Re: ARIA markup and "dual purpose menus"RE: Minutes PF 12 March 2014

I don't really think there is an ARIA based solution for something like 
this, because the triggering element is performing different tasks based on 
the mode of interaction, which is bound to cause accessibility issues for 
somebody at some point, requiring conditional documentation for the user to 
be aware of in advance.

----- Original Message ----- 
From: "Birkir Gunnarsson" <birkir.gunnarsson@deque.com>
To: "'PF'" <public-pfwg@w3.org>
Sent: Wednesday, March 26, 2014 12:07 PM
Subject: ARIA markup and "dual purpose menus"RE: Minutes PF 12 March 2014


> Greetings everyone.
>
> I am new to the list, and hope to get much more involved in meetings and
> exchanges starting this week.
> Travel, projects and CSUN has held me back.
> I am contemplating the use of aria markup for menus where the top menuitem
> itself is a link.
> Brian Garaventa calls these "Dual purpose menus".
> Imagine, if you will, a menubar with top level menus "products" "services"
> and "downloads".
> These are top level items with submenus that appear when you move focus to
> them (onFocus or onHover).
> But if you activate them with the enter key they take you to a different
> page.
> This causes confusion for screen reader users in particular.
> One obvious solution is to create a layer of top level items that are
> Javascript links which, when you activate them with the enter key' open 
> the
> submenus.
> The current link  to the page would be first menuitem in that submenu.
> This clears up the interaction pattern for screen readers certainly, but 
> it
> adds a whole layer of keyboard interaction for everyone else, that appears
> to be clumsy and unnecessary.
> Would it be possible to map an item as both a menuitem and a link, and 
> have
> screen readers responsible for interpreting that as having the menuitem 
> role
> be activated first (if user needs to press enter on the element to 
> activate
> the forms mode, without activating the link, this is similar to the 
> current
> screen reader interpretation of tabs).
>
> One could force screen reader forms mode by using role="application" on a
> div around the menu structure, which is not a very popular thing to do, 
> even
> when possible.
> One could also
> - do away with the menu markup altogether,
> - Keep all content visible to screen readers )hidden off-screen until 
> focus
> is received for everyone else),
> - implement a Javascript arrow key navigation of the menus
> - and tell user to manually turn off the screen reader document mode.
>
> That rather does away with the elegance and simplicity of the menubar/menu
> structure, which is extremely helpful to users when website contain 
> hundreds
> of links.
> (all of this is assuming of course that the developer has created 
> Javascript
> arrow key navigation that corresponds to the keyboard interaction of a
> Windows menubar).
>
> Any thoughts or a link to previous discussions on this would be most
> welcome.
> Thanks
> -Birkir
>
>
>
>
>
>

Received on Friday, 28 March 2014 00:47:00 UTC