Screen readers

Screen reader order of precendence for interpreting content

Whether you build a widget as a web component using standards, Vue, React, or any other framework, or with a combination of HTML and JavaScript, screen readers that encounter your widget will look for clues in the rendered markup to discern what it is and tell users that they’ve encountered a search box, menu, or carousel.

Screen readers generally follow this order of precedence:

  1. Look for explicitly set ARIA attributes (roles, states, properties), and in the absence of those:
  2. Interpret any implicit roles from markup semantics (form elements, paragraphs, lists, etc).
  3. Read any text available in the markup.

If no discernable semantics exist (think ARIA-less <div> or <span> tags), it skips to #3. So when you omit ARIA, you’re rolling the dice on whether users will understand that your <ul> is a menu and not simply a list. When you omit ARIA and semantic tags, you’re leaving it up to your users to figure things out (and potentially abandon your product because it doesn’t work).

Accessibility issues with toasts and how to mitigate them

You may have recently read Adrian Roselli’s Scraping Burned Toast, Chris Coyier’s summary of the current “toast conversation”. Or maybe you’ve browsed the GitHub repository for A Standard ‘Toast’ UI Element and its WICG discussion thread.

Or maybe you’re familiar with the concept of toasts from Android development and Material Design.

But regardless of how familiar you are with the concept of a “toast”, work has been progressing on try to pave the existing cow paths different UI library definitions have set for said potential component. Unfortunately, the level of concern given to the accessibility and inclusive UX of a toast component varies quite a bit, depending on which component library you review.


Defining a toast


At a high level, toasts should be used to indicate the completion of a task or process initiated by the user or the application itself. For instance, a notification verifying the saving of a file, that a message had been properly sent, or a that a meeting was about to start.

If someone were to ignore, or miss a toast message, due to its timed display, there should be no negative impact on their current activities or the status that the message conveyed. Using the previous examples, ignoring a toast message would still mean that a file was saved, that a message was sent, or that a meeting was about to start.


Inclusive UX of a toast

A toast component should be considered a type of status message, and thus should be given a role="status". This will ensure that when a toast is displayed on screen, its contents will be, politely, communicated to assistive technologies, such as screen readers.

Ideally, a toast component should contain no interactive controls, as by doing so an immediate divergence of inclusive UX is introduced.


See the source link for a list of issues and some ways to mitigate them.

Not Your Father's Navigation Strategy: There's More Than Just the TAB Key

As a blind screen reader user, and in my career educating designers, developers, and testers on accessibility issues, I have had the opportunity to observe the techniques used by various users to understand the layout and operation of web pages and applications. I have also seen well-intentioned sighted testers believe that components or entire sites are not accessible because they were unfamiliar with the techniques of navigating the web without sight.

In this article, I will walk you through the ways a blind screen reader user can navigate a web page, gather information about its layout and organization, and use that knowledge to efficiently and rapidly navigate a site or application. I hope to convey the importance of using techniques other than the TAB key as a primary means of navigating a website and illustrate the power you provide to a screen reader user by following semantic HTML markup and the principles of the Web Content Accessibility Guidelines.

Global Accessibility Awareness Day

May 17th is Global Accessibility Awareness Day. See the source link for more. The participate page is a great list of things to test for and be aware of.

The target audience of GAAD is the design, development, usability, and related communities who build, shape, fund and influence technology and its use. While people may be interested in the topic of making technology accessible and usable by persons with disabilities, the reality is that they often do not know how or where to start. Awareness comes first.

The title attribute is an accessibility fallback

[S]upport aside, it’s still not a particularly good choice as a consistent means to convey accessible information. Because while the title does provide an accessible name to elements in the absence of other sources, it is considered a fallback. Outside of some notable exceptions (more on this later), other mechanisms will always be preferred.


While the title attribute can be used on any HTML element, it’s essentially wasted on most inline, text level elements. As these elements aren’t typically included in the accessibility tree, there’s no reason for a screen reader to look for a title on these elements to announce.

Block-level wrapping elements can get some usage out of the title attribute. JAWS, NVDA and VoiceOver will all announce a title on elements like landmarks (header, footer, main, etc.) but support may vary on other elements depending on your browser pairing. For example, JAWS will not announce a title on a div without additional role updates.

Other wrapping elements, like lists and paragraphs, are announced in JAWS and VoiceOver, but NVDA ignores the attribute on these elements. But honestly, using title tooltips on these elements is highly suspect. Why would you want to have a tooltip constantly appearing over a large chunk of content? Unless you are purposefully trying to hide content, which isn’t helpful, there’s little need for using the title in this manner.

Images, form fields, and anchor links are the elements one is most likely to associate with the title attribute. In regards to screen readers, the title attribute essentially gets a “B” grade when reviewing publicly available screen reader support charts from

titles are meant to serve as descriptive text. And largely only in situations where there is no accessible name for an image, form field, or anchor element, the title will be promoted to the accessible name.

Inclusive Tooltips & Toggletips

Most of the time, tooltips shouldn’t be needed if you provide clear textual labeling and familiar iconography. Most of the time toggletips are a complex way of providing information that could just be part of the document’s prose content. But I see each of these components all the time in auditing websites, so I wanted to provide some guidance on how to make the most of them.


  • If you have space, don’t use tooltips or toggletips. Just provide clear labels and sufficient body text.
  • If it’s a tooltip you are looking to use, decide whether the tip’s content should be provided as the label or description and choose ARIA properties accordingly.
  • Don’t rely on title attributes. They are not keyboard accessible and are not supported in many screen reader setups.
  • Don’t describe toggletips with aria-describedby. It makes the subject button non-functional to screen reader users.
  • Don’t put interactive content such as close and confirm buttons or links in tooltips or toggletips. This is the job of more complex menu and dialog components.

Solutions for creating more accessible SVGs

We’ve been working with SVGs a lot recently, which has led our developers down a rabbithole of discovery! Here are some things to consider when it comes to SVGs and accessibility.


1. <img> tags and SVGs

When SVGs are implemented as <img> tags with an .svg as the source, we’ve encountered a few issues for VoiceOver and TalkBack users. These issues occur when those <img> tags don’t also have an ARIA role=”img” attribute.


2. <title> tags and SVGs

We often see examples of making SVGs accessible by simply adding a <title> element within the inline <svg>. While this does help in some situations, like a lone SVG icon within a link, adding a <title> element doesn’t make SVGs accessible in all browsing environments.


For example, when using Firefox and NVDA, a link containing an SVG would be recognized as a link, but the text within the <title> element would not be announced. NVDA announces the path within the href attribute only.

Adding an aria-labelledby attribute to the SVG can help expose the text within the <title> element to the browser’s accessibility API. However, even with this in place, NVDA does not announce the <title> text as we might expect.

Our most recommended approach when it comes to browser support and consistency across screen readers is to add a visually-hidden element as a sibling element to the <svg>. With this implementation, we’ve found that all browser and screen reader combinations tested were able to announce the link with the expected text announcement.

We also recommend adding aria-hidden=”true” to the <svg> element itself. This is to help prevent having any other text that may be embedded within the SVG be announced by screen readers. Then, the only text that should be announced would be the content within that visually-hidden element.


7. Colour contrast

While not a bug per se, we also see a lot of cases where designers and developers don’t plan for colour contrast issues for SVGs. Since SVGs function just like transparent GIFs in how they are displayed, different page background colors and effects can cause unanticipated issues for low vision users.

For example, a black SVG icon that’s perfectly visible with a white page background is going to be invisible in a Windows High Contrast theme that uses a black background. This is a common use case for users who use High Contrast settings due to light sensitivity or related issues. When you provide a solid background or contrasting border for SVGs, you can help avoid those kinds of problems.