Structure
Headings and landmarks
Navigate a page by structure and find content that is only visually organized.
Course progress: 0 / 20 lessons
LESSON 7 OF 20
Describe each reader consistently
A useful screen reader profile explains more than availability and price. It connects the reader's environment, input, navigation, output, and distinctive behaviour to product decisions and reproducible testing.
In this lesson
Research and document a screen reader with a repeatable structure that separates facts, observations, and recommendations.
Why a consistent profile matters
Screen-reader information is often scattered across platform documentation, support articles, release notes, training material, and community discussions. Without a consistent structure, teams collect interesting facts but cannot compare environments or turn research into test coverage. A profile should help a new team member understand where the reader is available, how people operate it, and what the product team must verify.
- State the environment before describing commands or behaviour.
- Separate built-in platform facts from product-team recommendations.
- Label information that depends on a version, browser, device, or setting.
- Use primary documentation for factual claims where it is available.
- Credit experienced users when their observations inform the profile.
Build the profile around real tasks
A command list alone does not explain how a screen reader feels in use. Connect features to representative tasks such as finding a heading, completing a form, choosing media, editing text, or recovering from an error. This reveals which commands, modes, and platform behaviours matter to the product.
- Describe how the user starts and stops the screen reader.
- Explain how the user discovers structure and moves between objects.
- Identify how focus, reading position, and interaction modes work.
- Include speech, sound, braille, and visual focus options where relevant.
- Record how the user returns after an overlay, route change, or mistake.
Compare without creating a ranking
A comparison should show meaningful differences, not declare one screen reader universally better. Products serve different platforms, workflows, languages, procurement settings, and user preferences. Compare readers only where the same question applies, and explain when a comparison would be misleading.
- Compare supported environments and input methods before individual features.
- Use the same representative task for both products.
- Distinguish missing product information from different screen reader phrasing.
- Do not use one tester's preference as a general user conclusion.
- Avoid popularity claims without current and relevant evidence.
Keep profiles maintainable
Screen readers and platforms change. Add a review date, source links, tested versions, and a clear owner. Update the profile when a platform changes navigation, speech behaviour, supported devices, or accessibility APIs. Keep stable concepts separate from version-specific commands so that a small release does not make the complete document appear obsolete.
Show evidence with a short scenario
End the profile with one short scenario that connects the sections. For example, describe how a user opens a banking app, finds transfer history, filters the list, reviews a transaction, and returns. Record the important commands, announcements, focus changes, and platform constraints. This makes the profile useful to product teams without presenting one scripted journey as the only way experienced users work.
Identity
Record the developer, history, current status, licence model, supported languages, installation method, and official documentation. Explain whether the reader is built in, free to install, commercially licensed, or tied to specific hardware.
Environment
List operating systems, devices, browsers, native apps, WebViews, and relevant version boundaries. Include combinations that the platform recommends and note where embedded web content introduces another accessibility layer.
Input and output
Describe keyboard, touch, voice, braille, speech, tones, and visual focus support. Explain the primary input for each environment instead of combining substantially different platforms into one generic workflow.
Navigation model
Explain how users move by object, structure, text, space, or application-specific modes. Include how they enter interaction, return to navigation, locate the current item, and recover when context changes.
Distinctive behaviour
Document features and concepts that differ meaningfully from other screen readers. Include them because they affect a task or test result, not merely because they exist.
Product implications
Translate research into questions for design, development, content, testing, and product support. Keep recommendations proportional to the product's supported environments and user needs.
Testing
Define representative tasks, setup, combinations, commands, limitations, and reproducible reporting. State what the test can establish and what still requires research with experienced users.
Sources
Prefer primary platform documentation and release information. Clearly label community knowledge, personal observations, and unresolved behaviour. Add access or review dates when the information can change.
TRY THIS NOW
Create one maintainable profile entry
Choose one screen-reader environment and complete these four fields. Keep verified facts separate from team observations.
- EnvironmentName the product, platform, device, input methods, relevant versions, and review date.
- Navigation modelDescribe how a person explores structure, moves focus, operates controls, and recovers.
- Product implicationsConnect the model to design, implementation, content, and testing decisions.
- EvidenceCite primary documentation and label observations, user evidence, and unresolved behavior.
What to remember
A useful profile connects verified platform facts to real tasks and product implications. Keep recommendations, user observations, and version-sensitive information clearly labelled.
Try this with your team
Select one screen reader that matters to your product. Create a profile with the eight headings above and one representative task. Mark each statement as a platform fact, team observation, user observation, or recommendation. Add sources, versions, a review date, and an owner.
Knowledge check
Answer every question, then use the forward lesson button to record this lesson as complete. The check is not scored and can be repeated.