WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: ARIA for main navigation bar

for

From: Birkir R. Gunnarsson
Date: Apr 24, 2015 7:25AM

The ARIA PFWG has already proposed a new property, aria-current, to
address this need:
http://rawgit.com/w3c/aria/master/aria/aria.html#aria-current

We discussed expanding the role of aria-selected but felt that using a
new attribute was a better solution as aria-selected can have a
slightly different meaning e.g. in a tab/tabpanel widget.

The problem with throwing away all things ARIA and going back to
simple html for the header navigation is that we do not improve the
experience for keyboard-only users that way. PayPal approached this by
implementing a combination of more or less plain html markup and
keyboard support in their Accessible megamenu:
http://adobe-accessibility.github.io/Accessible-Mega-Menu/

One can take it a step back and simply use a collection of expandable sections
http://www.3needs.org/en/testing/code/aria-expanded.html
(i.e. accordions):

(for a fully working accordion, refer to many of Bryan's excellent examples).

Recently I helped implement a button menu solution, though the webpage
is all in Icelandic
http://www.hbs.is (the 2nd, 3rd and 5th buttons in the top navigation list).
An English version of this set-up will be available next week, we are
going to implement a simplified version of same widget for demo
purposes (we are using Bootstrap).

Yes, ARIA is very powerful and can do harm when not used correctly. A
large part of teaching the use of ARIA to developers is telling them
not to use it except where it is appropriate.
But when used correctly, it revolutionizes the way we interact with
the web, especially when we keep pushing to make sure that browsers
and vendors interpret and expose the roles correctly to end users.

-B

On 4/24/15, Jonathan Avila < <EMAIL REMOVED> > wrote:
>> My last point would be that when I'm navigating a menu, I want to get
>> where I'm going (and figure that out) as quickly as possible, and I find
>> that over-ARIA-fication can slow me down.
>
> I agree. Menus and navigation structures continue to be a challenge and
> incorrect and overuse of ARIA is a huge issue in the field. I'd also make
> the following statements about the differences between the two types of
> menus.
>
> 1. When you implement a real ARIA application menu you have to implement all
> of the associated keyboard interactions and required roles.
> 2. Navigation flyouts should not use ARIA menu roles and properties.
> 3. Navigation flyouts should be used for navigation. If a navigation
> structure allows for other features such as checking items or performing
> non-navigation aspects perhaps you should use an ARIA application menu.
>
> I also agree that many keyboard based patterns such as those for menus are
> not working right on mobile devices and thus if a site can be used on a
> mobile environment you need to test and implement for that environment --
> perhaps first.
>
> Jonathan
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> <EMAIL REMOVED>
>
> 703-637-8957 (o)
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf
> Of Jennifer Sutton
> Sent: Thursday, April 23, 2015 5:53 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] ARIA for main navigation bar
>
> I will respond but first want to emphasize two points:
> 1. I was not involved with the development this tutorial, so I cannot speak
> to the thinking behind the recommendations and 2. I speak for myself as
> *one* screen reader user, from my personal perspective, only.
>
>
> Particularly in menus, it seems to me that there *is* a difference when
> using ARIA with a screen reader (and I am speaking only of desktop, here --
> personally, I don't tend to use the Web much on my phone).
>
> I tend to think that a flyout menu, such as the tutorial describes, more
> typically represents what would be needed on a Web site; whereas, using the
> ARIA menubar would be more for a Web *application*. I guess the simplest way
> I can put it is that even if something looks like a menubar, is it really
> *acting* like one?
>
> One of the things that I find with ARIA (and perhaps it's with the
> mis-application of it) is that one can spend a lot of time going in and out
> of application mode to make selections (with JFW, for example). There are
> absolutely cases where this is necessary, but I am not convinced that menus
> are necessarily one of them, except when the Web-based product is working
> like software.
>
> I'm not sure this helps, much.
>
> My last point would be that when I'm navigating a menu, I want to get where
> I'm going (and figure that out) as quickly as possible, and I find that
> over-ARIA-fication can slow me down.
>
> Best,
> Jennifer
>
> At 01:22 PM 4/23/2015, you wrote:
>>Thanks, Jennifer, so glad the WAI is working on tutorials like this.
>>Great to see this guidance. The tutorial indicates that we should be
>>using a "flyout menu" to build navigation. Thus my confusion.
>>Functionally is there a reason to use a flyout menu instead of a web
>>application menu for navigation? I would think that if the web
>>application menu delivers the same functionality for a web page, that
>>it wouldn't matter to the end user, or would it? Do screen readers or
>>interactive features differ between the two on desktop and mobile? Are
>>the ARIA features perceived differently by screen reader users? Or,
>>could an ARIA role "menubar" function just as well as a flyout for
>>simple navigation? Is it important semantically not to represent
>>navigation as a menubar, or vice versa? Questions, questions, so many
>>questions. Best, Judith On 4/23/15 12:13 PM, "Jennifer Sutton"
>>< <EMAIL REMOVED> > wrote: >I'll just put in a quick plug for the
>>menu-related tutorial from
>>WAI: >http://www.w3.org/WAI/tutorials/menus/ > >I'm sure feedback, in
>>the manner described, would be welcome. > >Jennifer > >
>
> > > http://webaim.org/discussion/archives
> > > > > >


--
Work hard. Have fun. Make history.