Key takeaways
- Keyboard access and screen reader compatibility are the two fixes with the widest reach. If a page fails either one, many users with disabilities cannot complete a task at all.
- Screen reader users rely on several tools. In WebAIM’s Screen Reader User Survey #10, JAWS (40.5%) and NVDA (37.7%) led as primary desktop screen readers, and 91.3% of respondents also used a screen reader on a mobile device, most often VoiceOver.
- Keyboard testing is free and fast: unplug the mouse and try to reach and operate everything with Tab, Shift+Tab, Enter, Space, Escape and the arrow keys.
- Most screen reader problems trace back to markup: missing alt text, unlabeled buttons and form fields, fake headings and custom widgets without proper roles.
- Fix shared components first, test with real assistive technology and skip overlay widgets, which do not repair the underlying code.
If your website passes only two accessibility tests, make them these. Can someone move through every page and complete every action with only a keyboard? Can a screen reader announce every element in a way that makes sense? People who are blind, have low vision, have motor disabilities or use switch devices and voice control depend on both. This Emulent guide explains what each test checks, how to run it, how to fix what you find and why the work also supports SEO and conversions. It is general guidance, not legal advice.
What does keyboard accessibility require?
Every interactive element must work without a mouse, in a logical order, with a visible indicator showing where focus is. These requirements come from WCAG 2.1 Level AA, the standard most courts and regulators reference.
- Reachable: links, buttons, menus, form fields, tabs, accordions, carousels and modals can all be reached with Tab and Shift+Tab.
- Operable: Enter activates links and buttons, Space toggles checkboxes and buttons and arrow keys move within menus, tabs and radio groups.
- No traps: focus can always leave a widget. Modals close with Escape and return focus to the button that opened them.
- Visible focus: a clear outline or highlight on the focused element. Removing the browser’s default outline without a replacement is one of the most common failures.
- Logical order: focus follows the visual reading order instead of jumping around the page.
- Skip link: a “Skip to main content” link lets keyboard users bypass long navigation menus.
- Not hidden: under WCAG 2.2, sticky headers, cookie banners and chat bubbles must not cover the focused element.
What does screen reader compatibility require?
A screen reader converts the page’s underlying code into speech or braille. It can only announce what the markup tells it, so compatibility depends on semantic HTML and accurate labels.
| Requirement | What it means |
|---|---|
| Alt text | informative images describe their content or function; decorative images use empty alt text so they are skipped. |
| Accessible names | icon-only buttons such as search, cart, menu and close have text labels a screen reader can announce. |
| Real headings | section titles are coded as H1 to H6 in a logical order, since many users jump between headings to scan a page. |
| Landmarks | header, nav, main and footer regions let users jump straight to the part of the page they want. |
| Form labels | every field has a programmatically tied label, and error messages are announced when they appear. |
| Roles and states | custom menus, toggles and tabs announce what they are and whether they are expanded, selected or checked. |
| Status messages | updates such as “Added to cart” or “3 results found” are announced without moving focus. |
| Descriptive links | link text makes sense out of context; ten links that all say “Learn more” do not. |
The 2026 WebAIM Million report found missing alt text on 53.1% of top home pages and missing form labels on 51.0%, both direct screen reader blockers.
How do you test keyboard and screen reader access?
Pick your main templates and the tasks that make you money, such as a contact form, booking flow or checkout, and test each one by hand. Automated tools help but cannot confirm either test on their own.
- Keyboard pass: put the mouse away, press Tab from the top of the page and complete each task. Note anything you cannot reach, cannot see focus on, cannot operate or cannot leave.
- Screen reader pass on desktop: NVDA is free on Windows and VoiceOver is built into Mac. Pair NVDA with Chrome or Firefox and VoiceOver with Safari.
- Screen reader pass on mobile: VoiceOver on iPhone and TalkBack on Android, swiping through each page and activating controls.
- Listen for gaps: unlabeled buttons, images announced as file names, form errors that are never spoken and menus that do not say whether they are open.
- Automated support: run WAVE, axe DevTools or Google Lighthouse to catch missing labels and alt text quickly before the manual pass.
- Record each issue with the page, the steps, the WCAG criterion and a screen recording, so developers can reproduce it.
How do you fix keyboard and screen reader problems?
Start with native HTML elements and shared components. A real button element is keyboard-operable and announced correctly by default; a styled div is neither.
- Replace clickable divs and spans with button and a elements.
- Restore visible focus styles in the theme’s CSS and make them match your brand.
- Add text labels or aria-label values to icon buttons, and visible labels to every form field.
- Use ARIA only when native HTML cannot do the job, and follow the W3C’s ARIA Authoring Practices patterns for menus, tabs and dialogs.
- Manage focus in modals and single-page interactions so users are not left stranded.
- Fix shared templates first: header, navigation, product cards and forms repeat on every page.
Do not reach for an overlay. UsableNet counted more than 1,400 lawsuits in 2025 against companies that had accessibility widgets installed. The same fixes help search, too: alt text, real headings and descriptive links give search engines and AI answer engines stronger signals, which supports your SEO. On WordPress sites, most of these changes are made once in the theme or element settings and carry across the site.
How the Emulent team can help
Emulent tests websites by keyboard and with NVDA, VoiceOver and TalkBack, alongside automated scans, and turns every finding into a fix your developers can act on. Our website design team can rebuild menus, forms and custom components so they work for keyboard and screen reader users, and build accessibility into new projects from the start. Results depend on each site’s code and content. To see how your website performs, contact the Emulent team.