This is a collection of elements and components created with or without ARIA attributes.
The goal is to test if and how they get exposed to assistive technologies.
If you are a screen reader user, and depending also on the screen reader, certain elements will not be exposed.
Unless otherwise specified, the following pairings of browser and assistive technologies are used:
Chrome 131 with JAWS 2025.2412.50
Firefox 134 with NVDA version 2024.4.2
Edge 131 with Narrator on Windows 11
Voice Access on Windows 11
Chrome 131 with TalkBack 13.5 on Android 12
Please note that not all elements listed have been added to the page yet.
Accordion
Example: Frequently Asked Questions
Fruit
Banana
Apple
Veggies
Carrots
Lettuce
Dessert
Cake
Ice cream
Notes on accordions
type of disclosure widget built with details
it has open/close status announced by screen readers as collapsed/expanded
uses summary element for the label
each details element maps as a group in the accessibility tree, but it's not announced as one
this example uses the name attribute with the same value for each details element to keep only
one open at a time. Note that this is not a good idea when considering users with cognitive disabilities.
Questions on accordions
for when there's more than one details element,
should they be wrapped by a named group, like the current example?
for when there's more than one details element,
should they be part of a list, like the current example?
is aria-controls necessary?
Labels for Inputs
Label with for wraps input element
Label without for wraps input element
Label with for does not wrap input element
Notes on labels
For Name 1 and Name 2,
clicking anywhere in the space of the container places the focus on the input. Name 1 is the best
approach right now because of an issue with Dragon Naturally Speaking, a common voice recognition software.
For Name 3 only
clicking on the label places the focus on the input.
Using aria-hidden
Example: aria-hidden hides content from screen readers
This very paragraph is wrapped in a div with aria-hidden="true".
The paragraph and the div are not exposed to screen readers.
Example: interactive content with aria-hidden on its container is still focusable
The link above is wrapped in a div with aria-hidden. Some screen readers will reach it
in both focus and browse mode, while others only in focus mode. The way it's announced also differs
depending on the browser.
Notes on aria-hidden (1/17/2025)
In general, the attribute removes nodes from the accessibility tree, including child nodes.
A very curious behavior from Chrome and Edge in the example with
aria-hidden added to the div parent of the link element. Possible related to HTML typo,
even though the validator
did not catch anything connected to this issue. Need to retest.
First, Chrome and Edge remove both the parent div and the link from the accessibility tree.
When selecting either the div or the link in Elements views, and then toggling to the
accessibility tree view, the Chromium browsers add the ignored nodes to the tree.
They do it only for the link and the text node, but not for the div.
However, with the screen reader on, the link is reachable
in focus mode. The moment the focus reaches the link, the accessibility tree changes the node for
the link from "ignored" to role "link". (This is the unbelievable part. The accessibility tree
determines the behavior of the screen reader and not the other way around.)
Since the link is now included in the tree, it's also reachable in browse mode.
Strange.
The text node is still ignored. The div node is still
not included, but the browsers add the div node with role "generic" when selecting the node in
Elements' view and then toggling to the accessibility tree view.
Firefox does not include the parent div
nor the link in the accessibility tree. With NVDA, the link is not reachable in browse mode,
but it is reachable
in focus mode. Since the link does not have a node in the accessibility tree, its name is not announced.
BUT, NVDA does announce the text content for the section that contains the link, which is the current
section with heading "Using aria-hidden".
Note that the div with aria-hidden that contains the link is a great-grandchild of the section.
Voice Access (on Windows 11) with Edge does not assign a number to the
link when using the "show numbers" command. Once the accessibility tree updates the status
of the link node (following the focus reaching it), the link is assigned a number, and can also
be activated with the "Click Learn more" command.
Using role none or presentation
Example: image with role "none"
The image above is removed from the accessibility tree. In this case, role="none"
behaves like alt="".
Example: role "none" hides the semantics of the list and its items
Item 1: exposed as a text node only.
Item 2: exposed as a text node only.
Item 3: exposed as a text node only.
Unlike aria-hidden, the role="none" does NOT cascade to
the children of the element it's applied to, but there are exceptions. One case is when a parent element requires certain
descendants in order to fulfill its role, the way an ul requires li elements.
If the parent has role "none", then the children's semantic roles are also supressed.
Note that in the list above the roles are supressed, and that the text content of each list item is still exposed to screen readers
when in browse mode. Just that the list and its items are not announced as such. In the list below, the
ul element has aria-hidden="true".
The entire list and its content are removed from the accessibility tree.
