What a screen reader does
A screen reader is software that turns on-screen content into speech or braille. A user typically moves through the interface with a keyboard, a set of gestures or a switch device, and the software announces what is in focus: a heading, a button, a paragraph of text. People who are blind use screen readers, as do some people with low vision, dyslexia or other reading difficulties.
The software does not “see” the screen as a picture. It reads a structured description that the interface provides, which is sometimes called the accessibility tree. When that description is complete and accurate, the user hears something sensible. When it is missing, the user may hear nothing, or a stream of meaningless fragments. That is the heart of the matter: support depends on what the interface offers to the software, not on how it looks.
Where screen readers meet exhibits
Exhibit interfaces take several forms, and the situation differs for each.
- Web-based exhibits and collection pages. These tend to be the easiest to support, because browsers and screen readers already work together and published web guidelines are well established. Our discussion of collection portals and a virtual exhibition looks at these formats.
- Visitor phones. If an exhibit is delivered through a phone, visitors may use the built-in assistive tools they already know. The choice between a web page and an app, covered in web or app, affects how well those tools work.
- Fixed touchscreens and kiosks. These are the hardest. A screen reader on a public kiosk requires a way to start it, headphones or a handset for private listening, and a non-visual way to navigate. Many touchscreen exhibits have none of these, so a blind visitor cannot use them independently.
Where an on-site screen cannot be made fully accessible, a good fallback is an equivalent route: an audio version, a tactile object or a companion web page. This should not be an afterthought, and it should be tested.
What the interface needs to provide
These requirements are general. Developers should consult the published guidelines relevant to their platform.
Meaningful structure
Headings should be real headings, in a logical order, so that a user can jump through them. Lists, tables and regions should be marked up as what they are. A page made entirely of styled boxes with no structure is a flat, confusing stream in speech.
Names for everything interactive
Each button, link and form control needs a clear name that makes sense out of context. A button labeled only with an icon needs a text label for the software. Words such as “click here” or “more” mean nothing when announced alone, so use specific names such as “Play the harbor recording.”
Text alternatives for images
Informative images need a short description of what they show and why it matters. Decorative images should be marked so that they are skipped. Complex images, such as maps or diagrams, may need a longer description nearby. The wider craft of describing visuals is covered by audio description, and the descriptions can often be reused. Good collection metadata also provides a base for image descriptions.
A sensible focus order
The order in which the software moves through controls should match the visual and logical order. Focus should be visible, and it should never get trapped in a pop-up or a carousel. When content changes, for example when a dialog opens, the focus should move there, and return afterward.
Keyboard and switch operation
Everything that can be done by touch or mouse should also be possible with a keyboard or equivalent. Screen reader users rely on this. It also benefits people who cannot use a pointing device at all. Avoid actions that need a particular gesture, a hover or a precise drag with no alternative.
Announcements for changes
If part of the screen updates, such as a quiz result, a loading message or an error, the software needs to be told. Live regions are the standard way on the web. Without them, a user may not know that anything happened.
Time and motion
Do not impose short time limits or auto-advancing content that a user cannot pause. Avoid moving or flashing elements that disrupt reading; the same care described for sensory friendly design applies.
Media
Video needs captions and a transcript, and descriptions of visual content for blind users. Auto-playing audio can clash with the screen reader’s speech, so avoid it or make it easy to stop.
Common pitfalls
- Text embedded in images with no alternative.
- Custom controls built from non-standard elements that software cannot recognize.
- Overlays and pop-ups that capture focus.
- Interactions that work only by dragging or by hovering.
- Different languages not marked up, which causes the voice to mispronounce text; see language switching.
Test with the software and with people
Automated checkers can find some problems, such as missing labels, but they cannot tell whether the experience makes sense. A developer can try the main screen readers available on common platforms and try moving through the interface with eyes closed or the screen turned off. Better still, ask blind users to attempt realistic tasks and watch where they struggle. Plan for this early, because making structure right at the start is far easier than adding it later. An accessibility checklist for the project should list these items, and a short test with real users after launch can catch what the checklist misses.
Keep expectations realistic. Different software and browsers behave differently, and no interface is perfect for everyone. Clear structure, good names, equivalent routes and willingness to improve will take most exhibits a long way.