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:59AM

Well, Sumit
I believe that that arrow must have an aria label explaining exactly what it is that is expanding and collapsing.
It either needs to be identified as a specific kind of menu or have some other accessible text but as a screen reader user if I come across a Expandable button that only says expandable and collapsible, I’m going to be marking that
Dean Vasile
IAAP, CPACC
<EMAIL REMOVED>
617-799-1162

> On Dec 11, 2024, at 8:16 AM, Sumit Patel < <EMAIL REMOVED> > wrote:
>
> I agree with your point, but unfortunately, the design is as it is, and the
> team is not willing to make changes at this time.
>
> In response to your question, I am using the NVDA screen reader. Initially,
> when the user focuses on the right arrow button, the screen reader
> announces "expand.". After activation, the button turns into a left arrow,
> and the screen reader announces "collapse."
>
> ---
>
> This version maintains clarity and flow while conveying your message more
> professionally.
>
>
>> On Wed, 11 Dec 2024 at 18:30, <EMAIL REMOVED> <
>> <EMAIL REMOVED> > wrote:
>>
>> 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.
>>> >>> >>> >>> >> >> >> >> >>
> > > >