E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 5 (In chronological order)

From: Sumit Patel
Date: Wed, Dec 11 2024 5:11AM
Subject: Screen reader behavior with navigation links
No previous message | Next message →

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.

From: Dean.Vasile
Date: Wed, Dec 11 2024 6:00AM
Subject: Re: Screen reader behavior with navigation links
← Previous message | Next message →

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 ADDRESS REMOVED =
617-799-1162

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

From: Sumit Patel
Date: Wed, Dec 11 2024 6:15AM
Subject: Re: Screen reader behavior with navigation links
← Previous message | Next message →

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 ADDRESS REMOVED = <
= EMAIL ADDRESS 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 ADDRESS REMOVED =
> 617-799-1162
>
> > On Dec 11, 2024, at 7:12 AM, Sumit Patel < = EMAIL ADDRESS 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.
> > > > > > > > > > > > >

From: Dean.Vasile
Date: Wed, Dec 11 2024 6:59AM
Subject: Re: Screen reader behavior with navigation links
← Previous message | Next message →

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 ADDRESS REMOVED =
617-799-1162

> On Dec 11, 2024, at 8:16 AM, Sumit Patel < = EMAIL ADDRESS 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 ADDRESS REMOVED = <
>> = EMAIL ADDRESS 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 ADDRESS REMOVED =
>> 617-799-1162
>>
>>> On Dec 11, 2024, at 7:12 AM, Sumit Patel < = EMAIL ADDRESS 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.
>>> >>> >>> >>> >> >> >> >> >>
> > > >

From: Sumit Patel
Date: Wed, Dec 11 2024 7:54PM
Subject: Re: Screen reader behavior with navigation links
← Previous message | No next message

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 ADDRESS REMOVED = <
= EMAIL ADDRESS 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 ADDRESS REMOVED =
> 617-799-1162
>
> > On Dec 11, 2024, at 8:16 AM, Sumit Patel < = EMAIL ADDRESS 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 ADDRESS REMOVED = <
> >> = EMAIL ADDRESS 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 ADDRESS REMOVED =
> >> 617-799-1162
> >>
> >>> On Dec 11, 2024, at 7:12 AM, Sumit Patel <
> = EMAIL ADDRESS 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.
> >>> > >>> > >>> > >>> > >> > >> > >> > >> > >>
> > > > > > > > > > > > >