Accessibility: in what scenarios would aria-describedby not be announced?

Question

I am working on creating accessible help text for my form controls. I am planning to use aria-describedby to attach a accessible description to a field. This approach is discussed here

Although in my testing with ChromeVox extension and Windows 10 screen reader I have found out that aria-describedby is not announced, but it is rather well supported across browsers and screenreaders, so i am planning to use this approach.

Also this suggests that in some cases aria-describedby would be ignored or not work as expected but these cases are quite specific and i am generally ok with it.

aria-describedby content may not always be announced to users, depending on their screen reader and navigation method. The attribute is well supported, but that doesn’t mean there aren’t some things to be aware of: aria-describedby content may not be announced by all screen readers if navigating to a button, link, or form control with the virtual cursor. JAWS specifically may not announce an element’s description when using hot keys to navigate to certain elements. When navigating by visited links, the description will not be announced. However JAWS should announce descriptions when navigating by form controls. JAWS 17 + IE won’t announce aria-describedby content when tabbing to a link (newer version of JAWS have fixed this). IE11 won’t announce the accessible name or description of a form control if the title attribute is used in tandem with aria-describedby, and the user is navigating by virtual cursor or form control hot key (F). Both will be announced if using the Tab key. (IE11 had much bigger problems with aria-describedby in the past.) TalkBack + Android Chrome won’t announce any aria-describedby content of a modal dialog when auto-focusing an element within that dialog. If a user has descriptions or hint text turned off, any associated content won’t be announced. Because of this, it’s vital that any content that is necessary to the understanding of a UI be available by means other than just aria-describedby.

I would like to understand if there are times when aria-describedby would not be announced automatically? The previous link phrasing seems to suggest that it is only going to be announced on request :

By using aria-describedby to reference the format of the field, this information is made available to the users on request. That is, it is not automatically displayed or read aloud. This makes sense if the user has been informed of the format before, or when there are lots of input fields with the same format, for example.

I don't get what it means by "on request". I believe that the default behavior is to announce the aria-describedby text after announcing the label and the input type.

Answer 1

The behavior of aria-describedby (like aria-label and aria-labeledby) is profoundly influenced by the role of the element where they appear.

As you may know screenreaders generally have two 'modes', and this is mostly determined by the role (or default semantics) of the content.

I have certainly had problems getting non-interactive elements announced, if they appear within interactive ("forms mode") content.

I have had good results using aria-describedby with modal content. (Put the attribute on the modal, and point at the text elements inside which you want announced when the modal opens.) But I suppose this is because there is an obvious moment where the screenreader is supposed to make those announcements: the moment when the modal opens.

In the case that the form (or other "forms mode" container) is always present on the page, you can usually read the non-interactive content using browse-mode key combinations such as "next heading" ("H" on NVDA and JAWS) or "next paragraph" ("P"). Check to see if these 'requests' are enough of a solution.

You might also experiment with the standard HTML elements fieldset and legend, whose purpose is providing a text description for groups of interactive elements.

Also consider treating the 'form' (or toolbar or whatever) as a single tab stop, and use arrow keys to navigate the components within. This way, when you give focus to the container, you should get an announcement of whatever is aria-describedby (or indeed aria-labeledby/aria-label)

If this isn't working for you, there are a couple of hacks you might try as a last resort:

• Put tabindex="-1" on the element surrounding the text you want announced, and then call focus() on that element at the appropriate moment.
• Copy the text into the textContent of an aria-live region with javaScript at the appropriate moment.

Neither of these hacks are pretty, and might not suit you, if there is no 'appropriate moment'. (There's no equivalent of onfocus for browse mode). But with a little care, they can be made to work.