Usable with a screen reader,
not just passed an automated scanner
An automated scanner catches maybe a third of real barriers: missing color contrast, broken alt text, obvious failures. It misses almost everything that only shows up when a real screen reader user or a keyboard-only user tries to finish a task. We audit and build against WCAG 2.1 AA with both automated tools and real assistive technology testing. That gap, between passing a scanner and being usable, is exactly where most accessibility work fails.
What “accessible” actually means here
An accessibility-compliant web app meets WCAG 2.1 AA, the Web Content Accessibility Guidelines at the AA level. That covers 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 it is actually needed. Clear, consistent interaction patterns.
We verify this two ways: automated scanning and real testing with assistive technology. The two catch genuinely different problems, which is why we use both.
Where this matters most, and where it can wait
This earns its cost for almost any public-facing site. Accessibility barriers exclude real users, and in many places they carry real legal risk. It matters most for sites serving the public broadly: healthcare, real estate, anything government-adjacent.
A network of medical centres and a five-language real estate site we built both needed interfaces that worked for every visitor. Excluding part of the audience was never an acceptable tradeoff for either project, even for a faster build.
The honest scoping question is depth and timing, not whether to do it at all. A brand-new MVP that might pivot next month does not need the remediation depth a stable site with real traffic needs. We calibrate the engagement to the project’s actual stage.
How we find what automated tools miss
We start with an audit that combines two things. Automated scanning catches structural issues fast: missing alt text, wrong heading order, contrast failures. Real testing with a screen reader (VoiceOver, NVDA) and keyboard-only navigation covers the site’s actual core user flows.
That second part is where most real barriers live. A custom dropdown a mouse user never notices is unreachable by keyboard. A modal that traps or loses focus incorrectly. A form error that updates visually but a screen reader never announces.
Remediation ranks by real user impact, not raw issue count. One broken checkout step that blocks a screen reader user from buying matters more than fifty minor contrast issues on a footer nobody reads closely.
Where semantic HTML can express the right behavior on its own, a real button instead of a styled div with a click handler, we use it. Semantic HTML gets most accessibility behavior right for free. ARIA attributes go in only where semantic HTML genuinely cannot express the interaction, because ARIA used wrong makes things worse, not better.
Color contrast gets corrected against the actual WCAG 2.1 AA ratios, not just enough to clear one scanner’s threshold. Every interactive element gets a visible focus state, so keyboard navigation is genuinely usable, not only technically possible. We write an accessibility statement covering the conformance level and known limits, plus a plan for keeping new features compliant. Accessibility regresses fast once new components stop being checked against the same standard.
Why this is not a one-time fix
Accessibility does not stay fixed on its own. A new feature built without the same discipline brings back the exact problems a remediation just solved. We recommend building accessibility checks into your 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. Patching a problem with ARIA that semantic HTML would have solved more reliably often confuses screen reader users more, not less. We treat ARIA as a tool for genuine gaps, not a default fix.
A perfect automated scanner score can also create false confidence. It is a real floor, not proof the site actually works with a screen reader, which is exactly why we do not stop at the automated pass.
What it costs
| 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.
Where this connects
This pairs with design system and component library, since accessibility is cheapest to maintain once it is built into shared components. It also pairs with multilingual site with hreflang for sites that need accessibility and language support 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. The exact number depends on how much 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. 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: color contrast ratios, keyboard operability, screen reader compatibility. AAA exists but is rarely required, and sometimes not achievable without hurting usability for other users. 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 repeated across the site. A custom component missing keyboard support. A color pair that fails contrast. A form without proper labels. None of it 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. WCAG 2.1 AA conformance is the standard most accessibility-related legal claims and regulations reference. 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.