E-mail List Archives
Re: Responsive navigation:
From: Isabel Holdsworth
Date: Jun 27, 2019 5:28AM
- Next message: Mallory: "Re: Expected behavior for focus events when using screenreader arrow navigation"
- Previous message: Birkir R. Gunnarsson: "Re: Expected behavior for focus events when using screenreader arrow navigation"
- Next message in Thread: None
- Previous message in Thread: Emily Ogle: "Re: Responsive navigation:"
- View all messages in this Thread
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 REMOVED> > wrote:
> Thanks all. This is great information.
>
>> On Jun 26, 2019, at 11:17 AM, glen walker < <EMAIL 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 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 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
>>>
>>>
>>> |
>>>
>>> |
>>>
>>> |
>>>
>>>
>>>
>>>
>>> >>> >>> >>> >>>
>>> >>> >>> >>> >>>
>> >> >> >> >
> > > > >
- Next message: Mallory: "Re: Expected behavior for focus events when using screenreader arrow navigation"
- Previous message: Birkir R. Gunnarsson: "Re: Expected behavior for focus events when using screenreader arrow navigation"
- Next message in Thread: None
- Previous message in Thread: Emily Ogle: "Re: Responsive navigation:"
- View all messages in this Thread