ARIA make reader read non-focused element content

aria-describedby
aria-describedby not working
mozilla aria describedby
aria-describedby jquery
aria-describedby multiple ids
aria-describedby selenium
aria-describedby popover
aria-describedby radio button

I have elements on a page which are "focusable" (buttons, elements with tabindex etc) and screen reader reads the content just fine.

However, I have some other elements that are not focusable (due to the fact there are lots of them - dropdown list results etc), so I don't want user to click tab countless times, but they are navigable through left/right/up/down keys, and they get CSS class "selected" (although some other element - their parent - is actually focused)

I want to make reader read those specific elements, with the class "selected". How do I do it?

(I tried applying attribute aria-label="read this" to them, but it didn't work; it works only if element is actually focused)


Here's more details to help you understand what I want to achieve:

<div tabindex="0" >
  <span>title1</span>
  <ul>
    <li class="selected">item1</li>
    <li>item2</li>
    <li>item3</li>
  </ul>
</div>

<div tabindex="0">
  <span>title2</span>
  <ul>
    <li>item1</li>
    <li>item2</li>
    <li>item3</li>
  </ul>
</div>

Here's the fiddle: https://jsfiddle.net/d5gbjst1/1/

You can tab back and forth between those 2 divs and any screen reader (I tried with Windows Narrator, NVDA and JAWS) will read "title1" and all the items for the first one and "title2" and all the items for the second, depending where the focus is.

Notice class "selected" on the first item in the first ul. Now, I browse with the up/down arrows through my ul lists, and class "selected" shifts from item to item accordingly. (That's the separate JS code, not included in this example for simplicity sake)

When the class "selected" is applied to the element, I want to force reader to read it. Is it possible at all?


Edit: I tried also adding attributes to ul and li, still no luck:

<ul role="list">
 <li role="listitem">

I had the same problem the other week, the solution I went with was to use aria-describedby and also aria-label to provide the extra info from around the page in the element that currently has focus.

In one case we change the content of aria-label to provide extra details only on the first time the element has focus.

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-describedby_attribute

Modal Dialog Example, To make the content easier to read when displayed on small screens, the Focus and accessible descriptions are set based on the content of each dialog. To support screen reader user awareness of the dialog text, the dialog text is The dialog element is not a descendant of any element that has aria-hidden set to true� Many screen reader users, when searching for the content they are interested in on a page, will use their screen reader to jump from heading to heading. Unfortunately, it might not always make sense to start each section of the page with a visual heading, so you could instead make those headings screen reader only as a compromise.

I want to make reader read those specific elements, with the class "selected". How do I do it?

I don't think you should try to do that. Screen readers - especially the ones you have tested with - have intricate keybinds to allow users to navigate to, from, and between specific elements and then jump in and out of them.

Forcing a non standard behaviour for accessible technologies could create a frustrating experience for those users.

Edit: I tried also adding attributes to ul and li, still no luck:

<ul role="list"> <li role="listitem">

Avoid setting roles for lists, as they have these assigned by default. See here: https://www.w3.org/TR/html53/grouping-content.html#ref-for-allowed-aria-role-attribute-values%E2%91%A1%E2%91%A0

Notice class "selected" on the first item in the first ul. Now, I browse with the up/down arrows through my ul lists, and class "selected" shifts from item to item accordingly. (That's the separate JS code, not included in this example for simplicity sake)

When the class "selected" is applied to the element, I want to force reader to read it. Is it possible at all?

I have tested using narrator and Screen Reader Simulator for Chrome with your jsfiddle. The expected behaviour, and what I have managed to reproduce, is what you are aiming for. Correct me if I am wrong?

First, I click tab and focus on the following piece of markup:

<div tabindex="0" >
  <span>title1</span>
  <ul>
    <li class="selected">item1</li>
    <li>item2</li>
    <li>item3</li>
  </ul>
</div>

Which results in the screen reader returning

"title1, item1, item2, item3"

in quick succession. As I would expect.

I click tab again to focus on this piece of markup:

<div tabindex="0">
  <span>title2</span>
  <ul>
    <li>item1</li>
    <li>item2</li>
    <li>item3</li>
  </ul>
</div>

And the screen reader returns

"title 2, item1, item2, item3"

in quick succession. Again, as I would expect

Finally, I click tab again to set focus back to the first piece of markup and use the downarrow key. The screen reader returns

"Enter list. One of three. Bullet. Item 1"

I then click the downarrow key again to move to the second bullet.

"Two of three. Bullet. Item 2."

I click the downarrow key again.

"Three of three. Bullet. Item 3".

This behaviour is what I would expect and is - from what experience I have of passing two Double-A WCAG 2.1 assessments - the norm.

What behaviour are you expecting. Specifically, what is it you want your screen reader to return/say?

Using aria-labelledby to concatenate a label from several text nodes , This rule checks that elements with an aria-hidden attribute do not as part of the reading order, but still part of the focus order, making its state� In the example below, the paragraph is not exposed to the accessibility API (e.g. would not be read aloud by a screen reader). <p aria-hidden="true"> Some things are better left unsaid. </p> Children elements can be omitted from accessibility APIs:

I had the same problem recently and during research, I found information about aria-activedescendant attribute: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-activedescendant_attribute

In this case, every list element should have a unique id attr. When the list element is selected, its id should be provided to the aria-activedescendant attr of the focused parent.

<div tabindex="0" aria-activedescendant="Id1">
  <span>title1</span>
  <ul>
    <li class="selected" id="Id1">item1</li>
    <li id="Id2">item2</li>
    <li id="Id3">item3</li>
  </ul>
</div>

Rule | Element with `aria-hidden` has no focusable content, Marking up a dialog element with the dialog role helps assistive technology Keep in mind that a dialog's title and description text do not have to be reader announce the dialog's information when focus is moved into it. Hiding elements from screen readers using aria-hidden. ARIA provides an attribute which allows to hide elements from screen readers. It works pretty uniformly on non-focusable elements in modern browsers and screen readers, but it still has some very odd peculiarities.

You could try adding tab index to those specific elements, but you should be careful when using it as it can lead to pages that can be really hard to navigate if you use values greater than 0. Heres a link for more detailed answer. https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/tabindex

ARIA: dialog role, Because ATs with reading mode default to that mode for all elements except to place focus on the document element and read the text with the screen role, the document role does not have any relation to other elements with a tabindex ="0": Used to make it focusable so the assistive technology user� Used to make it focusable so the assistive technology user can tab to it and start reading right away. Keyboard interactions. The element should be made focusable by setting the tabindex="0" attribute / value pair on it. This way, the user can tab to it, reading mode is invoked automatically, and the content can be read right away.

ARIA: document role, Accessibility is about making content available to as many people as It's possible to make non-focusable elements focusable by adding the But it's not because elements are focused in DOM order and the Thank you for reading and please don't forget to like and share this article if you enjoyed it. The descriptive elements do not necessarily have to be visible on screen. Using the Attributes. Here are some examples of how these attributes can be used. Provide Context For "Continue Reading" Links. On the homepage of this blog, for example, after the excert of each blog post there is a link with the text "Continue reading". To a screen

Writing JavaScript with accessibility in mind, So if there are any non-interactive elements (like a paragraph) in the form, they are prone to be missed. Screen reader users generally interact with form controls using focus mode, meaning done this yet, go back and read ARIA - when HTML simply is not enough). Making content focusable Preview. Screen readers allow users to interact in different modes, and can produce very different results in each mode. The modes used in these tests are: Reading Content read using the "read next" command in a screen reader; Tabbing Content read using the "tab" key in a screen reader; Heading Content read using the "next heading" key in a screen reader

Placing non-interactive content between form controls, All interactive elements must be focusable and non-interactive elements must be able to move focus to the element via any input device; keyboard, mouse, touch, voice, switch device etc, as well as via touch when a screen reader is running. Make sure that all content that has meaning and functionality is focusable by�

Comments
  • I'm not sure I understand. My element with the class "selected" and it never receives focus. His state is never focused (as in browser focused, rule (":focus") is never true for it)
  • You missunderstand me, on the item that has the focus, add an aria label that gives info about the element you want read out. You can not directly do what you want to do, but you can fake it
  • It is impossible for me to add to "ul" element labels of each "li" element
  • You can use aria-discribedby to list the IDs of each LI to have them all read out. It’s not pretty, but unfortunately it is often the only way.
  • Why would I do it? Why wouldn't I just use aria-label instead of aria-labelledby some other element? You miss the point, I don't want "li" elements to be focused.
  • I don't get the results as you do. When I use Windows Narrator I get only "down arrow" and "up arrow" when clicking down and up arrows. As for NVDA the up and down behaviour is blocked for some reason (some hotkeys probably highjacked it), and as for JAWS up and down arrows have the same effect as tabbing back and forth.
  • It sounds as if your narrator - and perhaps other assistive technologies - are announcing your key presses instead of actually following your on-screen navigation. I have confirmed again with Narrator this morning and replicated my above answer's behaviour.
  • I had the same result (down arrow/up arrow) when I installed Screen Reader Simulator for Chrome. I use Win10 and latest Chrome. I don't know how it's possible for me to have a different result than you.
  • Something for you to check: In your Narrator settings, scroll down to "Change what you hear when typing" and ensure that checkbox 1, 2, and 5 are ticked. That is the default settings.
  • I have default settings of Narrator, and the Narrator works fine conserning tab
  • I specifically told element should not be focusable, and tabindex attribute makes them focusable.