E-mail List Archives

Search E-mail List Archives for

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

From: Chris Pearce
Date: Tue, Jun 09 2015 12:58AM
Subject: Headings in a Menu Button UI pattern
No previous message | Next message →

Hi,

At my work we have implemented the Menu Button UI pattern as described
here: http://www.w3.org/TR/wai-aria-practices/#menubutton following these
specs:
https://github.com/chris-pearce/accessibility-specs/blob/master/components/menu-button/README.md
and using this markup:
https://github.com/chris-pearce/accessibility-specs/blob/master/components/menu-button/README.md#markup
which works well.

However now we have to implement a version that uses a heading to group
links in the drop down menu like this:

*Heading*
- Link item
- Link item
- Link item
<<-- dividing line -->>
*Heading*
- Link item
- Link item
- Link item

And I'm unsure the best way to implement this in an accessible way?

Is it another `li` with `role="menuitem"` that receives focus like the
links do? Or should the headings be referenced via `aria-labelledby`
attributes on its relevant links?

And semantically I think this type of menu is better suited to a `dl` where
the headings are `dt`s and the links within `dd`s rather than the default
`ul`/`li` setup.

Any advice on the best way to implement this in the most accessible way
would be greatly appreciated.

Thanks a lot,
Chris

--


http://chris-pearce.me
= EMAIL ADDRESS REMOVED =

From: Patrick H. Lauke
Date: Tue, Jun 09 2015 1:11AM
Subject: Re: Headings in a Menu Button UI pattern
← Previous message | Next message →

On 09/06/2015 07:58, Chris Pearce wrote:

> At my work we have implemented the Menu Button UI pattern as described
> here: http://www.w3.org/TR/wai-aria-practices/#menubutton following these
> specs:
> https://github.com/chris-pearce/accessibility-specs/blob/master/components/menu-button/README.md
> and using this markup:
> https://github.com/chris-pearce/accessibility-specs/blob/master/components/menu-button/README.md#markup
> which works well.
>
> However now we have to implement a version that uses a heading to group
> links in the drop down menu like this:
>
> *Heading*
> - Link item
> - Link item
> - Link item
> <<-- dividing line -->>
> *Heading*
> - Link item
> - Link item
> - Link item
>
> And I'm unsure the best way to implement this in an accessible way?
>
> Is it another `li` with `role="menuitem"` that receives focus like the
> links do? Or should the headings be referenced via `aria-labelledby`
> attributes on its relevant links?

It may just be my gut feeling (or the lack of authoritive examples to
the contrary), but I believe that this structure (a menu with extra
headings) does not fit in with the (fairly rigid) ARIA menu pattern,
which only allows for very specific types of menus (which essentially
mirror "standard" native application platform menus). I'd love to be
proven wrong, so if there's any good examples of a kosher menu with
extra headings etc, I'm all ears.

Incidentally, this (and the fact that developers used them for general
navigation, rather than for app-like menus) is the reason why I recently
nuked the role="menu" stuff from Bootstrap - see
https://github.com/twbs/bootstrap/pull/16571

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: Chris Pearce
Date: Tue, Jun 09 2015 1:45AM
Subject: Re: Headings in a Menu Button UI pattern
← Previous message | Next message →

I was thinking does the inclusion of headings now make this not follow the ARIA menu pattern. And if that were the case do the same keyboard behaviours still apply?

Chris

Sent from my iPhone

> On 9 Jun 2015, at 5:11 pm, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>
>> On 09/06/2015 07:58, Chris Pearce wrote:
>>
>> At my work we have implemented the Menu Button UI pattern as described
>> here: http://www.w3.org/TR/wai-aria-practices/#menubutton following these
>> specs:
>> https://github.com/chris-pearce/accessibility-specs/blob/master/components/menu-button/README.md
>> and using this markup:
>> https://github.com/chris-pearce/accessibility-specs/blob/master/components/menu-button/README.md#markup
>> which works well.
>>
>> However now we have to implement a version that uses a heading to group
>> links in the drop down menu like this:
>>
>> *Heading*
>> - Link item
>> - Link item
>> - Link item
>> <<-- dividing line -->>
>> *Heading*
>> - Link item
>> - Link item
>> - Link item
>>
>> And I'm unsure the best way to implement this in an accessible way?
>>
>> Is it another `li` with `role="menuitem"` that receives focus like the
>> links do? Or should the headings be referenced via `aria-labelledby`
>> attributes on its relevant links?
>
> It may just be my gut feeling (or the lack of authoritive examples to the contrary), but I believe that this structure (a menu with extra headings) does not fit in with the (fairly rigid) ARIA menu pattern, which only allows for very specific types of menus (which essentially mirror "standard" native application platform menus). I'd love to be proven wrong, so if there's any good examples of a kosher menu with extra headings etc, I'm all ears.
>
> Incidentally, this (and the fact that developers used them for general navigation, rather than for app-like menus) is the reason why I recently nuked the role="menu" stuff from Bootstrap - see https://github.com/twbs/bootstrap/pull/16571
>
> 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: Patrick H. Lauke
Date: Tue, Jun 09 2015 1:48AM
Subject: Re: Headings in a Menu Button UI pattern
← Previous message | Next message →

On 09/06/2015 08:45, Chris Pearce wrote:
> I was thinking does the inclusion of headings now make this not follow the ARIA menu pattern.

Well yes, that's what I'm thinking/saying.

> And if that were the case do the same keyboard behaviours still apply?

Note also that an ARIA menu is really most appropriate for web
applications that pretend to be/emulate actual apps. If this menu is
just for a site navigation, then I'd argue it's more appropriate NOT to
use it. See

http://www.w3.org/WAI/tutorials/menus/flyout/ (for navigations etc)

versus

http://www.w3.org/WAI/tutorials/menus/application/ (actual application
menus)

P

>
> Chris
>
> Sent from my iPhone
>
>> On 9 Jun 2015, at 5:11 pm, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>>
>>> On 09/06/2015 07:58, Chris Pearce wrote:
>>>
>>> At my work we have implemented the Menu Button UI pattern as described
>>> here: http://www.w3.org/TR/wai-aria-practices/#menubutton following these
>>> specs:
>>> https://github.com/chris-pearce/accessibility-specs/blob/master/components/menu-button/README.md
>>> and using this markup:
>>> https://github.com/chris-pearce/accessibility-specs/blob/master/components/menu-button/README.md#markup
>>> which works well.
>>>
>>> However now we have to implement a version that uses a heading to group
>>> links in the drop down menu like this:
>>>
>>> *Heading*
>>> - Link item
>>> - Link item
>>> - Link item
>>> <<-- dividing line -->>
>>> *Heading*
>>> - Link item
>>> - Link item
>>> - Link item
>>>
>>> And I'm unsure the best way to implement this in an accessible way?
>>>
>>> Is it another `li` with `role="menuitem"` that receives focus like the
>>> links do? Or should the headings be referenced via `aria-labelledby`
>>> attributes on its relevant links?
>>
>> It may just be my gut feeling (or the lack of authoritive examples to the contrary), but I believe that this structure (a menu with extra headings) does not fit in with the (fairly rigid) ARIA menu pattern, which only allows for very specific types of menus (which essentially mirror "standard" native application platform menus). I'd love to be proven wrong, so if there's any good examples of a kosher menu with extra headings etc, I'm all ears.
>>
>> Incidentally, this (and the fact that developers used them for general navigation, rather than for app-like menus) is the reason why I recently nuked the role="menu" stuff from Bootstrap - see https://github.com/twbs/bootstrap/pull/16571
>>
>> 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
>> >> >> >> > > > > >


--
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: Léonie Watson
Date: Tue, Jun 09 2015 3:12AM
Subject: Re: Headings in a Menu Button UI pattern
← Previous message | Next message →

FWIW, headings as part of a menu UI seems unintuitive to me (as a screen reader user). It isn't a design pattern found in software applications, and I'm not sure it's a design pattern we should be considering on the web.

Headings are helpful for navigating and understanding the structure of content. A navigation mechanism is arguably not content in this context.

Léonie.

From: Chris Pearce
Date: Tue, Jun 09 2015 3:26AM
Subject: Re: Headings in a Menu Button UI pattern
← Previous message | Next message →

Patrick it is an application but whether its a *true* application menu I'm
not sure as you could say its just a navigation menu. So the menu button is
the users name, their avatar and a down pointing arrow which when clicked
reveals the menu, within the menu are a list of links going to user setting
pages. This is featured in the application header so available on every
page.

Léonie that's useful feedback thanks. It did get me thinking are these
labels purely presentational? I feel if they didn't exist the menu would
still make sense anyway.


On 9 June 2015 at 19:12, Léonie Watson < = EMAIL ADDRESS REMOVED = > wrote:

> FWIW, headings as part of a menu UI seems unintuitive to me (as a screen
> reader user). It isn't a design pattern found in software applications, and
> I'm not sure it's a design pattern we should be considering on the web.
>
> Headings are helpful for navigating and understanding the structure of
> content. A navigation mechanism is arguably not content in this context.
>
> Léonie.
>
>
> > > > >



--


http://chris-pearce.me
= EMAIL ADDRESS REMOVED =

From: Marco Zehe
Date: Tue, Jun 09 2015 4:12AM
Subject: Re: Headings in a Menu Button UI pattern
← Previous message | Next message →

Hi Chris,

I agree with Léonie here, this definitely sounds more like a navigation
block that should get expanded and collapsed, but not be treated like a
menu. I suggest the following:

1. Give the button that expands and collapses this navigation menu for the
account no role, if you're using a button element, and no aria-haspopup.
Instead, give it an aria-expanded, set to "false" if the menu is currently
not showing, and a value of "true" if it is.
2. When the menu gets inserted/shown, make sure it is inserted in the DOM
*right below/after* that button, so the user can hit Space or Enter to
expand, and then down arrow or VoiceOver+RightArrow into the new items for
the account. Google does this similarly with their Account thing on every
page.
3. Or if it is not possible to insert the items in the DOM at that point,
make sure after setting the visibility to true, to set focus on the first
item within that account navigation block, since it can be assumed the user
wants to interact with this now. Therefore, you can expand the navigation,
and make sure the user doesn't have to search for it.

HTH!

Marco


2015-06-09 11:26 GMT+02:00 Chris Pearce < = EMAIL ADDRESS REMOVED = >:

> Patrick it is an application but whether its a *true* application menu I'm
> not sure as you could say its just a navigation menu. So the menu button is
> the users name, their avatar and a down pointing arrow which when clicked
> reveals the menu, within the menu are a list of links going to user setting
> pages. This is featured in the application header so available on every
> page.
>
> Léonie that's useful feedback thanks. It did get me thinking are these
> labels purely presentational? I feel if they didn't exist the menu would
> still make sense anyway.
>
>
> On 9 June 2015 at 19:12, Léonie Watson < = EMAIL ADDRESS REMOVED = > wrote:
>
> > FWIW, headings as part of a menu UI seems unintuitive to me (as a screen
> > reader user). It isn't a design pattern found in software applications,
> and
> > I'm not sure it's a design pattern we should be considering on the web.
> >
> > Headings are helpful for navigating and understanding the structure of
> > content. A navigation mechanism is arguably not content in this context.
> >
> > Léonie.
> >
> >
> > > > > > > > > >
>
>
>
> --
>
>
> http://chris-pearce.me
> = EMAIL ADDRESS REMOVED =
> > > > >

From: _mallory
Date: Tue, Jun 09 2015 4:19AM
Subject: Re: Headings in a Menu Button UI pattern
← Previous message | Next message →

On Tue, Jun 09, 2015 at 12:12:45PM +0200, Marco Zehe wrote:
...
> 3. Or if it is not possible to insert the items in the DOM at that point,
> make sure after setting the visibility to true, to set focus on the first
> item within that account navigation block, since it can be assumed the user
> wants to interact with this now.

Here we have a difference between users: while a screen reader user
might "be assumed to want to interact with this now", for a sighted
keyboarder it's often just "what is here?". Having my focus moved
into things I only wanted to quick see what was there so then needing
to shift-tab out each time isn't fun.

Though I'm a lazy user and this is just my opinion.

_mallory

From: Marco Zehe
Date: Tue, Jun 09 2015 5:43AM
Subject: Re: Headings in a Menu Button UI pattern
← Previous message | Next message →

OK, for that case an additional suggestion: Each of the elements inside
reacts to the Escape key which a) closes the navigation menu and b) sets
focus back to the button that opened it.

Marco


2015-06-09 12:19 GMT+02:00 _mallory < = EMAIL ADDRESS REMOVED = >:

> On Tue, Jun 09, 2015 at 12:12:45PM +0200, Marco Zehe wrote:
> ...
> > 3. Or if it is not possible to insert the items in the DOM at that point,
> > make sure after setting the visibility to true, to set focus on the first
> > item within that account navigation block, since it can be assumed the
> user
> > wants to interact with this now.
>
> Here we have a difference between users: while a screen reader user
> might "be assumed to want to interact with this now", for a sighted
> keyboarder it's often just "what is here?". Having my focus moved
> into things I only wanted to quick see what was there so then needing
> to shift-tab out each time isn't fun.
>
> Though I'm a lazy user and this is just my opinion.
>
> _mallory
> > > > >

From: Jim Allan
Date: Tue, Jun 09 2015 8:35AM
Subject: Re: Headings in a Menu Button UI pattern
← Previous message | Next message →

too bad we don't the the <lh> element from HTML3
http://www.w3.org/MarkUp/html3/listheader.html

always thought it would be useful. The description sounds much like
<details> and <summary>

though just having some kind of "title" or "caption" or "heading" for a
list like we do for table-caption and images-figure/figcaption would be
useful.

<ul>
<lh>Fruits I Like:<lh>
<li>Apples</li>
<li>Bananas</li>
<li>Oranges</li></ul>



On Tue, Jun 9, 2015 at 6:43 AM, Marco Zehe < = EMAIL ADDRESS REMOVED = > wrote:

> OK, for that case an additional suggestion: Each of the elements inside
> reacts to the Escape key which a) closes the navigation menu and b) sets
> focus back to the button that opened it.
>
> Marco
>
>
> 2015-06-09 12:19 GMT+02:00 _mallory < = EMAIL ADDRESS REMOVED = >:
>
> > On Tue, Jun 09, 2015 at 12:12:45PM +0200, Marco Zehe wrote:
> > ...
> > > 3. Or if it is not possible to insert the items in the DOM at that
> point,
> > > make sure after setting the visibility to true, to set focus on the
> first
> > > item within that account navigation block, since it can be assumed the
> > user
> > > wants to interact with this now.
> >
> > Here we have a difference between users: while a screen reader user
> > might "be assumed to want to interact with this now", for a sighted
> > keyboarder it's often just "what is here?". Having my focus moved
> > into things I only wanted to quick see what was there so then needing
> > to shift-tab out each time isn't fun.
> >
> > Though I'm a lazy user and this is just my opinion.
> >
> > _mallory
> > > > > > > > > >
> > > > >



--
[image: http://www.tsbvi.edu] <http://www.tsbvi.edu>;Jim Allan,
Accessibility Coordinator & Webmaster
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315 fax: 512.206.9264 http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964

From: Moore,Michael (HHSC)
Date: Tue, Jun 09 2015 8:36AM
Subject: Re: Headings in a Menu Button UI pattern
← Previous message | Next message →

Have you spoken to Hixie?

Mike Moore
Accessibility Coordinator
Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)
(512) 574-0091 (Cell)

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Allan
Sent: Tuesday, June 09, 2015 9:35 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Headings in a Menu Button UI pattern

too bad we don't the the <lh> element from HTML3 http://www.w3.org/MarkUp/html3/listheader.html

always thought it would be useful. The description sounds much like <details> and <summary>

though just having some kind of "title" or "caption" or "heading" for a list like we do for table-caption and images-figure/figcaption would be useful.

<ul>
<lh>Fruits I Like:<lh>
<li>Apples</li>
<li>Bananas</li>
<li>Oranges</li></ul>



On Tue, Jun 9, 2015 at 6:43 AM, Marco Zehe < = EMAIL ADDRESS REMOVED = > wrote:

> OK, for that case an additional suggestion: Each of the elements
> inside reacts to the Escape key which a) closes the navigation menu
> and b) sets focus back to the button that opened it.
>
> Marco
>
>
> 2015-06-09 12:19 GMT+02:00 _mallory < = EMAIL ADDRESS REMOVED = >:
>
> > On Tue, Jun 09, 2015 at 12:12:45PM +0200, Marco Zehe wrote:
> > ...
> > > 3. Or if it is not possible to insert the items in the DOM at that
> point,
> > > make sure after setting the visibility to true, to set focus on
> > > the
> first
> > > item within that account navigation block, since it can be assumed
> > > the
> > user
> > > wants to interact with this now.
> >
> > Here we have a difference between users: while a screen reader user
> > might "be assumed to want to interact with this now", for a sighted
> > keyboarder it's often just "what is here?". Having my focus moved
> > into things I only wanted to quick see what was there so then
> > needing to shift-tab out each time isn't fun.
> >
> > Though I'm a lazy user and this is just my opinion.
> >
> > _mallory
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
> > > archives at http://webaim.org/discussion/archives
> >



--
[image: http://www.tsbvi.edu] <http://www.tsbvi.edu>;Jim Allan, Accessibility Coordinator & Webmaster Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315 fax: 512.206.9264 http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964

From: Birkir R. Gunnarsson
Date: Tue, Jun 09 2015 9:05AM
Subject: Re: Headings in a Menu Button UI pattern
← Previous message | Next message →

Adobe decided to avoid the menu role for its accessible megamenu implementation:
https://adobe-accessibility.github.io/Accessible-Mega-Menu/
(it is good, ehough they should have implemented the escape key to
close a menu and move focus back to its trigger element).
You can use group labels and focusable separators inside menus, though
assistive technology support for that is, shall we say, more of a
future proposition rather than today's reality.

I think if you have more than two items with a common label, and you
want to go with a menu construct, group the items into a submenu with
an appropriate triggering element and keyboard navigation (arrow keys
to open and close), or equivalent for touch-screen.
It would simplify keyboard operation as well as provide grouping and a
common label within the context of menus, something users of menus on
operating systems are used to.
Once properly supported, the concept of menus within webpages and apps
can be useful, but today there are technical challenges, such as
functions on mobile devices with assistive technologies, that create
potential barriers.
Cheers
-B


On 6/9/15, Moore,Michael (HHSC) < = EMAIL ADDRESS REMOVED = > wrote:
> Have you spoken to Hixie?
>
> Mike Moore
> Accessibility Coordinator
> Health and Human Services Commission
> Civil Rights Office
> (512) 438-3431 (Office)
> (512) 574-0091 (Cell)
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Jim Allan
> Sent: Tuesday, June 09, 2015 9:35 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Headings in a Menu Button UI pattern
>
> too bad we don't the the <lh> element from HTML3
> http://www.w3.org/MarkUp/html3/listheader.html
>
> always thought it would be useful. The description sounds much like
> <details> and <summary>
>
> though just having some kind of "title" or "caption" or "heading" for a
> list like we do for table-caption and images-figure/figcaption would be
> useful.
>
> <ul>
> <lh>Fruits I Like:<lh>
> <li>Apples</li>
> <li>Bananas</li>
> <li>Oranges</li></ul>
>
>
>
> On Tue, Jun 9, 2015 at 6:43 AM, Marco Zehe < = EMAIL ADDRESS REMOVED = > wrote:
>
>> OK, for that case an additional suggestion: Each of the elements
>> inside reacts to the Escape key which a) closes the navigation menu
>> and b) sets focus back to the button that opened it.
>>
>> Marco
>>
>>
>> 2015-06-09 12:19 GMT+02:00 _mallory < = EMAIL ADDRESS REMOVED = >:
>>
>> > On Tue, Jun 09, 2015 at 12:12:45PM +0200, Marco Zehe wrote:
>> > ...
>> > > 3. Or if it is not possible to insert the items in the DOM at that
>> point,
>> > > make sure after setting the visibility to true, to set focus on
>> > > the
>> first
>> > > item within that account navigation block, since it can be assumed
>> > > the
>> > user
>> > > wants to interact with this now.
>> >
>> > Here we have a difference between users: while a screen reader user
>> > might "be assumed to want to interact with this now", for a sighted
>> > keyboarder it's often just "what is here?". Having my focus moved
>> > into things I only wanted to quick see what was there so then
>> > needing to shift-tab out each time isn't fun.
>> >
>> > Though I'm a lazy user and this is just my opinion.
>> >
>> > _mallory
>> > >> > >> > archives at http://webaim.org/discussion/archives
>> > >> >
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
>
> --
> [image: http://www.tsbvi.edu] <http://www.tsbvi.edu>;Jim Allan, Accessibility
> Coordinator & Webmaster Texas School for the Blind and Visually Impaired
> 1100 W. 45th St., Austin, Texas 78756
> voice 512.206.9315 fax: 512.206.9264 http://www.tsbvi.edu/
> "We shape our tools and thereafter our tools shape us." McLuhan, 1964
> > > http://webaim.org/discussion/archives
> > > > > >


--
Work hard. Have fun. Make history.

From: Andrew Kirkpatrick
Date: Tue, Jun 09 2015 10:48AM
Subject: Re: Headings in a Menu Button UI pattern
← Previous message | Next message →

https://adobe-accessibility.github.io/Accessible-Mega-Menu/
(it is good, ehough they should have implemented the escape key to close a menu and move focus back to its trigger element).

The mega menu implements the escape key as you suggest.
AWK

From: Birkir R. Gunnarsson
Date: Tue, Jun 09 2015 1:23PM
Subject: Re: Headings in a Menu Button UI pattern
← Previous message | No next message

Hey Andrew

You are right. There were a few updates, they must have added it in one of them.


On 6/9/15, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = > wrote:
> https://adobe-accessibility.github.io/Accessible-Mega-Menu/
> (it is good, ehough they should have implemented the escape key to close a
> menu and move focus back to its trigger element).
>
> The mega menu implements the escape key as you suggest.
> AWK
> > > > >


--
Work hard. Have fun. Make history.