WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Screen reader behavior with navigation links

for

From: Sumit Patel
Date: Dec 11, 2024 7:54PM

I agree that the button should have a descriptive label, such as 'Expand
Navigation Section' or 'Collapse Navigation Section.' What are your
thoughts on the two queries I raised earlier? I'd appreciate your feedback
on them as well.

On Wed, 11 Dec 2024 at 19:29, <EMAIL REMOVED> <
<EMAIL REMOVED> > wrote:

> 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.
> >>> > >>> > >>> > >>> > >> > >> > >> > >> > >>
> > > > > > > > > > > > >