How to Test Your Website With a Screen Reader

Choose and Install a Screen Reader

For Windows, install NVDA (NonVisual Desktop Access) from nvaccess.org. NVDA is free, open source, and used by a significant portion of screen reader users worldwide. Pair NVDA with Firefox for the most accurate representation of how your site behaves for screen reader users, because Firefox's accessibility implementation is the most thoroughly tested with NVDA. NVDA also works with Chrome and Edge, so testing across browsers is straightforward.

For macOS, VoiceOver is already installed. Activate it with Command+F5. VoiceOver pairs best with Safari, which is Apple's recommended combination and the one most Mac and iOS users rely on. Testing with VoiceOver and Safari is essential because Safari's WebKit engine handles accessibility tree generation differently from Chromium and Firefox, and VoiceOver has its own interpretation patterns that differ from NVDA and JAWS.

For comprehensive testing, use both NVDA with Firefox and VoiceOver with Safari. These two combinations cover the three major rendering engines (Gecko, WebKit, and indirectly Blink through your automated testing) and the two most commonly used free screen readers. JAWS with Chrome is the third important combination, but JAWS costs approximately $1,000 per license, so prioritize it only if your audience analytics show significant JAWS usage.

Before testing your site, spend 15 to 30 minutes practicing with the screen reader on a familiar website. Navigate a few pages, read content, interact with forms, and get comfortable with the audio output and navigation commands. Screen reader testing is disorienting at first because you are receiving information through a completely different channel than you are accustomed to. A brief practice session makes your actual testing more productive.

Learn Essential Navigation Shortcuts

NVDA uses the Insert key as its modifier key (called the NVDA key). In browse mode (the default for reading web pages), you navigate with single-letter shortcuts. Press H to jump to the next heading, Shift+H for the previous heading. Press 1 through 6 to jump to headings of that specific level (2 for the next h2, 3 for the next h3). Press D to jump to the next landmark region. Press K for the next link, F for the next form field, B for the next button, T for the next table, and L for the next list. Press Tab to jump to the next focusable element (links, buttons, form fields). Press Enter to activate a link or button.

VoiceOver on macOS uses the Control+Option combination as its modifier (called the VO key). Press VO+Right Arrow to move to the next element, VO+Left Arrow for the previous element. Use the Web Rotor (VO+U) to open a navigation panel where you can browse by headings, links, landmarks, form controls, and other element types, using arrow keys to select an item and Enter to jump to it. Press VO+Space to activate the current element (equivalent to clicking it). Press Tab to move between focusable elements, just like keyboard navigation without VoiceOver.

Both screen readers have a "forms mode" or "focus mode" that activates when you enter a form field. In this mode, keyboard input goes to the form field rather than being interpreted as navigation shortcuts. NVDA switches automatically when you Tab into a form field and switches back when you Tab out. VoiceOver uses VO+Shift+Down Arrow to enter a group (like a form) and VO+Shift+Up Arrow to exit it.

The most important command for testing is the one that reads the current element: NVDA+Tab reads the current focus element, and VO+F5 reads the current item in VoiceOver. Use these to verify what the screen reader thinks it is looking at, checking the element's role, label, and state.

Test Page Structure and Navigation

Start by listening to the page title. When the page loads, the screen reader should announce the page title (from the title element). Verify that the title is descriptive and unique, distinguishing this page from other pages on the site. If the screen reader announces a generic title like "Home" or your company name with no page-specific context, the title needs improvement.

Navigate by headings using H (NVDA) or the Web Rotor (VoiceOver) to hear the page's heading structure. The headings should form a logical outline of the page content, with one h1 describing the page topic, h2 elements for major sections, and h3 elements for subsections. Listen for skipped levels (jumping from h2 to h4), which confuse screen reader users about content hierarchy. Listen for headings that are too vague ("Section 1") or too similar ("Learn More," "Read More") to be useful for navigation.

Navigate by landmarks using D (NVDA) or the Web Rotor landmarks list (VoiceOver) to verify the page has proper landmark regions. You should hear a navigation landmark, a main content landmark, and footer/contentinfo landmark at minimum. If the page has multiple navigation regions (main nav and footer nav), each should have a distinct label (announced as "Main navigation" versus "Footer navigation"). If no landmarks are announced, the page lacks semantic landmark elements or ARIA landmark roles.

Navigate by links using K (NVDA) or the Web Rotor links list (VoiceOver) to hear all links on the page. Listen for links whose text does not describe their destination: "click here," "read more," "learn more," and "link" are all uninformative when heard out of context in a links list. Each link should make sense on its own without surrounding context, because screen reader users often navigate by pulling up a list of all links on the page and scanning that list to find what they need.

Test Forms and Interactive Elements

Tab through every form on the page. When focus lands on each form field, listen for the field's label. The screen reader should announce what the field is for: "Email address, edit text" or "Country, combo box, collapsed." If it announces just "edit text" or "combo box" with no label, the field lacks a programmatic label association. If it announces a different label than what is visually displayed next to the field, the programmatic association is pointing to the wrong element.

Test required field indicators. When a required field receives focus, the screen reader should announce it as required. Listen for "required" in the announcement. If required fields are indicated only by visual asterisks without the required attribute or aria-required="true" on the input, screen reader users have no way to know which fields are mandatory until they submit and get errors.

Submit a form with intentional errors and listen to the result. When validation errors appear, the screen reader should either announce the errors automatically (through an ARIA live region or alert role), or focus should move to the first error or an error summary. If errors appear visually but the screen reader says nothing and focus stays where it was, the error handling is not accessible. When you Tab to a field with an error, the error message for that specific field should be announced alongside the field's label.

Test custom interactive components like dropdown menus, date pickers, tabs, accordions, and modal dialogs. Each should announce its type (role), current state (expanded, collapsed, selected), and available actions. A dropdown should announce "Menu button, collapsed" when closed and "Menu button, expanded" when open. An accordion should announce "Details section heading, collapsed" when closed. Tab panels should announce which tab is selected and which panel is displayed. If a custom component reads as "div" or "span" with no role information, it lacks the ARIA attributes needed for screen reader compatibility.

Test Dynamic Content

Open a modal dialog and verify three things. First, when the modal opens, focus should move to the modal (typically to the modal's heading, its first focusable element, or the close button). If focus stays behind the modal, the screen reader user has no indication that a modal appeared. Second, while the modal is open, Tab and Shift+Tab should cycle only through the elements inside the modal, not reaching the page content behind it. If the user can tab to elements behind the modal, focus is not properly trapped. Third, when the modal closes, focus should return to the element that triggered it (the button or link that opened the modal).

Trigger notifications and toast messages. When a notification appears, the screen reader should interrupt to announce it (for urgent messages using aria-live="assertive" or role="alert") or announce it when it finishes its current speech (for non-urgent messages using aria-live="polite" or role="status"). If the notification appears visually but the screen reader says nothing, the notification container lacks the appropriate ARIA live region attributes.

Test accordion and tab interfaces. Expanding an accordion section should make the revealed content available to the screen reader immediately. The trigger button should update its announced state from "collapsed" to "expanded." Switching tabs should update the active tab's state to "selected," make the corresponding panel's content available, and ideally move focus to the panel content so the user can begin reading immediately.

Test content that loads dynamically via AJAX or infinite scroll. When new content appears on the page without a full page reload, the screen reader user needs some indication that content has changed. This can be accomplished through an ARIA live region that announces "Results updated" or similar, through focus management that moves the user's position to the new content, or through a status message announcing the number of new items loaded. If dynamic content appears silently, the screen reader user is unaware that anything happened.

Document and Prioritize Findings

Record each issue you find with the page URL, a description of the problem, the element or component affected, the screen reader and browser combination used, and the WCAG criterion it violates. Include what the screen reader actually announced versus what it should have announced, because this context helps developers understand the user experience impact and implement the correct fix.

Categorize findings by severity. Critical issues prevent task completion entirely, such as a form that cannot be submitted because the submit button is not keyboard-accessible, or a login flow where the password field has no label and the user cannot tell what to type. Serious issues make tasks significantly harder, such as confusing link text that requires the user to explore surrounding content to understand each link's purpose. Moderate issues cause inconvenience, such as headings that skip levels, making navigation less efficient but not preventing task completion. Minor issues have small impact, such as a decorative image that has uninformative alt text rather than empty alt text.

Prioritize remediation starting with critical issues, then serious, then moderate. Within each severity level, prioritize issues that affect the most common user workflows: login, registration, checkout, and core feature interactions. Fix template-level issues before page-specific content issues, because template fixes resolve the problem across every page that uses that template.