FlexAccesses documentation

Introduction

FlexAccesses helps you find, fix and document web accessibility issues. It combines three things: an optional on-site widget, an automated scanner, and expert manual audits.

Quickstart

The fastest path from "we should look at accessibility" to a defensible position:

1. Run a scan on your most important pages (home, a product/service page, checkout or contact). See Run a scan.
2. Work the checklist for everything a scan can't judge. See Using the checklist.
3. Fix and re-test, then consider a manual audit for high-risk flows.
4. Publish an honest statement with the statement generator.

The widget is optional and can be added at any point — it's a user-experience layer, not a step toward conformance. See What it does & doesn't.

How the pieces fit

Each part covers something different. Knowing the boundaries keeps your claims honest.

Finally, the accessibility statement documents your status publicly — it reports the outcome of the work above, it doesn't replace it.

The widget: what it does & doesn't

What it does: gives visitors on-page controls to adjust their own experience — things like text size, spacing, contrast themes, and reduced motion. For some users, these are a genuine help.

What it doesn't do: it doesn't rewrite your HTML, add correct alt text, fix keyboard traps, or make your site conform to WCAG. Treating a widget as "compliance" is exactly the claim that has drawn regulator action against overlay vendors. Use it as a convenience layer on top of a properly remediated site — never as a substitute for the fixes.

Install the widget

Add the script to your site's HTML, just before the closing </body> tag, on every page you want it to appear.

<!-- Example only — replace with your real snippet -->
<script
  src="https://cdn.flexaccesses.com/widget.js"
  data-site="YOUR_SITE_KEY"
  defer></script>

On WordPress, Shopify and similar platforms you can paste this into the theme's footer or a "custom scripts" area. Confirm it loads on every template, including checkout and forms.

Configure the widget

Options are set as data- attributes on the script tag. The table shows the expected options — check your dashboard for the current, authoritative list.

Run a scan

Open the scanner, enter a page URL, and start the scan. Scan the templates that matter most — your home page, a representative content or product page, and any form or checkout — rather than only the home page. Most issues repeat across templates, so a handful of well-chosen pages tells you a lot.

Read your report

The report lists detected issues, typically grouped by severity and mapped to the WCAG success criterion each one relates to, with the location on the page. Start with the highest-severity, highest-frequency items — often low contrast, missing alternative text, and unlabelled form fields, which are also the most common failures across the web.

What a scan can't catch

This is the most important thing to understand about any scanner, including ours. Automated testing reliably detects 30–50% of WCAG 2.2 AA success criteria. It can confirm some things (a missing alt attribute, a low contrast ratio, a missing page language) and flag candidates for others — but it cannot judge meaning or experience:

• Whether alt text actually describes the image
• Whether the page works with a keyboard alone
• Whether the reading and focus order make sense
• Whether error messages actually help someone recover

So a clean scan is a good start, not a conformance result. The checklist tags every criterion automated, partial or manual, so you can see exactly where the human work begins.

The remediation workflow

A repeatable loop that keeps accessibility from becoming a one-time scramble:

1. Detect — scan for the automated issues.
2. Review — walk the checklist for the manual criteria, testing with a keyboard and a screen reader.
3. Fix — correct the underlying HTML, content and interactions, by role (design, dev, content).
4. Re-test — confirm the fix and watch for regressions after each release.

Using the checklist

The accessibility checklist covers all 55 WCAG 2.2 Level A & AA criteria. Filter to Manual to see what a scan can't reach, filter by role to hand each teammate just their items, and print a dated record for your files. Your progress is saved in the browser.

WCAG conformance levels

WCAG defines three levels: A (essential), AA (the standard most laws require), and AAA (enhanced, rarely required site-wide). The ADA and EAA point to WCAG 2.1 AA and Section 508 to WCAG 2.0 AA — and because WCAG 2.2 is backwards compatible, targeting 2.2 AA satisfies those earlier baselines. Our WCAG 2.2 guide explains the details.

Manual audits

A manual audit is expert human testing of the criteria automation cannot reach: keyboard operation, screen-reader behaviour, focus and reading order, cognitive load, and the quality of alternatives and error handling. The deliverable is a report of issues mapped to WCAG, with remediation guidance — and, where you need one for procurement, a VPAT. Audits are the strongest evidence behind a conformance claim.

To request an audit, contact support with your site and the flows that matter most to your users.

Statement & VPAT

Accessibility statement. A public page declaring your target standard, current status, known limitations and a feedback channel. Build one with the statement generator — and state a status you can stand behind, not "fully compliant" by default.

VPAT. A Voluntary Product Accessibility Template documents how a product meets standards like Section 508 and is often required in US government procurement. A completed VPAT (an ACR) should reflect real testing. See the Section 508 guide.

Support & troubleshooting

Third-party licences

Our scanner runs on axe-core, the open-source accessibility rules engine built by Deque Systems. It is distributed as part of our service, so it is named here together with its licence.

axe-core 4.10.2 — © 2015–2024 Deque Systems, Inc. Used under the Mozilla Public License 2.0 (opens in a new tab). We use the released file as published — unmodified, with its copyright notice intact. Source: github.com/dequelabs/axe-core (opens in a new tab).

This notice records what we use and on what terms; it is not a legal opinion. Deque Systems is not affiliated with FlexAccesses and does not endorse it. axe-core is a rules engine, not a verdict — what it can and cannot detect is set out under What a scan can't catch.