How to review for accessibility

Approach accessibility reviews methodically

Auditing an existing site for accessibility can feel daunting. The range of potential issues is broad, but the process becomes manageable when you break it down into a structured series of checks. Prioritizing the areas that impact the most users first will help you identify and fix critical problems more efficiently.

Verify keyboard-only operation first

For users who cannot or choose not to use a mouse, the keyboard is the primary way to reach every part of the interface. This includes people with motor impairments and screen reader users. Start by tabbing through the page: focus order should follow DOM order, and every interactive control must be reachable without a mouse.

Pay particular attention to these keyboard concerns:

• Custom controls built from <div> or other non-interactive elements need a tabindex="0" to enter the tab order. Avoid tabindex values greater than 0, as they can create a confusing sequence for screen reader users.
• Do not add tabindex to non-interactive elements such as headings. This slows down keyboard users who can see the screen without helping screen reader users, who already become aware of those elements.
• When new content loads dynamically, move the user's focus to that content so they can act on it.
• Guard against keyboard traps. Autocomplete widgets and other contexts can leave the user stuck. Focus may be temporarily trapped within a modal, but you must provide a keyboard-accessible exit.
• Offscreen content that remains in the DOM, like links in a responsive menu or unopened modal buttons, can confuse keyboard users and screen readers. Use the inert attribute to remove offscreen interactive elements from the accessibility tree and keyboard flow; for older browsers, combine aria-hidden="true" with tabindex="-1".

Remember that ARIA changes only an element's semantics, not its behavior. Marking an element aria-hidden="true" does not prevent it from receiving keyboard focus.

Run a screen reader pass

Solid keyboard support is groundwork for the next phase: confirming the page exposes the correct semantics, labels, and structure that assistive technology relies on. When testing, keep these items in mind:

• Every meaningful image should have appropriate alternative text. Purely decorative images should use alt="" to signal that screen readers should skip them.
• Each control needs a label. Custom controls may require aria-label or aria-labelledby.
• Custom controls need an appropriate role plus any ARIA state attributes, such as role="checkbox" with aria-checked="true|false".
• The logical sequence of information should follow DOM order, because screen readers navigate in that order. Visually repositioned content that is moved with CSS will be announced in the wrong sequence; move the element in the DOM instead.
• No part of the page should be permanently hidden from screen readers. Content that should not be announced, such as offscreen sections or decorative material, can be marked with aria-hidden="true", while genuinely offscreen interactive controls require the inert attribute as covered above.

Learning a screen reader is a worthwhile investment. VoiceOver ships with macOS, and NVDA is a free, open-source Windows option. A few basic keystrokes are usually enough to run meaningful checks.

Make states and purpose visible

Users should not have to guess whether an element is clickable. Links and buttons must be distinguishable from surrounding text—a text underline on links is a common signal. Hover states are useful for mouse users, but elements must be recognizable without them so that the same information is available to other input methods.

Build for headings and landmarks

Correct semantic structure greatly improves navigation efficiency for assistive technology. Many screen reader users jump from heading to heading when they first land on a page. Landmarks such as <main> and <nav> also allow for quick navigation by region.

• Use the h1-h6 hierarchy consistently to create a meaningful outline. Ignore default heading styles and pick levels by semantics, then apply your own CSS.
• Prefer landmark elements (<main>, <nav>) or the ARIA role equivalents (<div role="search">) to structure major page regions.
• Avoid role="application". That role disables assistive technology shortcuts and routes all key presses to the page, which means your code must handle all keyboard interactions itself. Only use it if you have specific experience managing that behavior.

Screen readers expose a context menu that lists headings and landmarks; using it during review is a fast way to spot missing levels or regions that will confuse users.

Automate what you can

The axe and WAVE browser extensions catch many subtle issues, including contrast failures and missing ARIA attributes. The axe-cli command line tool provides the same engine (axe-core) for terminal workflows, and that engine can be integrated into an automated test suite to avoid regressions—especially helpful in CI

If you already use Lighthouse for PWA checks, watch for the report's accessibility section. Since this area is powered by axe-core, fixing those failures will directly improve the experience of assistive technology users.