# WCAG compliance, built into the web app and kept there > A customer can't finish checkout with a screen reader, a procurement questionnaire asks for WCAG 2.1 AA, or a demand letter cites the ADA, and nobody on your roadmap is free to fix it. Our engineers and designers join your team, audit the application against WCAG 2.2 AA, and fix what they find in the code and the design system, so the fix holds when the next feature ships. We built WCAG 2.1 AA compliance for nmbtc.com, the WordPress product site we also rebuilt for NMBTC. Canonical: https://www.techfabric.com/expertise/web-accessibility --- It starts with an audit of the flows that matter most, sign-in, search, checkout and forms, ranked by who is blocked, so you know what gets fixed first before anything is built. ## What we implement - **Audit**: Every distinct template and user flow tested against WCAG 2.2 AA, with automated rules, a keyboard and a screen reader, and each finding tied to the criterion it fails. - **Remediation in the code**: Fixes made in the markup, the components and the styles, by the engineers who'd otherwise be building features, in your repository or your CMS. - **Accessible design systems**: Contrast in the colour tokens, visible focus in every component, and target sizes and labels designed in, so new screens start compliant. - **Checks that keep it**: Automated accessibility checks on every pull request, and a manual pass with a keyboard and a screen reader before each release. Sectors: Manufacturing, Automotive, Financial services, Retail ## What we build - Audited against WCAG 2.2 AA, the current version, which also covers 2.1 AA where a contract or rule names it - Fixed in the components first, so one fix reaches every screen that uses them - Custom web applications and WordPress sites, nmbtc.com among them - Automated checks in CI, and a person with a screen reader before each release - Design and engineering in one team, so a contrast fix and a focus fix land together ## What WCAG 2.2 asks of a web app WCAG 2.2 became a W3C Recommendation on 5 October 2023. Its success criteria sit at three levels, A, AA and AAA, and contracts, procurement questionnaires and regulations almost always name AA. Version 2.2 added nine success criteria to 2.1 and removed one, 4.1.1 Parsing, as obsolete. The new ones land hardest on web applications, because they're about focus, pointer targets and sign-in. - 2.4.11 Focus Not Obscured (Minimum), AA: a sticky header or a cookie banner can't hide the focused element - 2.5.8 Target Size (Minimum), AA: small icon buttons need enough size or spacing to hit - 2.5.7 Dragging Movements, AA: anything done by dragging needs a single-pointer alternative - 3.3.8 Accessible Authentication (Minimum), AA: sign-in can't depend on a cognitive test such as remembering or transcribing a code, unless there's an alternative - 3.3.7 Redundant Entry and 3.2.6 Consistent Help, both A: don't ask for the same thing twice, and keep help in the same place ## The deadlines buyers are working to The Department of Justice's ADA Title II rule makes WCAG 2.1 AA the technical standard for the web content and mobile apps of state and local governments. After an interim final rule in April 2026, governments serving 50,000 people or more must comply by April 26, 2027, and smaller ones and special district governments by April 26, 2028. A company that sells software or runs a portal for one of them should expect that date in its contract. - State and local governments of 50,000 or more: April 26, 2027 - Smaller governments and special districts: April 26, 2028 - The standard in the rule is WCAG 2.1 AA; meeting 2.2 AA covers it - Suppliers see it first as a procurement question or a contract clause ## Fixing it in the code and the design system An overlay script changes what the page looks like after it loads and leaves the markup underneath as it was, so a screen reader still meets the same unlabelled buttons and broken focus order. We'd fix the source. Most findings in an application trace back to a handful of shared components, a button, a modal, a form field, a data table, and fixing those once fixes every screen built from them. - Colour contrast set in the design tokens, so no component can ship below it - Focus order and visible focus fixed in the shared components - Form fields with real labels, errors announced to assistive technology - Modals and menus that trap and return focus the way a keyboard user expects ## nmbtc.com We built nmbtc.com, NMBTC's WordPress product site, to WCAG 2.1 AA. It's the same site whose product database, search filtering and navigation we rebuilt inside WordPress for the design engineers who buy from it, and that rebuild is written up in the NMBT case study. - WordPress, kept as the company's content system - The search and navigation rebuild is at /case-studies/nmbt - For a custom web application, we'd make the same fixes in its component library ## How an accessibility engagement runs We audit against WCAG 2.2 AA with automated rules, a keyboard and a screen reader, and rank the findings by who is blocked and where, so a checkout nobody can finish comes before a decorative image missing its alt text. Most fixes go into the shared components and the design tokens, and the rest into the page where the problem is local. Automated checks then run on every pull request. They catch only part of what WCAG asks, so a person with a keyboard and a screen reader checks each release, and anything new goes back into the ranked list. ### Audit Every distinct template and flow against WCAG 2.2 AA, each finding tied to its success criterion and to a screen you can open. ### Rank Blocked tasks first, such as sign-in, checkout or a form that can't be submitted, then everything a user can work around. ### Fix at the source Shared components and design tokens first, then page-level fixes, in your repository or your CMS. How we build design systems is at [/expertise/experience-design](https://www.techfabric.com/expertise/experience-design). ### Keep it Automated checks on every pull request, and a manual keyboard and screen reader pass before each release. Checked on 23 October 2026 against: [What's new in WCAG 2.2, W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/), [ADA Title II web rule, ada.gov](https://www.ada.gov/resources/2024-03-08-web-rule/). ## Questions ### Which WCAG level should a web application meet? AA. It's the level contracts, procurement questionnaires and the DOJ's Title II rule name, and the rule names WCAG 2.1 AA. We audit against WCAG 2.2 AA, the current version, which covers 2.1 AA as well and adds the newer criteria on focus, target size and sign-in. ### Will an accessibility overlay make our site compliant? We wouldn't rely on one. An overlay adjusts the page after it loads and leaves the markup as it was, so a screen reader still meets the unlabelled buttons and the broken focus order underneath. We'd fix the components the pages are built from, which also stops new screens shipping with the same problems. ### Does the ADA Title II rule apply to us? It applies directly to state and local governments, for their web content and mobile apps: by April 26, 2027 for those serving 50,000 people or more, and by April 26, 2028 for smaller ones and special districts, after the April 2026 interim final rule. If you build or run software for one of them, expect the requirement in your contract before that date. ### Do you work on WordPress sites as well as custom applications? Both. nmbtc.com is a WordPress site, and we built its WCAG 2.1 AA compliance. For a custom React, Angular or Next.js application we'd run the same audit and make the fixes in its component library. ### Can you make an existing design system accessible? Yes, and it's usually the fastest route to a compliant application. Contrast goes into the colour tokens, and visible focus, labels and target sizes go into the components, so every screen built from them inherits the fix. New screens then start compliant rather than being audited after the fact. ### How do you keep a site accessible after the fixes? Automated checks run on every pull request and fail the build on a regression they can detect. They can't detect everything WCAG asks, so a person with a keyboard and a screen reader checks each release, and the components carry the accessible patterns so new work starts from them.