E-mail List Archives

Search E-mail List Archives for

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

From: Judith.A.Blankman
Date: Wed, Apr 22 2015 8:09PM
Subject: ARIA for main navigation bar
No previous message | Next message →

I'm working with developers who are creating a menu bar at the top of a page just (below the main masthead/banner region). Visually it looks like a solid horizontal bar with 4 segments. Each menu item has submenu items stored in a div that is intended to display upon the usual means of interaction. We want to give them the best guidance since they are coding this from scratch.

I think I'm answering my own question by sending this email.

Since I'm still a bit green when it comes to ARIA, I just wanted to confirm that they should code this using ARIA for menubar and not tabs. We were thinking since they don't look like function like tabs that "role=menubar" made more sense.

There are visual hover/focus states and selected states. I was thinking they should use ARIA to indicate the selected state for both the main menu items and the submenu items – does that make sense or should there be only one selected item indicated?

We found this info on the W3C wiki:
http://www.w3.org/WAI/GL/wiki/Using_ARIA_menus

The disclaimer at the top of the page gave us pause, which is also why I'm writing to the list.

We looked at the examples the page linked to at:
http://oaa-accessibility.org/examples/role/86/

I noticed when just using the keyboard in both of these examples that much of the functionality is identical. What's different:

1. http://oaa-accessibility.org/example/25/ displays the submenu as I arrow left/right.
2. http://oaa-accessibility.org/example/26/ I need to hit "enter" or the down arrow for any submenu to display even as I arrow left/right.

Is there a preferred or more common method between the two?

The submenu that the developers are working contains a brief list in a horizontal layout just below the main menubar. Otherwise, it seems to function the same as the examples.


Thanks,


Judith Blankman

Accessibility Strategist
Customer Experience (CX)
WFVC Digital | 1 Front Street | San Francisco, CA 94111
Tel: 415-947-6583 | Cell: 415-601-1114

MAC: A0195-171


j<mailto: = EMAIL ADDRESS REMOVED = > = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >

From: Bryan Garaventa
Date: Thu, Apr 23 2015 12:08PM
Subject: Re: ARIA for main navigation bar
← Previous message | Next message →

> The submenu that the developers are working contains a brief list in a horizontal layout just below the main menubar. Otherwise, it seems to function the same as the examples.

Does this mean that after you arrow into the submenu, you need to press Left/Right to navigate the submenu?

If the menu trigger includes a visual indication such as a downward pointing triangle or the like, then it's up to you whether the submenu visually opens on focus. Either way though, the triggering role=menuitem element must include aria-haspopup="true" to indicate that there is an attached submenu for non-sighted screen reader users.

Also, if pressing Enter on the triggering menuitem A+href=url tag will navigate to another page, it is necessary to surround the container element of the menubar construct with role=application, otherwise when you press Enter on the menu while navigating in Virtual Cursor or Browse mode using JAWS or NVDA, it will open the new page instead of entering Applications mode for interacting with the menus. After Application mode is invoked, pressing Enter again at this point will activate the onclick on the A tag, or pressing Down will navigate into the submenu.

If this dual functionality is the case, then I recommend adding an aria-describedby on each of the A tag role=menuitem elements to reference a hidden element for indicating the correct keystroke to use for doing one or the other action, since it won't be clear that pressing Enter again at this point will open a different browser page.

From: Jennifer Sutton
Date: Thu, Apr 23 2015 1:13PM
Subject: Re: ARIA for main navigation bar
← Previous message | Next message →

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

From: Judith.A.Blankman
Date: Thu, Apr 23 2015 2:22PM
Subject: Re: ARIA for main navigation bar
← Previous message | Next message →

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 ADDRESS 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
>
>>>>

From: Judith.A.Blankman
Date: Thu, Apr 23 2015 2:27PM
Subject: Re: ARIA for main navigation bar
← Previous message | Next message →

Bryan,

I can always count on you to dig into the details with me, much
appreciated!

>> The submenu that the developers are working contains a brief list in a
>>horizontal layout just below the main menubar. Otherwise, it seems to
>>function the same as the examples.
>
>Does this mean that after you arrow into the submenu, you need to press
>Left/Right to navigate the submenu?

No, the up/down arrows move through the submenu list in the examples, the
left/right move though the main menu.

>Also, if pressing Enter on the triggering menuitem A+href=url tag will
>navigate to another page, it is necessary to surround the container
>element of the menubar construct with role=application, otherwise when
>you press Enter on the menu while navigating in Virtual Cursor or Browse
>mode using JAWS or NVDA, it will open the new page instead of entering
>Applications mode for interacting with the menus. After Application mode
>is invoked, pressing Enter again at this point will activate the onclick
>on the A tag, or pressing Down will navigate into the submenu.
>
>If this dual functionality is the case, then I recommend adding an
>aria-describedby on each of the A tag role=menuitem elements to reference
>a hidden element for indicating the correct keystroke to use for doing
>one or the other action, since it won't be clear that pressing Enter
>again at this point will open a different browser page.

There will likely be this type of dual functionality on many of the pages,
so this is great advice.

Thanks!

Judith

From: Jennifer Sutton
Date: Thu, Apr 23 2015 3:52PM
Subject: Re: ARIA for main navigation bar
← Previous message | Next message →

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 ADDRESS 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 > >

From: Patrick H. Lauke
Date: Thu, Apr 23 2015 4:27PM
Subject: Re: ARIA for main navigation bar
← Previous message | Next message →

On 23/04/2015 22:52, Jennifer Sutton wrote:
[...]
> 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.
[...]
> 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'd echo Jennifer's comments here. I've also found (speaking to a few
other AT users, and from my own experience in development/testing) that
overly complex ARIA patterns are sometimes overkill (and the more
complex they are, the less likely they seem to be to work on anything
other than desktop machines with a keyboard, as many of the patterns
rely on custom keyboard event handling - on mobile devices, it seems
that it's up to the AT/browser to work out appropriate gestures/controls
purely from the assigned roles/attributes, meaning that any slight
deviation from a particular complex pattern can result in completely
unusable / unsupported constructs).

In fact, I'm currently considering pulling some of the (well meaning,
but not always helpful/appropriate) ARIA-fied things from the next
version of Bootstrap (for instance, the current pattern used for
menus/dropdowns, which attempts to follow the more application-centric
approach, while most authors seem to be using them primarily as
navigation tools).

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Judith.A.Blankman
Date: Thu, Apr 23 2015 4:54PM
Subject: Re: ARIA for main navigation bar
← Previous message | Next message →

These are great points.

My next questionÅ 

It is my understanding that "aria-selected" can only be applied to menu
items and not list items. So do you recommend simply using hidden text to
communicate a selected or "you are here" state? (Standards pain point, but
I gotta make what we have today work.)

This menu is definitely not a tree, which I know "aria-selected" can also
be used for.

Best,

Judith




On 4/23/15 3:27 PM, "Patrick H. Lauke" < = EMAIL ADDRESS REMOVED = > wrote:

>On 23/04/2015 22:52, Jennifer Sutton wrote:
>[...]
>> 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.
>[...]
>> 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'd echo Jennifer's comments here. I've also found (speaking to a few
>other AT users, and from my own experience in development/testing) that
>overly complex ARIA patterns are sometimes overkill (and the more
>complex they are, the less likely they seem to be to work on anything
>other than desktop machines with a keyboard, as many of the patterns
>rely on custom keyboard event handling - on mobile devices, it seems
>that it's up to the AT/browser to work out appropriate gestures/controls
>purely from the assigned roles/attributes, meaning that any slight
>deviation from a particular complex pattern can result in completely
>unusable / unsupported constructs).
>
>In fact, I'm currently considering pulling some of the (well meaning,
>but not always helpful/appropriate) ARIA-fied things from the next
>version of Bootstrap (for instance, the current pattern used for
>menus/dropdowns, which attempts to follow the more application-centric
>approach, while most authors seem to be using them primarily as
>navigation tools).
>
>P
>--
>Patrick H. Lauke
>
>www.splintered.co.uk | https://github.com/patrickhlauke
>http://flickr.com/photos/redux/ | http://redux.deviantart.com
>twitter: @patrick_h_lauke | skype: patrick_h_lauke
>>>>

From: Bryan Garaventa
Date: Thu, Apr 23 2015 6:29PM
Subject: Re: ARIA for main navigation bar
← Previous message | Next message →

Hi, aria-selected is not valid on menu item elements. Only gridcell, option, row, and tab.
http://www.w3.org/TR/wai-aria/states_and_properties#aria-selected

From: Gijs Veyfeyken
Date: Fri, Apr 24 2015 2:08AM
Subject: Re: ARIA for main navigation bar
← Previous message | Next message →

I think ARIA role="menu" and "menuitem are primarily intended for webapplication menu's, similar to desktop software (file - edit - view - window - help).
For actions, not for navigation.
From what I understand, you're building a simple dropdown navigation menu for a website.
I'd recommend keeping things as simple as possible. Aria role menu makes it more complicating and confusing.
It also prevents submenu items from showing up in a screenreader link list.

Here's a simple and accessible example based on bootstrap and Derek Featherstone's dropdown menu:
https://github.com/AnySurfer/dropdown <https://github.com/AnySurfer/dropdown>

Nice to hear bootstrap is downsizing it's use of ARIA.
If ARIA was sold in a box, it should be labeled with "use with caution".

Kind regards,

Gijs

---
Gijs Veyfeyken
AnySurfer - towards an accessible internet
http://www.anysurfer.be/en <http://www.anysurfer.be/en>;
Brussels - Belgium

From: _mallory
Date: Fri, Apr 24 2015 3:54AM
Subject: Re: ARIA for main navigation bar
← Previous message | Next message →

On Thu, Apr 23, 2015 at 10:54:31PM +0000, = EMAIL ADDRESS REMOVED = wrote:
> These are great points.
>
> My next questionÅ 
>
> It is my understanding that "aria-selected" can only be applied to menu
> items and not list items. So do you recommend simply using hidden text to
> communicate a selected or "you are here" state? (Standards pain point, but
> I gotta make what we have today work.)

In our menus, when you're "inside" the page, the selected category has
a class of "active" to highlight the current cat visually. In the
templates we then also add an offscreen span with "current page: "
before the cat name.

_mallory

From: Jonathan Avila
Date: Fri, Apr 24 2015 7:08AM
Subject: Re: ARIA for main navigation bar
← Previous message | Next message →

> It is my understanding that "aria-selected" can only be applied to menu items and not list items. So do you

I've commented to the PFWG on this -- I personally feel like this trait should be able to be applied to all sorts of widgets. I'd prefer a pattern or trait based method that we see in UIA and Apple's Accessibility Protocol that would allow us more flexibility to apply pattern properties to controls regardless of a fixed role. I'd encourage other people to comment to the ARIA task force if you feel the same.

Jonathan

--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =

703-637-8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter

From: Jonathan Avila
Date: Fri, Apr 24 2015 7:17AM
Subject: Re: ARIA for main navigation bar
← Previous message | Next message →

> 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 ADDRESS REMOVED =

703-637-8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter

From: Birkir R. Gunnarsson
Date: Fri, Apr 24 2015 7:25AM
Subject: Re: ARIA for main navigation bar
← Previous message | No next message

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 ADDRESS 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 ADDRESS REMOVED =
>
> 703-637-8957 (o)
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
>