Building Accessible Web Applications

About one in six people worldwide lives with a significant disability. Many more use a keyboard instead of a mouse, zoom text, or read a screen in bright sunlight. An accessible web application works for all of them, and it usually works better for everyone else too. The Web Content Accessibility Guidelines (WCAG) 2.2 define the standard, and level AA is the target most laws and contracts reference.

Start with semantic HTML

Native elements come with keyboard handling, roles and screen reader support built in. A <button> receives focus, responds to Enter and Space, and announces itself as a button. A <div onclick> does none of that until you add it by hand.

• Use <nav>, <main>, <header> and <footer> so screen reader users can jump between regions.
• Use one <h1> per page and keep heading levels in order.
• Use <a> for navigation and <button> for actions.
• Use real lists, tables and form controls for lists, tabular data and input.

Make everything work with a keyboard

Unplug your mouse and try to complete your main task. Every interactive element must receive focus, show a visible focus indicator and work with Tab, Shift+Tab, Enter, Space and the arrow keys where the pattern calls for it. Never remove the focus outline without providing a clear replacement. Modal dialogs must trap focus while open, close on Escape and return focus to the control that opened them. Add a "skip to main content" link as the first focusable element.

Check color and contrast

WCAG AA requires a contrast ratio of 4.5:1 for normal text and 3:1 for large text and interface components such as input borders and icons. Tools like the WebAIM contrast checker or the browser's DevTools show the ratio. Do not use color as the only signal: pair a red error border with an error message and an icon, and underline links inside body text.

Write useful text alternatives

Every informative image needs an alt attribute that describes its purpose. Decorative images get alt="" so screen readers skip them. Icon-only buttons need an accessible name, either visible text, an aria-label or visually hidden text. Videos need captions, and audio needs a transcript.

Build accessible forms

• Connect every input to a visible <label> with matching for and id attributes. Placeholder text does not replace a label.
• Mark required fields in text and with the required attribute.
• Show errors next to the field, link them with aria-describedby and move focus to the first error after a failed submit.
• Set autocomplete values like email and postal-code to speed up entry.

Use ARIA with restraint

The first rule of ARIA is to use native HTML when it exists. ARIA fills gaps for custom widgets such as tabs, comboboxes and live regions. Wrong ARIA is worse than none, because it tells assistive technology something false. When you build a custom widget, follow the patterns in the WAI-ARIA Authoring Practices Guide and test the result. Use aria-live="polite" regions to announce updates such as "3 items added to cart" without moving focus.

Respect user preferences

Honor prefers-reduced-motion by turning off parallax and large animations. Support text zoom to 200 percent and a reflowing layout at 320 pixel width without horizontal scrolling. Support prefers-color-scheme and, where possible, high-contrast modes.

@media (prefers-reduced-motion: reduce) {
  * { animation-duration: 0.01ms !important; transition-duration: 0.01ms !important; }
}

Test in layers

1. Run automated checks with axe DevTools, Lighthouse or jest-axe in CI. These catch roughly a third of issues.
2. Walk through key flows with the keyboard only.
3. Test with NVDA or JAWS on Windows, VoiceOver on macOS and iOS, and TalkBack on Android.
4. Invite users with disabilities to test your product when your budget allows it.

Make it part of the process

Common questions

Which WCAG level should we target?

Target level AA of WCAG 2.2. Most accessibility laws and procurement requirements reference it, and it covers the barriers that affect the largest groups of users. Level AAA contains criteria that are impractical to meet for entire sites, so apply individual AAA items where they are easy wins, such as clearer language.

Do overlay widgets make a site accessible?

No. Overlay products that promise one-line compliance cannot fix missing labels, broken focus order or inaccessible custom widgets, and several have been the subject of legal complaints. Fix the underlying code and design, and test with real assistive technology.

How do we keep accessibility from regressing?

Add automated checks to pull requests, keep accessible components in your design system, and include accessibility acceptance criteria in every ticket. Schedule a manual audit once or twice a year, and after major redesigns. Train designers and developers together so problems are caught at the wireframe stage.

Does accessibility help SEO?

The overlap is real. Semantic headings, descriptive link text, image alt text, captions and transcripts give search engines more to understand, and faster, cleaner pages tend to rank and convert better. Accessibility is not a ranking factor on its own, but the same practices support good search performance.

Retrofitting accessibility costs far more than building it in. Add accessibility criteria to your design system components and your definition of done, so each new button, modal and table starts compliant. If you need an audit of an existing site or want accessibility built into a new project, get in touch and see our web development services.