Is assistive technology able to accurately convey the page content and interaction to a user?

Listening to your web content rather than looking at it can be an “eye-opening” experience (pardon the pun) that takes sighted users out of their normal comfort zone. It gives sighted users a chance to evaluate their content from an entirely different perspective: from the perspective of a blind person. A lot of times you’ll end up finding mistakes that would have been hard to catch visually. For example, spelling mistakes become very obvious when you hear words mispronounced by the screen reader. Screen readers are also very good for checking the accuracy and quality of image alternative text. Screen readers can also help you identify problems with reading order, table markup, form elements, and many other aspects of accessibility.1

While this isn‘t a guide to using any particular screen reader (there are links to guides in the resources below), it is a walkthrough of what you should expect when using one. It should be noted that for the best results it‘s paramount to test with real users, with their own devices, in their own settings—if you‘re firing up a screen reader for the first time or just infrequently open one to test, your experience is guaranteed to fall far short of what an experienced user can accomplish, but that definitely doesn‘t mean you shouldn‘t try.

Contents

alt Tags

Alternative text is a critical attribute for conveying non-text content to screen readers, but it is also useful for when images don‘t load or for providing key information to search engines. It‘s also one of the more difficult accessibility items to address because of its subjectivity. What isn‘t subjective though is that every image should have an alt tag. Rather than hash out contextual examples here, there’s a great link in the resources below that does so.

What to Expect

These are general places to start, each image should be evaluated by its context.

  • Every image should have an alt tag
  • Images that are decorational or not key to the content should use a blank alt tag, i.e. alt="". Example: a horizontal SVG image used to divide content sections.
  • Images that are functional should have an alt tag that relates to the function. Example: An image of an arrow is used for paging forward and uses alt="next" to describe the function and not the visual.
  • Images that are part of the content should have alt tags that best explain them in the given context(external link)
  • In most cases logos do not need the word “logo” in the alt text
  • Using phrases like “image of…” or ”graphic of…” in the alt text should be avoided unless they are critical for explaining a feature or quality of the image
  • Background images are typically applied via CSS and cannot have an alt tag, so in that regard they should be considered decorational
  • Complex images, like charts or infographics should have the content within provided elsewhere. Alternately you can consider using SVG(external link).
  • Speaking of SVG, since they can be included inline, meaning not within an img element, there are other methods to make them accessible—look for title and desc elements within the SVG

Labels

Forms are often overlooked when it comes to accessibility. For sighted users it‘s easier to know what‘s expected for each form control and establish relationships. This is not the case for screen readers. Using the correct form control is one thing, but establishing clear expectations, order, relationships, explanations and error mitigation can be quite complex. This is where an effective use of labels and ARIA can help (learn about ARIA from links in the resources. Labels provide a 1:1 relationship with a form control and identify its purpose. We won‘t cover form design or development here, but generally what to expect when testing a form with a screen reader.

What to Expect

  • When a form control has focus there should be an associated label that describes the control
  • Groups of related form controls should have a legend that defines the group (depending on the screen reader this may or may not be read)
  • Descriptions should be provided for form controls that require formatting or other explanation and associated with the control via aria-describedby
  • Custom form controls should behave and be read by screen readers in the same way as native controls

Calls to Action

Although headings are one of the most common way screen reader users navigate, many also do so by viewing a list of the links within a page (WebAIM Screen Reader User Survey 7 Results(external link)). In this regard, a call to action should let users know what to expect when the action is taken or a link is followed, e.g. “Discover more about the app“ is more clear and concise than “Read more.“ Can you imagine trying to navigate based on a list of “click here“ or “read more“ links? It‘s not very useful.

Repeated call to action labels often make sense for visual users when the layout associates each with its own content block. When this is the case consider using aria-label or aria-describedby on the call to action to provide context for screen readers.

What to Expect

  • A call to action should clearly communicate what the result of that action will be, e.g. to submit a form or to follow a link
  • Calls to action with similar labels should leverage ARIA to add context
  • Calls to action should be focusable, using button and anchor elements
  • External links or actions that will change the page layout should be marked as such so that a user doesn’t unexpectedly find themselves in a place

Structure and Landmarks

Good, semantic page structure is one of the best things you can do for screen reader users. A combination of semantic HTML5 elements(external link), ARIA roles(external link), and hierarchy (like nested headings) provides users with a varierty of ways to scan and quickly traverse content.

What to Expect

  • Semantic HTML5 elements are used
  • ARIA roles help describe elements when the function or purpose would otherwise be indeterminate
  • The structure of elements in the DOM is logical

Changing States

When navigating the web for any short amount of time you’re sure to encounter dynamic content. Things like pop-ups, notifications, carousels and accordions are commonplace, but how does a screen reader know these items exist and are changing? Often times they don’t. In all of these cases a screen reader user should also be able to understand what is changing, what is new and how to address errors—like missing information in a form.

What to Expect

  • Notifications, alerts or time-based content should use aria-live regions to indicate to a screen reader that content has been introduced or changed
  • When submitting a form a user must know that errors exist, how to mitigate them and where on the page to go to do so
  • Components that change states with user interaction should communicate the change, e.g. expanding a dropdown menu or accordion
  • In most cases a user should be able to easily change back to the previous state, e.g. closing a modal window or collapsing an accordion

Resources

References