Accessibility built into the code, not bolted on.
A website accessibility redesign rebuilds semantic structure, contrast, focus states, forms, and keyboard navigation — aligned to WCAG 2.1 AA. Accessibility is part of build quality. It belongs in the code, not in a third-party overlay that promises compliance and delivers neither.
Five accessibility layers.
- Semantic structure — landmarks, headings, lists, regions
- Form labels and inputs — properly associated, clearly named
- Color contrast — text and interactive elements verified
- Focus states — keyboard navigation visible and logical
- Keyboard and screen reader behavior — every interactive element reachable
Every layer gets verified through real keyboard and screen-reader testing, not just an automated scan.
Five common accessibility failures.
Non-semantic structure
Divs used where headings, lists, buttons, and landmarks belong. Screen readers can't navigate a page made of generic containers. The redesign rebuilds the structure with real semantic HTML so assistive technology reads the page correctly.
Forms with broken labels
Placeholder text used as a label, inputs with no associated `<label>`, error messages that screen readers can't reach. The redesign fixes the form markup so every field has a real label, every error is announced, and the tab order works.
Color contrast that fails the threshold
Text on background colors below the WCAG ratio, link colors indistinguishable from body text, interactive elements (buttons, focus indicators) too light to see. The redesign measures and corrects contrast across the visual system.
Focus states that disappear
Default browser focus rings removed in CSS with nothing meaningful in their place. Keyboard users can't see what's focused. The redesign restores visible, consistent focus indicators on every interactive element.
Overlay widgets in place of real fixes
The "accessibility overlay" market sells a third-party widget that promises compliance and delivers technical debt. Most overlays produce worse experiences than the unaccessible site they layer over. The redesign removes the overlay and fixes the underlying code.
Three outcomes from doing this right.
Building accessibility into the redesign — instead of patching it later — produces three durable outcomes.
Legal exposure goes down.
ADA-related web complaints continue to rise. Sites with documented accessibility work, real semantic structure, and tested keyboard behavior are in a better position than sites relying on overlays or hope.
Search performance goes up.
The signals Google uses for accessibility — semantic HTML, alt text, heading structure, contrast — overlap heavily with the signals Google uses for ranking. Accessible sites tend to rank better on the same content.
The site works for more people.
A site that works with a keyboard works for visitors with mobility issues, visitors with broken trackpads, and visitors who simply prefer keyboard navigation. Accessibility extends the audience the site can serve.
Frequently asked questions.
Do you guarantee WCAG compliance?
Short answer: We align to WCAG 2.1 AA and document the work. Strict legal compliance involves audit, monitoring, and remediation over time — not a single launch milestone. The redesign produces a site that meets the standards; ongoing maintenance keeps it there.
Should we use an accessibility overlay?
Short answer: We recommend against it. Overlays add a script that runs on top of the existing site, often breaks assistive technology, and produces worse outcomes than the underlying site. The redesign fixes the source code instead.
How do you test accessibility after launch?
Short answer: Automated scans (axe, Lighthouse) catch the obvious issues. Real testing — keyboard-only navigation, screen reader walkthroughs (NVDA, VoiceOver), contrast verification — catches what automation misses. Both run before launch.
Does accessibility affect site speed?
Short answer: Done properly, no. Semantic HTML is often lighter than div-heavy markup. Accessibility work and speed work overlap more than they conflict.
Can accessibility run as a standalone engagement?
Short answer: Yes. A focused accessibility engagement keeps the existing visual system and rebuilds the underlying code layer. Many clients combine accessibility with broader redesign scope when both need attention.
Keep exploring.
Tell us where accessibility is the priority.
Send the URL and any accessibility audit findings or complaints you've received. We'll be in touch to schedule a call.