Usable with a screen reader,
not just passed an automated scanner
An automated accessibility scanner catches maybe a third of real barriers, missing colors, broken alt text, obvious contrast failures, and misses almost everything that only shows up when an actual screen reader user or a keyboard-only user tries to complete a real task. We audit and build against WCAG 2.1 AA with both automated tools and real assistive technology testing, since the gap between passing a scanner and being usable is exactly where most accessibility work fails.
What it is
An accessibility-compliant web app meets the Web Content Accessibility Guidelines at the AA level (WCAG 2.1 AA), covering how the site works for users with visual, motor, auditory or cognitive disabilities: sufficient color contrast, full keyboard operability, screen reader compatibility through semantic HTML and ARIA where needed, and clear, consistent interaction patterns. This is verified through a combination of automated scanning and actual testing with assistive technology, since the two catch genuinely different categories of problem.
When you need it (and when you do not)
It earns its cost for essentially any public-facing site, since accessibility barriers exclude real users and in many jurisdictions carry genuine legal risk, and it matters especially for sites serving the public broadly, healthcare, real estate, government-adjacent services. A network of medical centres and a multi-language real estate site we built both needed accessible, usable interfaces across a wide range of visitors, since excluding a portion of visitors on either project was never an acceptable tradeoff for a faster build.
It is rarely the wrong tool to invest in, but the honest scoping question is depth and timing: a brand-new MVP that may pivot in a month does not need the same remediation depth as a stable production site with real traffic, and we calibrate the engagement to that rather than selling the same scope regardless of project stage.
How we build it
We start with an audit that combines automated scanning, which quickly and reliably catches structural issues like missing alt text, incorrect heading order and contrast failures, with real testing using a screen reader (VoiceOver, NVDA) and keyboard-only navigation on the site’s actual core user flows, since this is where most of the barriers automated tools cannot detect actually live: a custom dropdown that a mouse user never notices is unreachable by keyboard, a modal that traps or loses focus incorrectly, a form error that updates visually but is never announced to a screen reader.
Remediation prioritizes real user impact over raw issue count: a single broken checkout step that blocks a screen reader user from completing a purchase matters more than fifty minor contrast issues on a footer nobody reads closely, and we rank the fix list accordingly rather than working through issues in whatever order a scanner happened to list them. Where semantic HTML alone can express the right behavior, a real button element instead of a styled div with a click handler, we use it, since semantic HTML gets a huge amount of accessibility behavior correct for free; ARIA attributes get added only where semantic HTML genuinely cannot express the interaction, since ARIA used incorrectly can make accessibility worse, not better.
Color contrast gets corrected against the actual WCAG 2.1 AA ratios, not just enough to clear a scanner’s specific threshold check, and every interactive element gets a visible, clear focus state so keyboard navigation is not just technically possible but actually usable to find where you are on the page. We write an accessibility statement documenting the conformance level and known limitations, and leave a plan for keeping new features compliant, since accessibility regresses quickly if new components are not checked against the same standard.
What to watch
Accessibility is not a one-time project that stays fixed; a new feature built without the same discipline reintroduces the exact problems a remediation just fixed, so we recommend building accessibility checks into the team’s regular review process, not treating this as a single engagement with no follow-up. Over-reliance on ARIA is a specific, common failure mode, adding ARIA attributes to patch a problem that semantic HTML would have solved more reliably often makes the experience more confusing for screen reader users, not less, so we treat ARIA as a tool for genuine gaps, not a default fix. And automated scanner scores can create false confidence, a 100% automated score is a real floor, not evidence the site is actually usable with a screen reader, which is exactly why we do not stop at the automated pass.
Price and timeline
| Option | Price | What it covers | Timeline |
|---|---|---|---|
| Audit and core flow remediation | from $2,200 | Combined audit, fixes to the most-used user flows | 2 to 3 weeks |
| Full-site remediation | from $5,500 | Site-wide audit and fixes, accessibility statement, team guidance | 4 to 5 weeks |
Running cost is close to zero once remediated; the ongoing cost is checking new features against the same standard before they ship.
Related
This pairs with design system and component library since accessibility is cheapest to maintain when it is built into shared components once, and with multilingual site with hreflang for sites serving accessibility and language needs together. See the development service page for our full build process. For real examples, see the five-language Montenegro real estate site and the medical centres marketing rebuild.
Not sure if your site actually works with a screen reader, versus just passing a scanner? Get in touch and we will test it with real assistive technology before proposing anything.
FAQ
How much does an accessibility build or remediation cost?
From $2,200 for an audit plus remediation of a focused set of core user flows, 2 to 5 weeks. A full-site remediation across a large, multi-page application runs $5,000 to $12,000 depending on how much of the existing code needs semantic restructuring rather than small fixes.
Is passing an automated scanner enough?
No, and this is the most common misunderstanding we run into. Automated scanners catch things like missing alt text and contrast ratios reliably, but they cannot tell you whether a screen reader user can actually complete a checkout flow, or whether a custom dropdown is operable by keyboard alone. We test with real assistive technology, not just a scanner report, because that gap is where legal exposure and real user exclusion both actually live.
What is WCAG 2.1 AA and why that level specifically?
WCAG is the Web Content Accessibility Guidelines, the standard most legal requirements and procurement policies reference; AA is the level most laws and major platforms require, covering things like color contrast ratios, keyboard operability and screen reader compatibility. AAA exists but is rarely required and sometimes not achievable without hurting usability for other users, so AA is the realistic, well-supported target for almost every project.
Can you fix an existing site, or does it need a rebuild?
Usually a fix, not a rebuild. Most accessibility problems come from a handful of recurring patterns, a custom component missing keyboard support, a color pair that fails contrast, a form without proper labels, repeated across the site rather than something that requires starting over. We prioritize by real user impact so the highest-barrier issues get fixed first.
Does this protect us legally?
We are not lawyers and do not offer legal advice, but WCAG 2.1 AA conformance is the standard most accessibility-related legal claims and regulations reference, and a documented audit and remediation process is generally the strongest practical position a site can be in. We recommend pairing this work with your own legal counsel's review for your specific jurisdiction.