WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Is this Navigation or a Menu? How should it work?

for

From: Jonathan Cohn
Date: May 9, 2018 8:47AM


very good points here.

Two additional points:
First, it appears on my that there is a Second nav region surrounding the labeled nav region. I didn't look at the code, but I expect a div with role=navigation is enclosing a nav element. If the designers are concerned that older systems won't recognize the nav element that role should be on the nav element.

Secondly, when tabbing around this type of structure using a screen reader (especially if the areas are expanded on focus) it gets very confusing when one has tabbed beyond the last item in the current list as a blind user. Though of course since these are standard lists one can easily use Browse/Vircutal cursor/QuickNav ) to move through / beyond the lists using standard Screen Reader commands so one is not limited to tab / shift tab to navigate around the Navigation region. But there might be an advantage to having an off-screen status like area that gets updated as lists and sub lists are opened and closed.

And in fact I would define this navigation as a navigation area with menus though it is not really a mega-menu or a menubar even though visually in is very close.


A navigation area would not have items that appear / disappear .
Jonathan Cohn

> On May 9, 2018, at 10:15 AM, glen walker < <EMAIL REMOVED> > wrote:
>
> I don't know if there's a "war" going on between menus and navigation, but
> I agree with your designers in this case. It's essentially a menu of
> navigation elements. It's not a menu in the traditional sense like a
> desktop app where menus perform some kind of action. In your case, the
> menu is taking you to another page so it's performing a navigation instead
> of an action on the page.
>
> Tab and Shift+Tab are perfectly valid when I hear the screen reader tell me
> I have a list of links.
>
> One thing I would change is not mix links and buttons in the menu. Make
> them all links. The items that have a dropdown correctly have
> aria-expanded, you should keep that, but change it from a button to a link.
>
> Also, when a link (formerly button) is expanded and shows the submenu, the
> Escape key should close the submenu.
>
> They also have a bug that if the submenu is displayed and I tab through the
> entire submenu and focus moves back to the main menu, if the next main menu
> item is an expandable item, then the submenu (correctly) dismisses. If the
> next main menu is not an expandable item, the submenu does *not* dismiss -
> that's a bug. For example, expand the "Transaction" menu, tab through the
> submenu to "Culpa". The next tab moves to "Reports" and the submenu
> disappears. That's correct. Now expand the "Admin" submenu and tab
> through "Unilateral". The next tab moves to "Customer" on the main menu
> but the submenu does not dismiss.
>
> Glen
>
>
> On Wed, May 9, 2018 at 7:59 AM, Meacham, Steve - FSA, Kansas City, MO <
> <EMAIL REMOVED> > wrote:
>
>> Live example of a top-navigation menu: http://usda-fsa.github.io/fsa-
>> style/boilerplate.
>>
>> The designers of this user interface rely upon default browser keyboard
>> support only, which is TAB, SHIFT-TAB, SPACE, and ENTER. They do not
>> support arrow keys or the escape key, as I would have expected as a
>> keyboard-only user. I recommended following WAI-ARIA Authoring Practices
>> 1.1 for Menus and Menu buttons, but the authors insist that those do not
>> apply, because it is not a menu, but rather that it is "navigation." I
>> don't get it.
>>
>> First, I was unaware of what they described as an almost religious war
>> about calling this a menu vs calling it navigation. Their claim is that
>> the "navigation" side of this debate is winning or has essentially won.
>>
>> Second, regardless of what we call it, it utilizes a hierarchy of
>> unordered lists containing links, buttons, and headings. I find it
>> tedious, at best, to use with only a keyboard, and impossible to understand
>> and perceive non-visually using a screen reader. I cannot use JAWS to look
>> at the headings on the page, links on the page, the buttons on the page,
>> the lists on the page, or even the regions on the page, to find the choices
>> available to me. The best I can do is realize that there is a Navigation
>> region, use JAWS to jump to it, then navigate sequentially, item by item,
>> pressing buttons when I find them, which unhide nested lists of more of the
>> same.
>>
>> Perhaps the worst thing is I have to remember all the steps I took to
>> drill down to a given choice in order to understand it's context, such as
>> what each "Overview" link is for.
>>
>> But maybe I just have a bad attitude, or my cognitive deficit is due to
>> Multiple Sclerosis, which isn't well-addressed by WCAG, and is just my
>> problem and not a conformance problem. If you're willing and able, please
>> take a look provide me with critical feedback (positive or negative) that I
>> can use with the designers.
>>
>> Steve Meacham, Digital Accessibility Program Manager
>> USDA FSA and FPAC +1 (816) 926-1942<tel:+1-816-926-1942>
>> For program support email <EMAIL REMOVED> <mailto:
>> <EMAIL REMOVED> >
>>
>> Success should not be defined in terms of money, but by helping people to
>> be independent individuals through inclusion.
>>
>>
>>
>>
>>
>> This electronic message contains information generated by the USDA solely
>> for the intended recipients. Any unauthorized interception of this message
>> or the use or disclosure of the information it contains may violate the law
>> and subject the violator to civil or criminal penalties. If you believe you
>> have received this message in error, please notify the sender and delete
>> the email immediately.
>> >> >> >> >>
> > > >