Start with a task, not the whole website
Screen readers announce text and information about page elements, allowing people to navigate and interact without relying on sight. Testing with one can reveal problems that are easy to miss when you look at a page: an image button with no name, a confusing heading structure, or a form error that is never announced. It is a useful check, but one quick test cannot tell you whether a site works for every screen reader user.
Choose one common task for your first session. For a small community organization, that might be finding opening hours and sending a contact form. Write down what success looks like: starting on the home page, finding the contact page, completing the form, and understanding whether it was sent. Keep a list of the pages involved so you can repeat the same journey after making changes.
Prepare a simple, repeatable test setup
Use a screen reader available on your computer, such as VoiceOver on macOS or NVDA on Windows, with a browser you can use consistently. Follow that screen reader’s introductory instructions before testing the site. Learn how to start and stop speech, move to the next item, navigate by headings, and move through interactive controls. Commands differ between tools, so keep the relevant help guide nearby rather than guessing.
Test with the keyboard as well as the screen reader. Tab usually moves between interactive elements, Shift+Tab moves backward, and Enter or Space often activates a focused control; the exact behavior depends on the control. Keep sound on and, for at least part of the test, avoid looking at the page. The aim is not to imitate every user’s habits. It is to notice where the spoken information and keyboard path do not give you enough to proceed.
Explore the page before completing the task
Start at the top of a page and listen to its title, headings, links, and other content in order. Then use heading navigation to get a sense of the page’s structure. Can you identify the main topic and find the section you need? A page with headings chosen only for their visual size may sound disorganized. If several links are announced as “Learn more,” ask whether each link makes sense when heard without the surrounding paragraph.
Next, move through the interactive elements in keyboard order. Notice whether the navigation, search, buttons, and links have clear names. Check whether a keyboard user can tell which element has focus; you may need to look at the screen for this part. If a menu opens, can you reach its options and leave it without getting stuck? Record the exact page and element when something is confusing, rather than writing a broad note such as “navigation is inaccessible.”
Complete the journey and check what happens when it goes wrong
Now attempt the task you chose. For a contact form, listen to each field’s announced name and any instructions before entering information. Can you tell which fields are required? Do radio buttons, checkboxes, and submit controls make their purpose clear? If a form uses a visual cue such as an asterisk or a red border, check whether the same meaning is available through text and screen reader output.
Test an error deliberately, such as submitting the form with a required field empty. Listen for a clear explanation of what needs fixing, and check whether you can find the affected field again. Then try a valid submission if you can do so without creating an unwanted message or record. Confirm that the result is understandable: a success message should be available as text, not conveyed only by a color change or an icon.
Turn observations into fixes you can verify
For each issue, note the task, page, browser and screen reader, steps to reproduce it, what you expected, and what you heard or experienced. For example: “On the contact page, the submit button is announced as ‘button’ with no name.” This gives the person making the change a useful starting point. Prioritize barriers that prevent completion of the task, then problems that make it slow or confusing.
After a fix, repeat the same steps rather than assuming the change worked. Also check that it did not create a new problem elsewhere in the journey. Screen reader testing is most valuable as a regular part of editing and publishing, not a one-time exercise. Pair it with keyboard checks, other accessibility checks, and feedback from people who use assistive technology when possible; each approach can uncover issues the others miss.
