Make an Interactive Frontend Demo Keyboard and Screen-Reader Friendly

Accessibility feedback is most useful before a prototype hardens into a component library. A single-file demo can already answer the essential questions: can the control be reached, does it have a meaningful name, is its state exposed, and does focus move predictably?

Use native elements whenever their behavior matches the interaction. A button supplies keyboard activation and semantics that a clickable div does not. A real input connects cleanly to a label. A link should navigate; a button should perform an action.

<label for="project-name">Project name</label>
<input id="project-name" name="project-name" autocomplete="off">
<button type="button" aria-expanded="false" aria-controls="details">
  Show details
</button>
<div id="details" hidden>Additional project settings</div>

When JavaScript changes visible state, update the related accessibility state in the same function. If the disclosure becomes visible, set aria-expanded to true. If a form submission produces an error, associate the message with the field and move focus only when doing so helps recovery.

Test without a mouse. Begin at the address bar, press Tab through the whole demo, activate controls with Enter and Space, and ensure focus never disappears behind an overlay. Visible focus should be stronger than a subtle color shift.

Then inspect the accessibility tree in browser developer tools. Names such as “button” or “image” without context indicate missing labels. Avoid adding ARIA where native HTML already communicates the correct role; redundant or contradictory attributes can make the result worse.

Finally test zoom, reduced motion, and a narrow viewport. A demo does not need to solve every assistive-technology edge case before review, but it should expose known limitations. That honesty lets reviewers focus on the important behavior instead of discovering an undocumented trap.

Build a keyboard path before polishing

List every action in the order a keyboard user should encounter it. Start at the address bar, press Tab repeatedly, and write down the focused control and the result of activating it with Enter or Space. This catches missing buttons, clickable div elements, and focus that jumps into hidden panels. Native elements are usually the shortest route to correct behavior: a real button already exposes a role, accepts keyboard activation, and participates in the focus order. Use ARIA to describe an unusual interaction, not to repair avoidable markup.

When an action opens a dialog, menu, or disclosure, decide where focus moves, how it returns, and what Escape does. A visual prototype can omit backend logic, but it should not invent a keyboard model that production cannot keep. If focus management is deliberately incomplete, say so beside the demo rather than letting reviewers assume the pattern is ready to ship.

Test names, state, and announcements

Inspect the accessibility tree in browser developer tools. Every control needs a useful accessible name, and repeated controls need names that distinguish them. “Delete” may be sufficient next to one record, but a table of icon-only delete buttons needs record context. State must also be exposed: expanded disclosures should update aria-expanded, selected tabs should communicate selection, and validation errors should be associated with the relevant input.

Do not use live regions for every visual update. Reserve them for information a screen-reader user would otherwise miss, such as an asynchronous save result. Keep the message concise and avoid replacing the live-region node repeatedly. Test with at least one real screen reader because the accessibility tree is evidence, not a complete simulation of the listening experience.

Apply pressure to the content

Zoom to 200 percent, increase the default font size, and replace short labels with longer text. The interface should reflow without hiding controls or forcing two-dimensional scrolling except for genuinely tabular content. Check forced-colors or high-contrast mode, reduced motion, and both light and dark color schemes. A focus ring that looks clear on your laptop can disappear when system colors replace the palette.

Run an automated checker, but treat its output as a starting list. Automated tools find missing names, invalid relationships, and some contrast failures; they cannot decide whether focus order makes sense or whether instructions rely on color. Record the browser, viewport, keyboard path, and assistive technology used so another reviewer can reproduce the result.

A practical handoff record

End the demo with a small test matrix: scenario, expected result, observed result, and known limitation. Include direct links to the relevant screen and the smallest steps needed to reach each state. If sample data is required, embed it safely in the artifact. A reviewer should not need private credentials or a verbal walkthrough.

The most useful accessible demo is not one that claims conformance. It is one that makes behavior inspectable, states what has been tested, and separates prototype shortcuts from production requirements. That evidence lets design and engineering discuss the same interaction instead of arguing from screenshots.