ADA Compliant Website Examples: What Good Accessibility Actually Looks Like

Accessible navigation starts with a skip-to-content link as the very first focusable element on the page. When a keyboard user presses Tab, they should see a visible link that lets them bypass the entire header and menu. Government sites like usa.gov implement this well. The main navigation should use a semantic <nav> element with an aria-label like 'Main navigation.' Dropdown menus need to be keyboard-operable: arrow keys to move between items, Enter or Space to activate, and Escape to close. The current page should be indicated with aria-current='page' rather than relying on visual styling alone. Mobile menus should use a proper button element (not a div) to toggle visibility, with aria-expanded reflecting the open/closed state.

Well-built accessible forms go beyond just adding label elements. Every input needs a programmatically associated label using the for/id pattern or by wrapping the input inside the label element. Required fields should be indicated with both visual cues and aria-required='true.' When validation fails, the form should move focus to an error summary at the top of the form, with each error linking directly to the offending field. Individual field errors should be associated with their input using aria-describedby. The error summary itself should be marked with role='alert' or injected into an aria-live region so screen readers announce it immediately. Apple's account creation forms and many government service portals demonstrate this pattern effectively.

Every informative image needs alt text that conveys the same information a sighted user would get. A photo on an 'About Us' page might read alt='Team members reviewing blueprints at a conference table' — it describes what matters in context. Decorative images (borders, spacers, purely aesthetic background photos) should use alt='' (empty alt) so screen readers skip them entirely. Complex images like charts or infographics need both a brief alt text and a longer description, either in surrounding text or via aria-describedby pointing to a detailed text block. Videos need synchronized captions (not auto-generated — those are full of errors) and ideally an audio description track or a text transcript. The key principle is that no information should be available only through visual or auditory means.

Accessible color usage means two things: sufficient contrast ratios, and never using color as the only way to convey information. Normal body text (under 18px or under 14px bold) must have a contrast ratio of at least 4.5:1 against its background. Large text (18px+ or 14px+ bold) needs at least 3:1. Non-text UI components like form field borders, icons that convey meaning, and focus indicators also need 3:1 against adjacent colors. Links within body text should be distinguishable from surrounding text by something other than color alone — an underline is the simplest solution. Error states should not rely solely on red coloring; include an icon, bold text, or explicit error message alongside the color change. Sites like GOV.UK are excellent references for contrast-first design that still looks modern.

Custom interactive components are where most sites fail. An accessible modal dialog must trap focus inside itself when open (Tab should cycle through the modal's focusable elements and not escape to the page behind), return focus to the triggering element when closed, close on Escape, and use role='dialog' with an aria-labelledby pointing to the modal's heading. Tab interfaces need role='tablist' on the container, role='tab' on each tab, and role='tabpanel' on each panel, with arrow keys moving between tabs and Tab moving into the active panel's content. Accordions should use button elements as triggers with aria-expanded toggling between true and false. The W3C's ARIA Authoring Practices Guide provides canonical keyboard interaction patterns for every common widget. If you are building custom components, following these patterns is non-negotiable for compliance.

The fastest way to see where your site stands is to run an automated scan that flags violations against WCAG 2.1 AA criteria. ADA CodeFix scans your pages and maps each issue to a specific success criterion, so you can compare your site directly against the patterns described above. After fixing automated findings, do a manual keyboard test: unplug your mouse and try to complete every key task on your site using only Tab, Enter, Space, Escape, and arrow keys. If you get stuck anywhere, that is a compliance gap. Finally, test with a screen reader — VoiceOver on Mac (Command+F5 to toggle) or NVDA on Windows (free download) — and listen to whether your content makes sense when read linearly without any visual context.