E-mail List Archives

Search E-mail List Archives for

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

From: Emily Ogle
Date: Wed, Jun 26 2019 9:20AM
Subject: Responsive navigation:
No previous message | Next message →

My company is working on creating an enterprise level framework that is accessible. This framework will be the foundation of many different solutions (products) and the framework team won't necessarily have control over the content used to create different solutions. Currently, they are working on the navigation system. Again, the team is creating an extensible framework for many other groups within the company to use.
Among the challenges we've encountered is in creating a responsive and consistent navigation when resizing. In max view, the navigation order is generally intuitive. We have the potential of having numerous pages within navigation so have added a "More" drop-down. "More" isn't necessarily descriptive, however, and we've discussed the possibility of adding ARIA label to say "Additional Sections" instead of the visual "More." The problem with that, however, is ensuring access to those using speech input devices. So what would be the best way to maintain visual real estate and provide accessibility to all assistive technologies?

In mobile view, the navigation is collapsed into a hamburger menu and the entire navigation content is announced to screen reader upon receiving focus. This is unexpected. Additionally, the navigation order from max view changes when in mobile mode, where static elements are in between the navigation options and profile options, but in mobile view, the navigation and profile options are one stream of navigation. This might be okay, but am not completely sure.
I've got a link to the framework below. Hoping someone can take a look to see if anything stands out as glaringly inaccessible and can provide guidance.
Appreciate the help!

Terra Framework

|
|
| |
Terra Framework


|

|

|

From: Emily Ogle
Date: Wed, Jun 26 2019 9:28AM
Subject: Re: Responsive navigation:
← Previous message | Next message →

Here's the link I mentioned:https://terra-framework-deploye-pr-695.herokuapp.com/#/raw/tests/terra-application-navigation/application-navigation/stated-demo
On Wednesday, June 26, 2019, 10:21:23 AM CDT, Emily Ogle via WebAIM-Forum < = EMAIL ADDRESS REMOVED = > wrote:

My company is working on creating an enterprise level framework that is accessible. This framework will be the foundation of many different solutions (products) and the framework team won't necessarily have control over the content used to create different solutions. Currently, they are working on the navigation system. Again, the team is creating an extensible framework for many other groups within the company to use.
Among the challenges we've encountered is in creating a responsive and consistent navigation when resizing. In max view, the navigation order is generally intuitive. We have the potential of having numerous pages within navigation so have added a "More" drop-down. "More" isn't necessarily descriptive, however, and we've discussed the possibility of adding ARIA label to say "Additional Sections" instead of the visual "More." The problem with that, however, is ensuring access to those using speech input devices. So what would be the best way to maintain visual real estate and provide accessibility to all assistive technologies?

In mobile view, the navigation is collapsed into a hamburger menu and the entire navigation content is announced to screen reader upon receiving focus. This is unexpected. Additionally, the navigation order from max view changes when in mobile mode, where static elements are in between the navigation options and profile options, but in mobile view, the navigation and profile options are one stream of navigation. This might be okay, but am not completely sure.
I've got a link to the framework below. Hoping someone can take a look to see if anything stands out as glaringly inaccessible and can provide guidance.
Appreciate the help!

Terra Framework

|
|
|  |
Terra Framework


|

|

|

From: glen walker
Date: Wed, Jun 26 2019 10:17AM
Subject: Re: Responsive navigation:
← Previous message | Next message →

I like the main navigation when they're links with aria-current. When it
changes to the hamburger menu, they become a listbox with role=option and
aria-selected. I don't like that the roles and aria attributes have
changed. I would recommend sticking with links and aria-current in the
hamburger menu.

To abide with 2.5.3, if you display "More...", then the aria-label would
require the word "more" in it. You could have "more additional sections"
but I'm not sure you really need an aria-label. If I hear "more, submenu"
(because you have aria-popup), then (for me), that's enough to tell me
there's more stuff.

Note that the "more" submenu doesn't automatically switch to forms mode
when I'm running nvda on firefox. Not sure why. I thought it switched
automatically for certain roles as defined on
https://www.w3.org/TR/wai-aria-practices/#kbd_generalnav. You're using
role="listbox" which requires the up/down arrow keys to navigate in the
list so nvda should switch to forms mode automatically, but when nvda is
running, the up/down arrows don't work in your submenu.

For 1.4.11, you might want to adjust your "active" light blue bar above the
currently selected navigation item (2.0:1 contrast ratio). In the
hamburger menu, the left blue bar is lighter and the dark blue background
is darker so you have a 5.0:1 ratio (much better).

When the hamburger menu opens, it looks like the focus is put on the
container itself (not interactive), and on firefox, my first TAB puts the
focus on the scrollable container. Firefox allows the focus to move to
containers with scrollbars (overflow:auto) so that the arrow keys can
scroll the container. Other browsers don't do that. It's not necessarily
a problem. I just wanted to point it out. NVDA just says "section" when
the scrollable container receives focus.

The hamburger icon itself should have aria-expanded.


On Wed, Jun 26, 2019 at 8:28 AM Emily Ogle via WebAIM-Forum <
= EMAIL ADDRESS REMOVED = > wrote:

> Here's the link I mentioned:
> https://terra-framework-deploye-pr-695.herokuapp.com/#/raw/tests/terra-application-navigation/application-navigation/stated-demo
> On Wednesday, June 26, 2019, 10:21:23 AM CDT, Emily Ogle via
> WebAIM-Forum < = EMAIL ADDRESS REMOVED = > wrote:
>
> My company is working on creating an enterprise level framework that is
> accessible. This framework will be the foundation of many different
> solutions (products) and the framework team won't necessarily have control
> over the content used to create different solutions. Currently, they are
> working on the navigation system. Again, the team is creating an extensible
> framework for many other groups within the company to use.
> Among the challenges we've encountered is in creating a responsive and
> consistent navigation when resizing. In max view, the navigation order is
> generally intuitive. We have the potential of having numerous pages within
> navigation so have added a "More" drop-down. "More" isn't necessarily
> descriptive, however, and we've discussed the possibility of adding ARIA
> label to say "Additional Sections" instead of the visual "More." The
> problem with that, however, is ensuring access to those using speech input
> devices. So what would be the best way to maintain visual real estate and
> provide accessibility to all assistive technologies?
>
> In mobile view, the navigation is collapsed into a hamburger menu and the
> entire navigation content is announced to screen reader upon receiving
> focus. This is unexpected. Additionally, the navigation order from max view
> changes when in mobile mode, where static elements are in between the
> navigation options and profile options, but in mobile view, the navigation
> and profile options are one stream of navigation. This might be okay, but
> am not completely sure.
> I've got a link to the framework below. Hoping someone can take a look to
> see if anything stands out as glaringly inaccessible and can provide
> guidance.
> Appreciate the help!
>
> Terra Framework
>
> |
> |
> | |
> Terra Framework
>
>
> |
>
> |
>
> |
>
>
>
>
> > > > >
> > > > >

From: Mark Magennis
Date: Wed, Jun 26 2019 10:21AM
Subject: Re: [EXTERNAL] Responsive navigation:
← Previous message | Next message →

Hi Emily,

I agree that "More" on its own is not fully descriptive.

You do need to have "More" as part of the accessible name though. Because that is what is visible on screen, this is what users of voice activation software will likely speak when they want to activate that control - "click more". As long as "more" is somewhere in the name, Dragon will make the match. This is actually a WCAG 2.1 level A requirement under SC 2.5.3 Label in Name. The accessible name should either be the same as, or include, the visible text.

Then you need to add something to indicate that it is links to sections. So you could use the accessible name "More sections". You won't need "Additional" because "More" covers that. You could argue that "More sections" doesn't actually get across that it is more *links* to sections so you might decide to use "More links to sections" but that seems a bit cumbersome and I think unnecessary. Users would probably guess that "More sections" will show links.

Mark Magennis
Skillsoft | mobile: +353 87 60 60 162
Accessibility Specialist

From: Emily Ogle
Date: Wed, Jun 26 2019 5:06PM
Subject: Re: Responsive navigation:
← Previous message | Next message →

Thanks all. This is great information.

> On Jun 26, 2019, at 11:17 AM, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
>
> I like the main navigation when they're links with aria-current. When it
> changes to the hamburger menu, they become a listbox with role=option and
> aria-selected. I don't like that the roles and aria attributes have
> changed. I would recommend sticking with links and aria-current in the
> hamburger menu.
>
> To abide with 2.5.3, if you display "More...", then the aria-label would
> require the word "more" in it. You could have "more additional sections"
> but I'm not sure you really need an aria-label. If I hear "more, submenu"
> (because you have aria-popup), then (for me), that's enough to tell me
> there's more stuff.
>
> Note that the "more" submenu doesn't automatically switch to forms mode
> when I'm running nvda on firefox. Not sure why. I thought it switched
> automatically for certain roles as defined on
> https://www.w3.org/TR/wai-aria-practices/#kbd_generalnav. You're using
> role="listbox" which requires the up/down arrow keys to navigate in the
> list so nvda should switch to forms mode automatically, but when nvda is
> running, the up/down arrows don't work in your submenu.
>
> For 1.4.11, you might want to adjust your "active" light blue bar above the
> currently selected navigation item (2.0:1 contrast ratio). In the
> hamburger menu, the left blue bar is lighter and the dark blue background
> is darker so you have a 5.0:1 ratio (much better).
>
> When the hamburger menu opens, it looks like the focus is put on the
> container itself (not interactive), and on firefox, my first TAB puts the
> focus on the scrollable container. Firefox allows the focus to move to
> containers with scrollbars (overflow:auto) so that the arrow keys can
> scroll the container. Other browsers don't do that. It's not necessarily
> a problem. I just wanted to point it out. NVDA just says "section" when
> the scrollable container receives focus.
>
> The hamburger icon itself should have aria-expanded.
>
>
> On Wed, Jun 26, 2019 at 8:28 AM Emily Ogle via WebAIM-Forum <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> Here's the link I mentioned:
>> https://terra-framework-deploye-pr-695.herokuapp.com/#/raw/tests/terra-application-navigation/application-navigation/stated-demo
>> On Wednesday, June 26, 2019, 10:21:23 AM CDT, Emily Ogle via
>> WebAIM-Forum < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> My company is working on creating an enterprise level framework that is
>> accessible. This framework will be the foundation of many different
>> solutions (products) and the framework team won't necessarily have control
>> over the content used to create different solutions. Currently, they are
>> working on the navigation system. Again, the team is creating an extensible
>> framework for many other groups within the company to use.
>> Among the challenges we've encountered is in creating a responsive and
>> consistent navigation when resizing. In max view, the navigation order is
>> generally intuitive. We have the potential of having numerous pages within
>> navigation so have added a "More" drop-down. "More" isn't necessarily
>> descriptive, however, and we've discussed the possibility of adding ARIA
>> label to say "Additional Sections" instead of the visual "More." The
>> problem with that, however, is ensuring access to those using speech input
>> devices. So what would be the best way to maintain visual real estate and
>> provide accessibility to all assistive technologies?
>>
>> In mobile view, the navigation is collapsed into a hamburger menu and the
>> entire navigation content is announced to screen reader upon receiving
>> focus. This is unexpected. Additionally, the navigation order from max view
>> changes when in mobile mode, where static elements are in between the
>> navigation options and profile options, but in mobile view, the navigation
>> and profile options are one stream of navigation. This might be okay, but
>> am not completely sure.
>> I've got a link to the framework below. Hoping someone can take a look to
>> see if anything stands out as glaringly inaccessible and can provide
>> guidance.
>> Appreciate the help!
>>
>> Terra Framework
>>
>> |
>> |
>> | |
>> Terra Framework
>>
>>
>> |
>>
>> |
>>
>> |
>>
>>
>>
>>
>> >> >> >> >>
>> >> >> >> >>
> > > >

From: Isabel Holdsworth
Date: Thu, Jun 27 2019 5:28AM
Subject: Re: Responsive navigation:
← Previous message | No next message

Hi Emily,

There doesn't seem to be any structural link between the menu options.
It would be greate if they could be wrapped in a labelled landmark
region or a list or any such element that would group them together as
a single entity for screenreader users.

When the "More" option is activated, as a screenreader user I'd expect
the extra sections to be tagged on to the end of the list. But they're
in a different location at the end of the DOM, which means the two
groups of section links may be very far from one another.

Hope this helps.

Cheers, Isabel

On 27/06/2019, Emily Ogle via WebAIM-Forum < = EMAIL ADDRESS REMOVED = > wrote:
> Thanks all. This is great information.
>
>> On Jun 26, 2019, at 11:17 AM, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> I like the main navigation when they're links with aria-current. When it
>> changes to the hamburger menu, they become a listbox with role=option and
>> aria-selected. I don't like that the roles and aria attributes have
>> changed. I would recommend sticking with links and aria-current in the
>> hamburger menu.
>>
>> To abide with 2.5.3, if you display "More...", then the aria-label would
>> require the word "more" in it. You could have "more additional sections"
>> but I'm not sure you really need an aria-label. If I hear "more,
>> submenu"
>> (because you have aria-popup), then (for me), that's enough to tell me
>> there's more stuff.
>>
>> Note that the "more" submenu doesn't automatically switch to forms mode
>> when I'm running nvda on firefox. Not sure why. I thought it switched
>> automatically for certain roles as defined on
>> https://www.w3.org/TR/wai-aria-practices/#kbd_generalnav. You're using
>> role="listbox" which requires the up/down arrow keys to navigate in the
>> list so nvda should switch to forms mode automatically, but when nvda is
>> running, the up/down arrows don't work in your submenu.
>>
>> For 1.4.11, you might want to adjust your "active" light blue bar above
>> the
>> currently selected navigation item (2.0:1 contrast ratio). In the
>> hamburger menu, the left blue bar is lighter and the dark blue background
>> is darker so you have a 5.0:1 ratio (much better).
>>
>> When the hamburger menu opens, it looks like the focus is put on the
>> container itself (not interactive), and on firefox, my first TAB puts the
>> focus on the scrollable container. Firefox allows the focus to move to
>> containers with scrollbars (overflow:auto) so that the arrow keys can
>> scroll the container. Other browsers don't do that. It's not
>> necessarily
>> a problem. I just wanted to point it out. NVDA just says "section" when
>> the scrollable container receives focus.
>>
>> The hamburger icon itself should have aria-expanded.
>>
>>
>> On Wed, Jun 26, 2019 at 8:28 AM Emily Ogle via WebAIM-Forum <
>> = EMAIL ADDRESS REMOVED = > wrote:
>>
>>> Here's the link I mentioned:
>>> https://terra-framework-deploye-pr-695.herokuapp.com/#/raw/tests/terra-application-navigation/application-navigation/stated-demo
>>> On Wednesday, June 26, 2019, 10:21:23 AM CDT, Emily Ogle via
>>> WebAIM-Forum < = EMAIL ADDRESS REMOVED = > wrote:
>>>
>>> My company is working on creating an enterprise level framework that is
>>> accessible. This framework will be the foundation of many different
>>> solutions (products) and the framework team won't necessarily have
>>> control
>>> over the content used to create different solutions. Currently, they are
>>> working on the navigation system. Again, the team is creating an
>>> extensible
>>> framework for many other groups within the company to use.
>>> Among the challenges we've encountered is in creating a responsive and
>>> consistent navigation when resizing. In max view, the navigation order
>>> is
>>> generally intuitive. We have the potential of having numerous pages
>>> within
>>> navigation so have added a "More" drop-down. "More" isn't necessarily
>>> descriptive, however, and we've discussed the possibility of adding ARIA
>>> label to say "Additional Sections" instead of the visual "More." The
>>> problem with that, however, is ensuring access to those using speech
>>> input
>>> devices. So what would be the best way to maintain visual real estate
>>> and
>>> provide accessibility to all assistive technologies?
>>>
>>> In mobile view, the navigation is collapsed into a hamburger menu and
>>> the
>>> entire navigation content is announced to screen reader upon receiving
>>> focus. This is unexpected. Additionally, the navigation order from max
>>> view
>>> changes when in mobile mode, where static elements are in between the
>>> navigation options and profile options, but in mobile view, the
>>> navigation
>>> and profile options are one stream of navigation. This might be okay,
>>> but
>>> am not completely sure.
>>> I've got a link to the framework below. Hoping someone can take a look
>>> to
>>> see if anything stands out as glaringly inaccessible and can provide
>>> guidance.
>>> Appreciate the help!
>>>
>>> Terra Framework
>>>
>>> |
>>> |
>>> | |
>>> Terra Framework
>>>
>>>
>>> |
>>>
>>> |
>>>
>>> |
>>>
>>>
>>>
>>>
>>> >>> >>> >>> >>>
>>> >>> >>> >>> >>>
>> >> >> >> >
> > > > >