E-mail List Archives
Screen reader behavior with navigation links
From: Sumit Patel
Date: Dec 11, 2024 5:11AM
- Next message: Dean.Vasile@outlook.com: "Re: Screen reader behavior with navigation links"
- Previous message: Corvin Bazgan: "Re: Audible sync for Windows discontinued"
- Next message in Thread: Dean.Vasile@outlook.com: "Re: Screen reader behavior with navigation links"
- Previous message in Thread: None
- View all messages in this Thread
Hi Experts,
I hope this message finds you well. I am writing to seek your advice on an
issue I am encountering with the homepage navigation section in our
application.
At the top of all pages, we have a navigation section containing 8 links.
By default, the links are presented with icons. However, there is an arrow
button before these links that allows the user to expand the section. When
activated, the section expands, and the user can see both the icon and the
visual label for each navigation link. If the user activates the arrow
button again, the UI reverts to the previous state, with only the icons
visible.
Currently, for the arrow button, the screen reader announces "expand" when
the right arrow is activated, and "collapse" when the left arrow is
activated. I have a couple of queries regarding the screen reader behavior
and the accessibility of this navigation section:
### Query 1: Screen Reader Announcements for Links
When the user navigates to the links, the screen reader announces the role
of each element as "link," but no label is announced. However, when the
section is expanded, and the user navigates to the links, the screen reader
announces the correct label (the visual label) along with the icon.
If we add an `aria-label` to the links to resolve this, the screen reader
announces the label twice when the section is expanded – once as the
`aria-label` and again as the visual label.
What would be the best solution to fix this issue? Should we accept the
dual announcement, or is there a better approach to avoid this redundancy
while maintaining clarity for screen reader users?
### Query 2: Screen Reader Behavior for Tab and Arrow Keys
When navigating with the Tab key, the screen reader announces all the links
(including the arrow button) together. After pressing Tab again, the focus
moves out of the navigation section. However, screen reader users can still
navigate the links using the arrow keys in the virtual/browse mode.
For keyboard-only users, arrow key navigation within the section is
enabled, allowing them to move between the links.
My concern is whether this behavior aligns with WCAG guidelines. The only
issue I observe is that the screen reader does not switch to forms mode due
to the "link" role. Is this acceptable, or should we adjust the
implementation to better comply with WCAG standards?
I appreciate your insights and guidance on these queries. Please let me
know if you need any further details to provide a recommendation.
Thank you for your time and assistance!
Regards,
Sumit.
- Next message: Dean.Vasile@outlook.com: "Re: Screen reader behavior with navigation links"
- Previous message: Corvin Bazgan: "Re: Audible sync for Windows discontinued"
- Next message in Thread: Dean.Vasile@outlook.com: "Re: Screen reader behavior with navigation links"
- Previous message in Thread: None
- View all messages in this Thread