How to Use Screen Readers

It is a good idea to try out screen reader navigation yourself. I would recommend figuring out how to both turn on and off the screen reader. There's a lot of talking.

Mac

• Turn VoiceOver on or off
• Keyboard shortcuts for VoiceOver
• Show captions (Please use this in the workshop)

Windows

• You turn Narrator on and off by pressing Windows+Ctrl+Enter
• Keyboard shortcuts for Narrator
• If anyone figures out how to get Narrator to show captions, please tell us.

Linux

• 🤷

Things to Test

Navigation and Overview

Sighted users open the page and get an overview right away. Screen reader users can use shortcuts to quickly read headers or main sections.

• When you open the page with a screen reader, one of the first things said is: "Title". Why? Hint
• Try to get an overview of the page by navigating via landmarks or headings. Hint
• Can you expand the different rockets using a screen reader? Hint
• When you start navigating, you have to tab through the entire header before getting to the juicy stuff. Screen reader users should be able to skip to the main content. Hint
• Open the purchase modal. A sighted user will have context with "Payment and delivery info for the rocket," but does Bethany get any context from the screen reader? Hint
• Open the modal and tab around. Can the cursor leave the modal? Hint
• Try to close the modal without purchasing. Hint

Interaction

• Tab through the input fields in the modal. How do you know what to write in each field? Hint
• How can a blind person know that "name" is required? Hint
• Click buy without filling anything out, so you get a validation error. How do you find out about this using a screen reader? Hint
• This isnt really a test, but click this hint for a bit of information about forms. Hint
• Okay, the progress bar is pretty pointless in this case, but it's used in many other cases so bear with me. How will a screen reader read the progress bar and will it be able to get any information from it? Hint

Reading and Images

• Tab through the images. What information do you get? Hint
• Do you really need information about the K in the bottom right corner? Hint
• How will this sentence be read by the screen reader on a Mac? Hint
• Have you fixed the previous list item? Can the screen reader understand that the hint is a link? Hint

Notes

WAI-ARIA

Web Accessibility Initiative - Accessible Rich Internet Applications, or just Aria, is a set of attributes you can add to your HTML tags to provide information to the Accessibility API (which is what screen readers use).

These are powerful tools that should be used where needed. However, they should be used where needed and not just added to be on the safe side. Ideally, you should write semantic HTML so that they are not needed, but in certain cases, you will need to use them. Having many ARIA attributes in the code is actually a code smell, as it indicates that you need to use ARIA to try to fix problems instead of writing good HTML.

Aria-hidden

Aria-hidden is an example of this. The attribute is often added to all hidden elements just to be on the safe side, but it is not needed if the element is hidden using display: none, visibility: hidden, or the HTML hidden attribute. Adding aria-hidden: true in these cases provides no additional information to the screen reader, but it increases the likelihood of errors if, for example, visibility: visible is set without setting aria-hidden: false.

Semantic HTML

h-tags

h1/h2/h3/h4/h5/h6 tags must follow the structure. If your parent is an h1, then you should be an h2, even if the design may suggest that you should look like an h3. Here you must first set up the semantic structure, and then you can style afterwards. Designers must also consider this ;)

Relevant Requirements

• 1.1.1 - Provide users with a text alternative for non-text content.
• 1.3.1 - Things should be coded as they appear.
• 1.3.2 - Present content in a meaningful sequence.
• 1.3.3 - Instructions must not rely solely on shape, size, visual location, orientation, or sound to be understood.
• 1.3.5 - Form elements are coded with input purpose.
• 1.4.1 - Do not use presentation that relies solely on color.
• 1.4.5 - Use text instead of images of text.
• 2.1.1 - All functionality must be operable via keyboard only.
• 2.1.2 - Avoid keyboard traps.
• 2.4.1 - Provide users with the ability to skip directly to main content.
• 2.4.2 - Use helpful and clear page titles.
• 2.4.3 - Present content in a logical sequence (focus order).
• 2.4.4 - Clearly indicate the target and function of all links in the link text.
• 2.4.6 - Ensure that labels and headings are descriptive.
• 3.1.1 - Ensure that the language of content on all web pages is specified in the code.
• 3.1.2 - Ensure that all parts of content that are in a language different from the rest of the page are marked in the code.
• 3.3.1 - For errors detected automatically, show where the error occurred and provide a text description of the error.
• 3.3.2 - Display labels or instructions when form elements need to be filled out.
• 4.1.2 - All components have name and role determined in the code.
• 4.1.3 - Users should receive status messages about important changes on the website without causing a change in context.