Frequently Asked Questions

We can test and remediate accessibility problems in your WordPress website and work toward the technical accessibility standard applicable to your project.

We do not provide legal certification, and we do not claim that an automated scan can prove complete legal compliance. Anyone who tells you otherwise is selling you a number.

For organizations subject to specific regulations, we test and remediate against the relevant technical target while recommending legal counsel for legal interpretations.

That is not our remediation model.

We prefer to correct accessibility problems in the underlying WordPress theme, templates, plugins, content, CSS, JavaScript and interactions.

Targeted JavaScript or CSS may well be part of a legitimate fix. The difference is that the code exists to correct one specific defect, rather than acting as a blanket layer intended to compensate for the entire website.

Yes.

We can evaluate the rendered website with the existing widget or overlay present and determine what accessibility problems remain.

You do not have to remove an existing tool before beginning an assessment, and you do not have to take a position on overlays in general in order to find out what is wrong with your site in particular.

No.

Automated testing is extremely useful for finding certain classes of accessibility problems, but many WCAG requirements require human judgment, interaction testing, or assistive-technology testing.

We use automation where it is reliable, and we state its limitations rather than burying them.

The technical target depends on the engagement.

The DOJ Title II rule for state and local government currently uses WCAG 2.1 Level AA, and the HHS Section 504 web rule uses the same standard.

Our internal tooling also tests newer WCAG 2.2 criteria where that is useful, but we do not confuse a newer testing target with the standard actually named by a regulation.

Yes.

Elementor accessibility issues may originate in widget configuration, content, global styling, the active WordPress theme, Elementor add-ons, custom CSS, JavaScript, or generated markup.

We investigate the actual source and determine an appropriate remediation — usually one that fixes the pattern rather than each page that uses it.

Yes.

WooCommerce accessibility testing may include products, variations, carts, checkout, account screens, validation errors, status updates, keyboard behavior, and theme or plugin overrides.

Most of those are interactive states that a static scan of a product page never reaches.

Often.

Depending on the plugin, we may be able to resolve a problem with configuration, WordPress hooks or filters, template overrides, CSS, JavaScript, or another targeted change.

Sometimes the correct answer is replacing the plugin. We evaluate that case by case, and we will tell you when we think replacement is cheaper than repair.

A public site can be reviewed without administrative access for an initial assessment.

Foundational remediation should normally be performed against a staging, development, or local copy rather than making experimental changes directly in production.

Authenticated workflows may require appropriate access to a safe testing environment.

Accessibility remediation should not require adding a large blanket JavaScript layer to every page — which is one of the practical arguments against overlays as well as an accessibility one.

Some individual fixes may use CSS or JavaScript, but we aim for targeted, maintainable changes, and performance impact is considered as part of implementation.

It depends heavily on the site.

A straightforward brochure site with a reasonably accessible theme may require relatively minor changes.

A large WordPress installation with a page builder, WooCommerce, many plugins, years of content, forms and third-party services can be a much larger engagement.

An initial assessment is what determines the actual scope. We would rather find the size of the project at the start than halfway through it.

PDF and document accessibility can be part of the overall accessibility picture, especially for government and regulated organizations.

However, document remediation is a different discipline from WordPress code remediation and is usually scoped separately.

We can help identify document risk and determine what should be handled as part of a larger project.

Our automated testing does not substitute for testing with real assistive technologies such as NVDA, JAWS, or VoiceOver.

If a project requires formal assistive-technology testing, that should be included explicitly in the scope rather than implied by automated browser testing.

Yes.

We can establish a baseline and periodically retest representative pages and workflows for new accessibility regressions, reporting what is new rather than re-presenting the entire history every time.

Ongoing monitoring is optional and is not a condition of remediation work.

That is exactly the kind of regression ongoing testing is designed to catch.

A repaired website can become less accessible after software or content changes. Accessibility should be treated as an ongoing quality attribute rather than a one-time certificate.