The screen reader always reads aloud the information fragment on which its cursor currently is placed. The cursor can be moved by the user to the next (or previous) element, which then again is announced by the screen reader. The DOM is used to determine the sequence of the elements.
I was recently watching this “Accessibility Fundamentals with Rob Dodson” video, specifically the section around the 6:55 mark, where Rob Dodson explains how the Chrome browser interprets the DOM with the accessibility tree as the step in between. I am not a developer, so I do not know if this is specific to the Chrome browser, but I found it very helpful because it makes it easy to understand exactly what the screenreader is reading, and also introduces the concept of the accessibility tree feature inside Chrome Dev Tools.
Just thought I would share this thought. I am sure people more knowledgeable about development for accessibility can assess whether this is a relevant suggestion or not. In any case, let me know if my description above is unclear or if you have any follow-up questions. Thank you,
(Attached: Screenshot from the linked video at 6 minutes 55 seconds, showing a diagram. The diagram shows HTML code turning into the DOM, which in turn turns into two separate things: The GUI; and the accessibility tree. The diagram then shows the accessibility tree being interpreted by a user using assistive browser technologies)
Hi,
I was reading through the page titled 'Screen readers process contents in a linear way using a cursor' (on this URL).
In the section titled 'Auditive announcement of elements' of the page, the text says that:
I was recently watching this “Accessibility Fundamentals with Rob Dodson” video, specifically the section around the 6:55 mark, where Rob Dodson explains how the Chrome browser interprets the DOM with the accessibility tree as the step in between. I am not a developer, so I do not know if this is specific to the Chrome browser, but I found it very helpful because it makes it easy to understand exactly what the screenreader is reading, and also introduces the concept of the accessibility tree feature inside Chrome Dev Tools.
I think the 'Screen readers process contents in a linear way using a cursor' page is very helpful as-is, but I wondered if it might be helpful to add a short note regarding this intermediary concept between the DOM and the screenreader in the context of the paragraph I quoted above?
Just thought I would share this thought. I am sure people more knowledgeable about development for accessibility can assess whether this is a relevant suggestion or not. In any case, let me know if my description above is unclear or if you have any follow-up questions. Thank you,
(Attached: Screenshot from the linked video at 6 minutes 55 seconds, showing a diagram. The diagram shows HTML code turning into the DOM, which in turn turns into two separate things: The GUI; and the accessibility tree. The diagram then shows the accessibility tree being interpreted by a user using assistive browser technologies)
— Filip