ADA website compliance means addressing accessibility barriers, not buying a badge. For B2B companies on WordPress, #10 recommends a defined WCAG testing target, automated checks plus manual testing of important tasks, fixes to the underlying site, and ongoing review. You need evidence that people can use the site. A plugin or a clean scan alone does not provide it.
A procurement team may ask whether your website is accessible. Your marketing team may have received an automated warning, or discovered that the quote form cannot be completed without a mouse. These situations call for different responses, but none is helped by treating accessibility as a product you install once.
We approach the technical work as part of building and operating a usable WordPress site. The legal question belongs with qualified counsel. Keeping those responsibilities distinct makes the brief more useful, not less urgent.
What does ADA website compliance actually require?
The Americans with Disabilities Act is a law. The Web Content Accessibility Guidelines, or WCAG, are a technical standard. They are related, but they are not interchangeable labels.
The Department of Justice’s guidance on web accessibility and the ADA explains its position that ADA obligations extend to the online goods and services of businesses open to the public under Title III. It identifies barriers such as mouse-only navigation, missing image alternatives, inaccessible forms and insufficient color contrast.
That does not make a general-purpose checklist a legal determination for every company. Calling your business B2B does not resolve which obligations apply. Ask counsel to establish the applicable requirements, including any contractual obligations, before treating a vendor’s proposal as the answer.
State and local government entities have a separate Title II web-accessibility rule. The DOJ’s Title II fact sheet explains its WCAG 2.1 Level AA requirement, scope, exceptions and compliance dates. Do not borrow a government deadline and apply it to a private company’s website.
For a technical brief, we recommend specifying a version and level, such as WCAG 2.2 Level AA, rather than asking for an unspecified “ADA-compliant site.” W3C’s WCAG overview explains the versions and conformance levels. The target for your project should also account for the requirements counsel or procurement identifies.
This guide is technical planning information, not legal advice or a complete WCAG conformance checklist.
What your WordPress site needs before you buy another tool
Start with what a visitor needs to accomplish. On a B2B site, that might mean finding a product, comparing specifications, reading a datasheet and submitting a request. An accessible homepage is not enough if the form at the end of that journey is unusable.
These are useful starting checks, drawn from the DOJ guidance and W3C’s first-review accessibility checks. Passing them is not proof that every applicable WCAG criterion has been met.
Navigation and controls that work without a mouse
Try the main navigation, search, product filters and contact form using only the keyboard. You should be able to reach and operate the controls, see which element has focus, and move away without becoming trapped. Check any menu, modal or consent banner that interrupts the journey as well.
A visible button is not enough if it cannot be reached or activated. Record the actual failure, such as “the product-menu dropdown cannot be opened with the keyboard,” rather than putting “navigation accessibility” on an undifferentiated task list.
Content whose structure is available beyond its appearance
Headings should describe the page’s sections and be marked up as headings, not merely styled to look large. Informative images need appropriate text alternatives. A chart conveying essential information needs that information available in text, not just a generic description such as “chart.”
For technical catalogs, include specification tables and documents in the review scope. If a buyer needs a PDF to evaluate the product, stopping the audit at the download link misses part of the task. Review the document’s accessibility rather than assuming that making it downloadable makes it usable.
Forms that explain what to enter and what went wrong
Check field labels, instructions, required-field indicators and error messages. Can someone using a screen reader identify what each field is for? If submission fails, can they find the error and understand how to correct it?
Test the full sequence, including validation and confirmation. Reaching the submit button is not the same as successfully making an inquiry.
Readable layouts and usable media
Review text contrast, browser zoom and whether important information relies on color alone. Try the content at an enlarged size rather than judging it only on a designer’s screen.
Include video captions and other media alternatives appropriate to the content. An embedded player or third-party form should not disappear from the scope simply because another vendor supplies it. List those dependencies and agree who will investigate and fix each one.
What your site does not need as a substitute for the work
The expensive mistake is not necessarily choosing the wrong tool. It is expecting a tool to answer a question it cannot answer on its own.
| What you are offered | What to ask for instead |
|---|---|
| An accessibility widget presented as proof of compliance | Evidence that the underlying pages and important tasks have been tested and barriers addressed |
| A clean automated scan | The scan’s scope, manual test results and unresolved issues |
| A certificate or badge | The standard assessed, pages and tasks tested, methods, findings and assessment date |
| A complete redesign before anyone has investigated the failures | A diagnosis showing which issues are in shared components, individual pages, content or third-party tools |
| A one-time fix with no handoff | Retesting, publishing guidance and clear ownership after launch |
The DOJ specifically warns that a clean automated report does not necessarily mean everything is accessible. It recommends pairing automated checkers with manual review. We would use a scanner to find issues worth investigating, not as the sole acceptance test for the site.
The same distinction applies to an accessibility statement. W3C’s guidance on accessibility statements recommends useful information about accessibility, known limitations and feedback routes. A statement helps people understand the situation and report problems. It does not repair a broken form or establish conformance by itself.
You also do not need an agency’s promise that a website will be “lawsuit-proof.” Ask for a precise technical scope and verifiable work, with legal interpretation kept where it belongs.
Fix in place or include accessibility in a WordPress rebuild?
We would make this decision after examining representative templates and complete visitor journeys, not from a screenshot or a plugin’s score.
If the failures sit in a shared navigation component, form template or set of content patterns, targeted remediation may be the right scope. If the theme and editing system repeatedly produce barriers, a rebuild may deserve consideration. Either way, ask the team to explain why its recommendation addresses the underlying problems.
A practical brief should identify:
- The WCAG version and level being assessed, plus any separate requirements supplied by counsel or procurement.
- The templates, documents, integrations and complete tasks included in testing.
- Automated and manual testing methods, including keyboard and screen-reader testing.
- A prioritized issue log with examples, owners and retest results.
- Known limitations and responsibility for future content and component changes.
Prioritize blockers in important journeys, then work through the rest of the agreed scope. Prioritization is a way to sequence remediation, not permission to label a partly tested site fully conformant.
Our WordPress design and development work is the relevant starting point when the implementation needs attention. A redesign should have accessibility acceptance criteria before design approval, not an accessibility task added after launch.
What long-term WordPress ownership looks like in practice
For a B2B industrial photonics distributor, our engagement record spans work since 2007. We rebuilt its site on WordPress, mapped redirects for the platform change, built bulk product and datasheet management tools, and continued maintaining categories, documents and content as the catalog changed.
That is proof of long-term WordPress operations, not a claim that this client passed an ADA or WCAG assessment. We do not have a verified accessibility result to present for that engagement.
The relevance is operational: a technical site keeps changing after launch. A new form, revised template or replacement datasheet creates something else to review. Accessibility needs an owner within that publishing and maintenance process, rather than being left in the launch checklist indefinitely.
You can see the broader shape of our work in our project portfolio. For accessibility, ask specifically what testing and remediation your engagement includes. A general support relationship should not be mistaken for a comprehensive accessibility assessment.
Questions B2B WordPress owners ask
What should a WordPress agency for B2B include in an accessibility brief?
A named testing target, representative templates, complete buyer tasks, manual testing alongside automated checks, a remediation scope and retesting. Include important documents and third-party dependencies. The proposal should make clear what is assessed and what remains outside the scope.
Do we need a WordPress rebuild or redesign to address accessibility?
Not automatically. Start with diagnosis. Some failures can be addressed in shared components or content without replacing the site. A rebuild is a larger decision that should be justified by the condition of the theme, templates and editing workflow, not by an unsupported claim that an old site cannot be fixed.
Can a WordPress maintenance and support agency handle this after launch?
It can own agreed implementation and regression checks, but confirm the scope. Security patches, uptime monitoring and plugin updates are not the same as accessibility testing. Ask who performs the assessment, who fixes findings and when the important journeys will be retested.
What does a WordPress redesign agency with long-term support need to hand over?
Test results, resolved and unresolved findings, content-entry guidance, and a clear route for reporting barriers. The support retainer should define responsibility for new templates, form changes, documents and third-party integrations rather than implying that every future change is covered.
Does WCAG conformance guarantee ADA compliance?
Do not treat it as a legal guarantee. WCAG provides testable technical criteria; legal obligations depend on the applicable law and circumstances. We recommend agreeing the technical target with the people responsible for legal and procurement requirements, then retaining evidence of the assessment and remediation.
Start with a scoped review, not a compliance badge
Before commissioning work, gather the important page types, forms, documents, integrations and any requirements already supplied by procurement or counsel. That gives the team something concrete to assess and gives you a way to judge its recommendation.
If your WordPress site needs changes, talk with #10 about the implementation and ongoing support. We can discuss where the work fits within the site’s operation and what specialist assessment needs to be scoped separately. The useful outcome is a site people can use, with tested fixes and a team responsible for keeping it that way.
