Web accessibility audit and remediation (WCAG 2.2 AA)

What the accessibility audit and remediation include#

We shape the engagement around the actual brief. The proposal identifies which of these deliverables are included, who supplies the inputs and how each one is accepted.

• Automated scan of every sampled page, plus manual testing of key journeys
• Keyboard, screen reader, zoom and reflow, and contrast testing
• Report of issues mapped to WCAG success criteria, with screenshots, severity and the fix
• Remediation in code, content and the design system
• Retest of every fixed issue
• Accessibility statement with a route to report barriers
• Checks added to the release process so issues do not return

Audit now or fix during a redesign?#

Start with an audit when you need to know where the site stands, because of a deadline, a tender or a complaint. If the site is due for a redesign anyway, build accessibility into the website redesign rather than fixing a design you are about to replace. Once the issues are fixed, a website maintenance plan with accessibility checks keeps new content and releases from bringing them back.

How the audit and remediation work#

We first agree the sample: every template type, the key journeys such as contact, sign-up, login, search and checkout, and the documents people have to download, following the W3C's evaluation methodology (WCAG-EM). An automated scan covers every page in the sample, then we test each journey by hand, because the W3C is clear that evaluation tools cannot determine accessibility on their own. Every issue is recorded with the success criterion it fails, a screenshot, who it affects, its severity and the fix.

Fixes are ranked by their effect on people and by how many pages share the cause. A broken component is fixed once in the design system and corrected everywhere it appears. We retest each fix, update the report and write the accessibility statement with the date, the standard, known limitations and a way to report barriers. If your own developers make the changes, we review their work and retest it.

What does the audit test?#

The audit follows how disabled people actually use the web, with WCAG 2.2 AA as the yardstick. Automated tools find part of the problems; the rest needs a person working through each journey:

The deliverable is a prioritized report, not a raw tool export. Each issue names the WCAG success criterion, where it happens, a screenshot, who is affected and the recommended fix in code or content, grouped so a developer can work through it and a manager can see what remains.

• Keyboard only: every link, control and form field reachable in a logical order, with a visible focus indicator that sticky headers do not hide
• Screen readers: NVDA on Windows, VoiceOver on macOS and iOS, and TalkBack on Android, chosen by your audience
• Zoom and reflow: text resized to 200% and content at 320 CSS pixels wide without loss or sideways scrolling
• Contrast of text, icons, focus indicators and form field borders
• Forms and errors: labels, instructions, error messages that say what went wrong, no re-entering the same data, sign-in without memory puzzles
• Target size and alternatives to dragging, for people with limited dexterity
• Motion: reduced-motion preferences respected, no flashing, controls to pause moving content
• Media: captions, transcripts and audio description where needed
• Documents: the PDFs and office files people need to complete a task

Which rules apply, and to whom?#

Accessibility laws differ in whom they bind, which standard they name and when they apply. WCAG 2.2 has been a W3C Recommendation since 5 October 2023 and was approved in October 2025 as the international standard ISO/IEC 40500:2025. The W3C states that content conforming to WCAG 2.2 also conforms to WCAG 2.0 and 2.1, so a 2.2 AA audit covers the 2.1 AA level that the US and Colombian rules name.

This table summarizes the rules for planning; it is not legal advice. Your counsel confirms which obligations apply to your organization, and we supply the technical evidence. Dates were checked against the official texts on 8 October 2026: the US interim final rule took comments until 22 June 2026, and no later rule has been published since.

Colombia: Resolución 1519 and NTC 5854#

Resolución 1519 de 2020 of MinTIC requires the obligated subjects of Ley 1712 de 2014 to meet WCAG 2.1 at level AA from 1 January 2022, as set out in its Anexo 1 on web accessibility guidelines. It applies to every update, restructuring, design or redesign of their portals and e-services sites, and to existing content. It does not bind private companies in general, but an obligated entity's portal has to meet it whoever builds it.

NTC 5854 of 2011, the Colombian technical standard for web accessibility, still appears in public entities' internal audits: the Superintendencia de Transporte's internal control office, for example, checked its portal against it in December 2022. Anexo 1 of Resolución 1519 does not cite it; the requirement there is WCAG 2.1 AA. We report against WCAG 2.2 AA and add an NTC 5854 cross-reference when an internal control office asks for one.

Why we audit by hand and do not sell overlays#

Overlay widgets promise compliance by adding one script to the page. In April 2025 the US Federal Trade Commission approved a final order requiring accessiBe to pay $1 million over claims the FTC alleged were false, misleading or unsubstantiated, including that its automated tool could make any website WCAG-compliant; the order bars such claims without evidence to support them. An overlay does not change the markup, components and content where the failures live.

We fix accessibility at the source, in the design system where possible, so a corrected button, form field or dialog stays correct on every page that uses it. Then we add automated checks and a manual keyboard pass to the release checklist, so new pages and content keep the level the audit reached.

Questions before you choose#