E-mail List Archives
Re: Responsive navigation:
From: Emily Ogle
Date: Jun 26, 2019 5:06PM
- Next message: Birkir R. Gunnarsson: "Re: Expected behavior for focus events when using screenreader arrow navigation"
- Previous message: L Snider: "Re: Microsoft Word: Decorative Image Accessibility"
- Next message in Thread: Isabel Holdsworth: "Re: Responsive navigation:"
- Previous message in Thread: Mark Magennis: "Re: [EXTERNAL] Responsive navigation:"
- View all messages in this Thread
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: Birkir R. Gunnarsson: "Re: Expected behavior for focus events when using screenreader arrow navigation"
- Previous message: L Snider: "Re: Microsoft Word: Decorative Image Accessibility"
- Next message in Thread: Isabel Holdsworth: "Re: Responsive navigation:"
- Previous message in Thread: Mark Magennis: "Re: [EXTERNAL] Responsive navigation:"
- View all messages in this Thread