Skip to main content
RemediADA
Methodology

How RemediADA checks, fixes and records

What the system does today, step by step, from the first crawl to the fix history in your dashboard.

How we detect

The scanner runs the checks below on each page it reaches. When the same failure turns up on several pages of a crawl, it is reported once, against the first page it was seen on.

A

axe-core on the rendered page

Once the page has loaded and settled, the scanner runs the axe-core rules against it. Missing alternative text, empty link text, skipped heading levels and form fields without labels are found here.

B

Computed accessibility tree and contrast

axe reads the roles, names and styles the browser computed, so the check works on what the browser built rather than the raw HTML. Where axe cannot resolve a colour, such as text over an image or a gradient, a separate probe reads the colours the browser actually rendered so the contrast ratio can be worked out.

C

Keyboard traversal

The scanner presses Tab through the page with real keystrokes and records the order. It reports focus that gets stuck, elements with no visible focus indicator, a missing skip link, a tab order that does not follow the page, and focus that changes the page on its own.

D

Click-through of the page

The scanner opens menus, tabs, dialogs and expanding sections, then runs axe again. A failure that only appears after the click is reported alongside the rest.

E

Live-region and support-page probes

Where a form or button should announce a result, the scanner checks that a live region is there to announce it. On paid scans it also reads the help, contact, documentation and terms pages for the EN 301 549 clause 12 rows.

F

AI visual analysis

On paid scans a screenshot of the page goes to an AI vision model, which looks for failures the code checks cannot see, such as text over a photo that is hard to read and colour used as the only way to convey meaning.

How we fix

Fixes follow the Persistence Limitation: the remediation engine writes each fix to the source through the platform’s own API. It does not add a script to your pages to change them in the visitor’s browser. A fix that has been written stays in place if you disconnect RemediADA.

Platform-native writes

WordPress fixes go through the WordPress REST API. Shopify fixes go through the Shopify Admin REST API, for page and product content. Webflow fixes go through the Webflow API. Squarespace fixes go through its Products API, for product descriptions and images. For a website repository on GitHub we open a pull request. A custom-coded site with no connection receives a downloadable patch to apply itself. Wix does not give the write access we need, so for Wix we generate the changes and you apply them.

The fix goes to whatever the platform serves the page from: a database row, a content record or a file under version control.

Confidence routing and approval

The remediation engine writes a candidate fix and scores its confidence. On WordPress, Shopify, Webflow and Squarespace, the job starts once you have bought remediation and connected the platform. Fixes the system scores at or above its automatic threshold are applied directly. Fixes between the review threshold and the automatic threshold wait in your review queue for you to approve. Fixes below the review threshold are not applied.

Before anything is written, the whole batch goes through a visual check. If the page would look different with the fixes in place, the batch is held and nothing is written. On GitHub every fix goes into the pull request, and we merge it only if you turned on automatic merging.

Snapshots and rollback

Every applied fix is stored with the original content next to the fixed content. On the platforms we write to, any fix can be reverted from your dashboard, one at a time or all together. A pull request you merged or a patch you applied is yours to revert, and the original content stays in your fix history so you can.

Monitoring and drift

Monitoring plans re-scan on their schedule. A new failure of a kind you turned on for automatic fixing is queued for a fix under the same confidence rules. A failure we fixed before that comes back within 90 days is reported to you as drift and is not fixed again on its own.

How we record it

Every scan, every fix and every check after a fix leaves a record. These are the records, in the order a job writes them.

  1. 01

    Scan record

    Every scan has its own ID. The violation list is stored with it, and each finding carries its WCAG criterion, its severity and the selector of the element it was found on.

  2. 02

    Fix snapshot

    Every fix is stored in fix_snapshots with the original content and the fixed content, byte for byte, the resource that was changed, the platform, the time and the violation it fixes. Rollback writes the original back from this record.

  3. 03

    Check after the write

    After a write, the system reloads the live page and checks the page still looks the same, and on the platforms where it can, checks the fix is present. If the page changed more than an accessibility fix should, the change is queued for rollback where the platform supports it and the job is held.

  4. 04

    Audit log

    Each step of a remediation job, from the gate before the write to any rollback, is written to an audit log with a timestamp.

How EN 301 549 reports are built

The EU Accessibility (EAA) Add-On turns our checks into an accessibility conformance report organised by the clauses of EN 301 549. Rows follow V3.2.1, the edition that is the legal reference today. Each chapter is filled from one source, and a chapter we have no evidence for says so.

9

Web

From the website scan. Each WCAG 2.2 Level A and AA success criterion maps to its clause 9 row, and the row carries the status our checks found on the pages scanned.

10

Non-web documents

From the document checks on the PDF and Office files found on your site or uploaded by you. Only documents that were actually checked count toward these rows.

11

Software

From the app checks: the source check of your connected repository, and the runtime checks that install your Android or iPhone build and walk its screens.

12

Documentation and support services

From a pass over your help, contact, documentation and terms pages, plus your questionnaire answers. Each row shows what the pages showed (Found, Partly found, Not found). A row reads "Supports" only when the pages show the feature and your answer confirms it.

What "Not Evaluated" means. The product has not been evaluated against that requirement: none of our checks reached it on the pages, files or screens in this report. It is not a pass and not a failure. A whole chapter we had no evidence for, for example documents when none were checked, is listed under "Other chapters" as Not Evaluated and outside the scope of the evaluation. Chapters 4 (functional performance statements) and 5 (generic requirements) are always listed that way.

Newer requirements are labelled. V4.1.1 is the current edition and adopts WCAG 2.2. The requirements it adds to chapter 9 appear in a separate table headed "Chapter 9 additions in V4.1.1", and 4.1.1 Parsing is marked "Void in V4.1.1", so a reader can see which rows the legal reference edition requires today.

The report and the draft accessibility statement are generated from automated checks and your questionnaire answers. They do not give a presumption of conformity with the European Accessibility Act and they are not legal advice.

Lawsuit risk scoring

The risk label on a report comes from two things: whether the site fails any of the WCAG checks most often cited in ADA website lawsuits, and the site’s overall score. It shows how the site compares with the failures plaintiffs cite. It does not predict whether you will be sued, and it is not legal advice.

Sources

Every statistic on this site comes from one of the sources below. Figures without a primary source are not published, which is why you will not find a dollar amount here for what an ADA claim costs to resolve. Those numbers are confidential and no authoritative public figure exists.

  1. Seyfarth Shaw LLP, ADA Title III blog, Federal Court Website Accessibility Lawsuit Filings Bounce Back in 2025 (2026-03-25). adatitleiii.com
  2. UsableNet, 2025 Year-End Digital Accessibility Lawsuit Report (2026-01). info.usablenet.com(industry data, vendor published)
  3. WebAIM (Institute for Disability Research, Policy and Practice, Utah State University), The WebAIM Million: The 2026 report on the accessibility of the top 1,000,000 home pages (2026-03-30). webaim.org
  4. Accessible.org, ADA Website Compliance Lawsuit Settlement Amounts. accessible.org
  5. US Department of Justice / Federal Register, Nondiscrimination on the Basis of Disability; Accessibility of Web Information and Services of State and Local Government Entities, and the April 2026 interim final rule extending compliance dates (2026-04-20). federalregister.gov
  6. RemediADA coverage generator, Coverage truth table, generated from the criteria table, the routing maps and a real axe run (2026-09-14). Internal coverage matrix, available on request
  7. RemediADA coverage rollup, How many of the 55 criteria a scan can decide once WCAG 2.2.2 never passes on automation alone (2026-09-25). Internal coverage measurement, available on request
  8. RemediADA Information Disclosure Statement, provisional 64/071,563, Information Disclosure Statement (Form PTO/SB/08 equivalent), submitted under 37 C.F.R. 1.97 and 1.98 (2026-05-21). Prior-art search record, available on request
  9. Deque Systems, Automated Accessibility Testing Coverage (2021-01-01). deque.com(industry data, vendor published)
  10. World Wide Web Consortium (W3C), Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation (2023-10-05). w3.org
  11. US Federal Trade Commission, FTC enforcement action against an overlay provider over accessibility compliance claims (2025-04-01). ftc.gov
  12. ETSI, EN 301 549 V4.1.1 (2026-09) Harmonised European Standard, Accessibility requirements for ICT products and services (2026-09-01). etsi.org
  13. AccessibleEU (European Commission), European accessibility standard EN 301 549 has been updated (2026-09-07). accessible-eu-centre.ec.europa.eu
  14. EUR-Lex, Directive (EU) 2019/882 on the accessibility requirements for products and services (European Accessibility Act) (2019-04-17). eur-lex.europa.eu
  15. RemediADA product definitions and accessibility statement, Automated score scale, WCAG-edition export, and accessibility statement revision (2026-09-24). remediada.com
  16. Seyfarth Shaw LLP, ADA Title III blog, ADA Title III Federal Lawsuit Filings Fall Slightly to 8,667 in 2025 (2026-02-11). adatitleiii.com
  17. Seyfarth Shaw LLP, ADA Title III blog, 2026 Mid-Year Report: ADA Title III Federal Lawsuit Numbers Are Climbing (2026-09-09). adatitleiii.com
  18. EcomBack, 2025 Annual ADA Website Accessibility Lawsuit Report (2026-02-06). ecomback.com(industry data, vendor published)
  19. California Legislative Information, California Civil Code section 52 (Unruh Civil Rights Act remedies). leginfo.legislature.ca.gov