Accessibility (WCAG) guide

Most of the legal-exposure conversation around accessibility focuses on the downside: the lawsuits, the demand letters, the reputational risk if a high profile accessibility failure becomes news. Those risks are real, and they are enough on their own to justify the investment. But the more durable reason to do the work is that accessible websites are better websites, full stop. They are easier to navigate, faster to load, more reliable on imperfect connections, more usable on the long tail of devices and assistive technologies, and more legible to search engines. The quality work that earns WCAG conformance is the same quality work that produces a better experience for users who do not have a disability, and the teams that internalize this tend to produce better software in general, not just more accessible software.

If you're starting from a site that hasn't been accessibility-audited, the most useful order to fix things is usually: keyboard navigation first (any interactive element you can't reach or operate with the keyboard is broken for a meaningful percentage of users); then color contrast (one of the most common failures and one of the easiest to fix at the design-system level); then form labels and error messaging; then heading order and landmark structure; then focus visibility; then ARIA roles and labels for dynamic content. Skipping ahead to ARIA before the basics are right tends to add more bugs than it removes.

Build the accessibility checks into your design and development workflow once the initial remediation is done. New components and content should be tested before they ship; otherwise the next year's audit looks a lot like this year's. The teams that do this well treat accessibility the same way they treat performance, a quality gate at every stage rather than a separate workstream.

WCAG defines three levels of conformance:

• Level A \u2014 the minimum; failing means real barriers for many users.
• Level AA \u2014 the practical industry target and what most regulations reference.
• Level AAA \u2014 the strictest; not realistic for all content.

Most engagements aim for WCAG 2.2 AA conformance.

An automated scan (axe, Lighthouse, WAVE, etc.) catches only a portion of accessibility issues, published research from Deque and others consistently puts it at a minority of WCAG criteria. The rest needs human review. A reasonable order:

1. Run an automated audit and triage the findings.
2. Manually test keyboard-only navigation across primary flows.
3. Test with at least one screen reader (NVDA, VoiceOver, JAWS).
4. Review color contrast, focus indicators, and form error patterns.
5. Audit media (alt text, captions, transcripts).

• Visible focus indicators. Default browser outlines are often removed without replacement.
• Form labels and error messages. Every input needs a programmatically associated label.
• Color contrast. 4.5:1 for normal text, 3:1 for large text and UI components.
• Heading structure. Logical hierarchy without skipped levels.
• Image alt text. Descriptive for content; empty (alt="") for decorative.
• Keyboard operability. Every interactive element reachable and operable without a mouse.

Accessibility work makes sites better for everyone: cleaner semantics, faster navigation, more reliable forms, better search engine understanding. The legal exposure is real \u2014 ADA, EAA, AODA \u2014 but the user experience win is the more durable reason to do the work.