Designing for keyboard and screen reader users (plain language)

Why keyboard and screen readers matter

Some people cannot or prefer not to use a mouse. They use the keyboard to move focus from link to link, button to button, and field to field. Some people use a screen reader: software that reads the page aloud (or via braille) so they can navigate and understand content [1]Source 1 .

If your site only works with a mouse, or if the structure and labels do not make sense when read aloud, you lock those users out. Designing for keyboard and screen readers is not a niche extra; it is part of making your site usable for more people.

What keyboard users need

Everything reachable by keyboard

Every link, button, and form field must be reachable using the Tab key (and Shift+Tab to go back). If something is “clickable” only with a mouse (e.g. a div that looks like a button but is not a real button), keyboard users cannot use it.

Visible focus

When you press Tab, you need to see where you are. There should be a clear focus indicator (e.g. a ring or outline) around the focused element. Do not remove it with CSS unless you replace it with something equally visible.

Logical order

Focus should move in an order that matches the visual layout and the way people read (e.g. top to bottom, left to right in English). If the tab order jumps around randomly, keyboard users get lost.

No keyboard traps

Users must be able to Tab out of every component (e.g. menus, modals, accordions). If focus gets stuck inside something with no way to leave, that is a keyboard trap.

What screen reader users need

Semantic structure

Headings (h1, h2, h3…) and landmarks (nav, main, footer) let screen reader users jump to sections and understand the page outline. Use real headings in order; do not skip levels (e.g. h1 then h4).

Meaningful labels

Links and buttons must have text that describes what they do or where they go. “Click here” or “Read more” is unhelpful when read in isolation. “Contact us” or “Read about our accessibility policy” is clear.

Form fields need visible labels that are associated with the input (e.g. with for and id), so the screen reader can announce “Name, edit text” or “Email, required, edit text”.

Announcements for dynamic content

When something changes on the page (e.g. an error message appears, or a filter updates a list), screen reader users need to be told. That usually means using live regions (e.g. aria-live) or moving focus to the new content where appropriate [3]Source 3 .

How to check your site

• Unplug the mouse: Use only the keyboard to open your site, move through the homepage, open a menu, submit a form, and close a modal. If you get stuck or lost, you have found a problem.
• Watch the focus: As you Tab, does focus appear somewhere visible? Does the order make sense?
• Try a screen reader: VoiceOver (Mac) or NVDA (Windows) are free. Turn one on and listen to your page. Can you find the main content, understand links and buttons, and complete a form?
• Get an audit: For a full picture, commission an accessibility audit that includes keyboard and screen reader testing [2]Source 2 .

For more on what to ask suppliers, see we build accessible sites: show me your process and what accessibility means: a plain language definition.

Summary

Keyboard users need every interactive element reachable by Tab, visible focus, logical order, and no traps. Screen reader users need clear structure, meaningful link and button text, proper form labels, and announcements when content changes. Test with the keyboard and with a screen reader yourself, and get an audit when you need a full picture.