Screen Reader Guide

SCREEN READER FOUNDATIONS

0 of 20
Course progress: 0 / 20 lessons

LESSON 2 OF 20

Follow the information chain

What a screen reader presents begins with decisions in the product, passes through the platform accessibility layer, and is interpreted by the screen reader. A problem at any point in this chain can change or remove the information a user receives.

  • Reading: about 5 minutes
  • Knowledge check: 2-3 minutes
In this lesson

Trace screen reader information from the product to the user and identify where defects can enter the chain.

1. The product exposes meaning

The chain begins in the product. Interface code creates objects and gives them properties such as name, role, state, value, hierarchy, and relationships. On the web, native HTML elements provide much of this information automatically. A button element, for example, already exposes button behaviour. Native apps and embedded products use the components and accessibility APIs provided by their platforms.

  • A visible label can provide the accessible name of a control.
  • The element or component can provide a role such as button, heading, checkbox, or dialog.
  • Properties can expose states such as selected, expanded, checked, unavailable, or invalid.
  • Document structure can expose relationships between headings, regions, labels, instructions, and controls.
  • Application logic can communicate changes such as errors, loading states, and completed actions.

2. The platform creates an accessibility model

The browser or operating system translates the product's information into an accessibility model. This model is often called an accessibility tree. It is a structured representation that assistive technologies can query. It does not need to contain every visual element. Decorative images, layout containers, and hidden content may be excluded, while meaningful controls and text need useful properties and a logical position.

  • The platform calculates names and descriptions from labels, text, and accessibility properties.
  • It represents parent and child relationships, such as a list and its list items.
  • It records which object has input focus.
  • It sends events when focus, content, values, or states change.
  • It makes actions available so assistive technology can operate the product.

3. The screen reader interprets the model

The screen reader reads the accessibility model rather than simply examining pixels on the screen. It combines the available properties with its own rules, user settings, navigation mode, and current context. This is why two screen readers may phrase the same information differently while still communicating equivalent meaning.

  • It turns names, roles, states, and values into speech, braille, or sound cues.
  • It provides commands for moving by heading, link, control, landmark, list, table, or text.
  • It moves focus or activates an action when the user operates a control.
  • It responds to platform events and announces important changes.
  • It can omit, reorder, or shorten information according to user preferences.

A custom control through the chain

Consider a quantity selector in a checkout flow. Visually, it contains a minus icon, the number two, and a plus icon. If the icons are generic containers with click handlers, the product may expose no names or button roles. The accessibility model can then contain two unnamed objects, or exclude them entirely. The screen reader cannot infer that the controls decrease and increase quantity from their appearance.

  • The product should use native buttons where the platform provides them.
  • Each button needs a stable name, such as “Decrease quantity” and “Increase quantity.”
  • The current quantity needs a clear label and value.
  • After activation, the product must expose the new value or send an appropriate change event.
  • The screen reader can then announce the controls and communicate the result of the action.

Find where the chain broke

A screen reader defect is not always caused by the screen reader. Begin with the product and follow the information forward. Confirm that the intended meaning exists in code, inspect what the platform exposes, and then compare that information with the screen reader output. This method helps the team report the responsible layer instead of describing only the final symptom.

  • Check the semantic element, accessible name, role, state, value, and relationships.
  • Inspect the browser or platform accessibility tree.
  • Check focus order and the events sent after an interaction.
  • Compare the result with a native control that has similar behaviour.
  • Record the operating system, browser or app, screen reader, versions, commands, expected result, and actual result.

Semantics

Semantics describe what an object is and how it relates to surrounding content. Native elements and components usually provide stronger defaults than generic containers. Custom controls must recreate every property and behaviour that users need.

Accessibility APIs

Accessibility APIs connect products, platforms, and assistive technologies. Product code supplies information through platform mechanisms; the browser or operating system then makes a normalised model available to the screen reader.

Focus and events

Static properties are not enough for an interactive product. The chain must also communicate where focus moves and what changes after an action. Missing or badly timed events can leave the accessibility model correct but the user unaware of an update.

Environment differences

Browsers, operating systems, app frameworks, and screen readers do not all interpret information in exactly the same way. Test supported combinations, but first confirm that the product exposes valid information through the platform.

TRY THIS NOW

Trace one action through the chain

Use a familiar control from your product and record what each layer must contribute.

  1. ProductDefine the control's name, role, state, value, relationships, and operation.
  2. PlatformInspect how the browser or operating system represents that information.
  3. Screen readerCheck the information and actions available through the supported combination.
  4. User outcomeConfirm that the person can understand the control, operate it, and receive the result.

What to remember

A visual label is not enough if its meaning never reaches the accessibility model. Follow the information from product code to platform data to screen reader output.

Try this with your team

Choose one custom control in your product. Write down its intended name, role, state, value, relationships, and keyboard or touch behaviour. Inspect the accessibility model and compare it with what a screen reader presents. If something differs, identify the first point in the chain where the information becomes incorrect or disappears.

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.

1. A named visual control is announced only as “button.” Where should investigation begin?

2. Why are focus events important?

OPTIONAL HANDS-ON PRACTICE

Use these exercises to apply the lesson in a working interface, diagnose an intentional defect, review its relevance, and retest the repair.

  1. Name

    Accessible names

    Find an icon button that has no meaningful name and repair what a screen reader exposes.

    • Beginner
    • 5-10 minutes

  2. Role and state

    Custom checkbox or toggle

    Test a visual toggle that must expose its role, name, state, and keyboard behavior.

    • Beginner
    • 5-10 minutes

NEXT STEP

Continue to lesson 3: Navigate with different input models

Move on when you are ready. Your knowledge-check answers are not stored.