WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Screen reader behavior with navigation links

for

From: Dean.Vasile
Date: Dec 11, 2024 6:00AM

Hello Sumit.
First question I have for you is which screen reader are you testing with?
The next question if I am navigating by form element and I arrive to the arrow, what is my screen reader saying when it gets to the arrow?
Third thing I have to mention
Is it necessary to have the icons with a collapsed menu?
Or would it be better to eliminate those and identify the collapsed arrow as the main navigation button and then expand it at which point you will see the eight links.
I do know that JAWS and NVDA do announce things differently.
Personally I would eliminate the whole thing and just have a navigation region with a list of eight items,
But that’s myself this is your design :-)
Dean Vasile
IAAP, CPACC
<EMAIL REMOVED>
617-799-1162

> On Dec 11, 2024, at 7:12 AM, Sumit Patel < <EMAIL REMOVED> > wrote:
>
> 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.
> > > >