Accessibility, answered.

Web accessibility means building websites and apps so that people with disabilities — visual, motor, auditory, cognitive — can perceive, understand, navigate and use them. In practice that means things like real text alternatives for images, full keyboard operation, sufficient colour contrast, and content that works with screen readers.

It depends where you operate and who you serve. Many jurisdictions require it: the ADA in the US, the European Accessibility Act in the EU, and Section 508 for US federal bodies and their vendors. Even where no single law names your site, accessibility is increasingly expected and litigated — so the practical answer for most public-facing sites is yes.

The Web Content Accessibility Guidelines (WCAG) are the international standard for digital accessibility, published by the W3C. Almost every accessibility law points to WCAG as its technical baseline. The current version is WCAG 2.2, published in 2023.

WCAG defines three conformance levels. Level A is the essential minimum, Level AA is the level almost every law requires, and Level AAA is enhanced and rarely required across a whole site. When people say “WCAG compliant” they almost always mean Level AA.

US courts have widely applied the ADA to websites, especially for businesses tied to a physical place. For state and local government (Title II), the DOJ set WCAG 2.1 AA, and a 2026 interim rule extended the compliance dates to 26 April 2027 for larger entities and 26 April 2028 for smaller ones. For private businesses (Title III) there is no single fixed federal deadline, but accessibility is still expected. See the ADA guide.

The EAA is an EU directive requiring a wide range of products and services — e-commerce, banking, transport, e-books and more — to be accessible. Its requirements have applied since 28 June 2025. It reaches any company selling into the EU, not just EU-based ones, and it is met in practice through EN 301 549, which references WCAG 2.1 AA. See the EAA guide.

Section 508 requires US federal agencies to make their technology accessible, and it reaches private vendors indirectly through procurement: to sell to the government you typically supply a VPAT showing how your product conforms. Its baseline is WCAG 2.0 AA. See the Section 508 guide.

Yes. Thousands of web accessibility lawsuits are filed every year in the US, and the majority target e-commerce sites. Importantly, adding an accessibility overlay or widget does not shield you — many suits have been filed against sites that had one installed. The reliable protection is an actually accessible site.

Target WCAG 2.2 Level AA. It is the current version and is backwards compatible, so meeting 2.2 AA also satisfies the 2.1 AA that the ADA and EAA reference and the 2.0 AA that Section 508 references. Working to the newest version keeps you covered across frameworks.

WCAG 2.2 added nine new success criteria — covering things like focus visibility, target size, dragging alternatives, consistent help and accessible authentication — and removed one older criterion (4.1.1 Parsing). It is otherwise backwards compatible with 2.1. Our WCAG 2.2 guide breaks down each new criterion.

No. Automated testing reliably detects 30–50% of WCAG 2.2 AA success criteria. It is excellent at catching things like missing alt text, low contrast and unlabelled fields quickly, but it cannot judge meaning, keyboard flows, reading order or whether an error message actually helps. A clean scan is a strong start, not a compliance result.

A scan is automated: fast, repeatable, and good for the 30–50% of WCAG 2.2 AA success criteria machines can detect. A manual audit is expert human testing of the rest — keyboard, screen reader, focus order, cognitive load — and produces a report you can act on and stand behind. You need both; the checklist shows exactly which criteria fall where.

No. Overlays add user-facing adjustments on top of a site, but they don't fix the underlying code, and they don't make a site conform to WCAG. Regulators have acted on this: in 2025 the FTC ordered an overlay vendor to pay $1M over its compliance claims (FTC case 2223156 (opens in a new tab), final order April 2025). Treat a widget as a convenience layer on an already-remediated site, never as a substitute for the fixes.

Accessibility isn't a one-time task. Test before each major release, re-scan after redesigns or new features, and review key user journeys periodically — new content and components introduce new issues. Building it into your process is far cheaper than an annual scramble.

In some cases it's required — EU public sector bodies must publish one, and the EAA expects covered services to provide accessibility information and a feedback route. Elsewhere it isn't mandatory but is a recognised good-faith practice and a genuine help to users. You can build one free with our statement generator.

Rarely. “Fully compliant” means every page meets every applicable criterion — hard to sustain and easy to disprove. Overstated claims have drawn regulator action, and EU law requires accessibility statements to be accurate. Most sites should state “partially conformant”, list known limitations honestly, and describe how they're closing the gap.

A Voluntary Product Accessibility Template (VPAT) is a document describing how a product meets accessibility standards like Section 508 or WCAG. A completed one is called an ACR, and it's often required to sell to the US government. It should reflect real testing — an inaccurate VPAT can get a product disqualified from procurement.

FlexAccesses helps you find, fix and document web accessibility issues. It combines an automated scanner, self-guided tools like our checklist and statement generator, an optional on-site widget, and expert manual audits — with an honest view of what each part can and can't do.

No, and we won't tell you otherwise. The widget adds user-facing adjustments — things like text size and contrast — that some visitors find helpful. It does not fix your code or make your site conform to WCAG. Real conformance comes from remediation, testing and audits; the widget sits on top of that work, not in place of it.

Our checklist and statement generator run entirely in your browser. What you type isn't uploaded or stored on our servers — you copy or download the result yourself. The checklist saves your progress locally on your own device so it's there when you return.

Reach us from the contact page with your site and the user journeys that matter most — for example your home page, a key product or service page, and checkout or sign-up. A manual audit covers the criteria automation cannot reach and gives you a prioritised, actionable report.