We've been working on getting keyboard and ARIA support into our
flyout/iPod menu prototype that will prove as a starting point /
resource for the jQuery UI menu widget.
The following markup is the basic structure we went with. It validates
now in the HTML 5 validator tool but I wanted to see if anyone had
input on this structure and whether we're using all of the attributes
properly. I've attached some questions at the bottom, as well as a
link to our current implementation which has all this built-in.
Questions:
- should the role="application" attribute be lower in the markup?
Perhaps on a div wrapper of the menu? Just wondering since we probably
can't count on adding that to just any page that has a menu... right?
- We're a little confused by the relation of the menu button to the
menu itself. Should it be a button element? Should it be a link with a
role of button? What about a role of spinbutton? Currently, we're
using an anchor with a hash url corresponding to the menu's ID. The
menu has an aria-labeledby attribute corresponding to the button's ID.
Is this adequate?
- for the aria-activedescendent attribute, we were assuming that could
use a roving ID for the focused element. Is this proper?
Here is a demo of our current code if you happen to have time to test
it on an AT device
ARIA support is still not mature in any of the screen readers I've tried, so its difficult to assess how well this will work.
When I tried the link you provide, application mode is enabled, and I'm pretty sure its seeing the menu as a menu (i.e. its dealing with the role correctly), but keyboard navigation is not enabled. Not sure if this is your code or the Jaws screen reader ineptness.
As per the role="application", I'd hope that this is meant to be placed on any element to make all elements in that subtree behave like an application. I've done some quick testing with Jaws and it does seem to support this, but it does not switch smoothly between the two modes. I've sent a message to my contact at Freedom Scientific asking them to take a look at this issue. I'll forward any comments I get back to this group.
----- Original Message ----- From: "ScottJehl" <sc...@scottjehl.com>
To: "jQuery Accessibility" <jquery-a11y@googlegroups.com>
Sent: Tuesday, March 31, 2009 12:55 PM
Subject: Hierarchical menu ARIA markup -- looking for input
We've been working on getting keyboard and ARIA support into our
flyout/iPod menu prototype that will prove as a starting point /
resource for the jQuery UI menu widget.
The following markup is the basic structure we went with. It validates
now in the HTML 5 validator tool but I wanted to see if anyone had
input on this structure and whether we're using all of the attributes
properly. I've attached some questions at the bottom, as well as a
link to our current implementation which has all this built-in.
Questions:
- should the role="application" attribute be lower in the markup?
Perhaps on a div wrapper of the menu? Just wondering since we probably
can't count on adding that to just any page that has a menu... right?
- We're a little confused by the relation of the menu button to the
menu itself. Should it be a button element? Should it be a link with a
role of button? What about a role of spinbutton? Currently, we're
using an anchor with a hash url corresponding to the menu's ID. The
menu has an aria-labeledby attribute corresponding to the button's ID.
Is this adequate?
- for the aria-activedescendent attribute, we were assuming that could
use a roving ID for the focused element. Is this proper?
Here is a demo of our current code if you happen to have time to test
it on an AT device
I made a testcase with a menubar that worked with Jaws 9 and NVDA. But
I made some very little changes to the keyboard navigation and this
fact made it totally inaccessible. The HTML-structure looked like
this:
I will make some tests with your script and your HTML, but by now i
see the following problems:
1. I didnīt needed to set the application-role. If the screenreader
see a menubar. It will automaticly switch to a mode, wich can handle
this widget.
2. The active-menu Item should be the anchor element in your example.
(the menu item does not contain the submenu). (but there is a bug in
Jaws 9: if you set the menuitem-role to an anchor, Jaws will read the
content of href-attribute, too.
3. Your menu-button should have the following structure: <a
id="menubutton" role="button" aria-haspopup="true" href="#menu">ARIA
Tree Example</a> <!-- there is a special role called menubutton, too.
but button should also worked and is testet -->
4.If you are managing the focus with the activedescendant-method. The
element, wich has this attribute has to recieve focus. in your example
the menu has this attribute, but the focus is still on the menubutton.
If you look on my HTML you will see that i have used aria-hidden and
the presentation role. My tests showed, that these attributes were not
really needed in my widget. The Jaws and NVDA seem to look directly to
the display-property (none/block), of some elements and can handle
dynamic changes with these elements.
regards
alex
On Mar 31, 8:40 pm, Rich Caloggero <rich_calogg...@wgbh.org> wrote:
> ARIA support is still not mature in any of the screen readers I've tried, so
> its difficult to assess how well this will work.
> When I tried the link you provide, application mode is enabled, and I'm
> pretty sure its seeing the menu as a menu (i.e. its dealing with the role
> correctly), but keyboard navigation is not enabled. Not sure if this is your
> code or the Jaws screen reader ineptness.
> As per the role="application", I'd hope that this is meant to be placed on
> any element to make all elements in that subtree behave like an application.
> I've done some quick testing with Jaws and it does seem to support this, but
> it does not switch smoothly between the two modes. I've sent a message to my
> contact at Freedom Scientific asking them to take a look at this issue.
> I'll forward any comments I get back to this group.
> Hope this helps.
> -- Rich
> ----- Original Message -----
> From: "ScottJehl" <sc...@scottjehl.com>
> To: "jQuery Accessibility" <jquery-a11y@googlegroups.com>
> Sent: Tuesday, March 31, 2009 12:55 PM
> Subject: Hierarchical menu ARIA markup -- looking for input
> We've been working on getting keyboard and ARIA support into our
> flyout/iPod menu prototype that will prove as a starting point /
> resource for the jQuery UI menu widget.
> The following markup is the basic structure we went with. It validates
> now in the HTML 5 validator tool but I wanted to see if anyone had
> input on this structure and whether we're using all of the attributes
> properly. I've attached some questions at the bottom, as well as a
> link to our current implementation which has all this built-in.
> Questions:
> - should the role="application" attribute be lower in the markup?
> Perhaps on a div wrapper of the menu? Just wondering since we probably
> can't count on adding that to just any page that has a menu... right?
> - We're a little confused by the relation of the menu button to the
> menu itself. Should it be a button element? Should it be a link with a
> role of button? What about a role of spinbutton? Currently, we're
> using an anchor with a hash url corresponding to the menu's ID. The
> menu has an aria-labeledby attribute corresponding to the button's ID.
> Is this adequate?
> - for the aria-activedescendent attribute, we were assuming that could
> use a roving ID for the focused element. Is this proper?
> Here is a demo of our current code if you happen to have time to test
> it on an AT device
----- Original Message ----- From: "alexander farkas" <i...@corrupt-system.de>
To: "jQuery Accessibility" <jquery-a11y@googlegroups.com>
Sent: Wednesday, April 01, 2009 4:02 PM
Subject: Re: Hierarchical menu ARIA markup -- looking for input
I made a testcase with a menubar that worked with Jaws 9 and NVDA. But
I made some very little changes to the keyboard navigation and this
fact made it totally inaccessible. The HTML-structure looked like
this:
I will make some tests with your script and your HTML, but by now i
see the following problems:
1. I didnīt needed to set the application-role. If the screenreader
see a menubar. It will automaticly switch to a mode, wich can handle
this widget.
2. The active-menu Item should be the anchor element in your example.
(the menu item does not contain the submenu). (but there is a bug in
Jaws 9: if you set the menuitem-role to an anchor, Jaws will read the
content of href-attribute, too.
3. Your menu-button should have the following structure: <a
id="menubutton" role="button" aria-haspopup="true" href="#menu">ARIA
Tree Example</a> <!-- there is a special role called menubutton, too.
but button should also worked and is testet -->
4.If you are managing the focus with the activedescendant-method. The
element, wich has this attribute has to recieve focus. in your example
the menu has this attribute, but the focus is still on the menubutton.
If you look on my HTML you will see that i have used aria-hidden and
the presentation role. My tests showed, that these attributes were not
really needed in my widget. The Jaws and NVDA seem to look directly to
the display-property (none/block), of some elements and can handle
dynamic changes with these elements.
regards
alex
On Mar 31, 8:40Â pm, Rich Caloggero <rich_calogg...@wgbh.org> wrote:
> ARIA support is still not mature in any of the screen readers I've tried, > so
> its difficult to assess how well this will work.
> When I tried the link you provide, application mode is enabled, and I'm
> pretty sure its seeing the menu as a menu (i.e. its dealing with the role
> correctly), but keyboard navigation is not enabled. Not sure if this is > your
> code or the Jaws screen reader ineptness.
> As per the role="application", I'd hope that this is meant to be placed on
> any element to make all elements in that subtree behave like an > application.
> I've done some quick testing with Jaws and it does seem to support this, > but
> it does not switch smoothly between the two modes. I've sent a message to > my
> contact at Freedom Scientific asking them to take a look at this issue.
> I'll forward any comments I get back to this group.
> Hope this helps.
> -- Rich
> ----- Original Message -----
> From: "ScottJehl" <sc...@scottjehl.com>
> To: "jQuery Accessibility" <jquery-a11y@googlegroups.com>
> Sent: Tuesday, March 31, 2009 12:55 PM
> Subject: Hierarchical menu ARIA markup -- looking for input
> We've been working on getting keyboard and ARIA support into our
> flyout/iPod menu prototype that will prove as a starting point /
> resource for the jQuery UI menu widget.
> The following markup is the basic structure we went with. It validates
> now in the HTML 5 validator tool but I wanted to see if anyone had
> input on this structure and whether we're using all of the attributes
> properly. I've attached some questions at the bottom, as well as a
> link to our current implementation which has all this built-in.
> Questions:
> - should the role="application" attribute be lower in the markup?
> Perhaps on a div wrapper of the menu? Just wondering since we probably
> can't count on adding that to just any page that has a menu... right?
> - We're a little confused by the relation of the menu button to the
> menu itself. Should it be a button element? Should it be a link with a
> role of button? What about a role of spinbutton? Currently, we're
> using an anchor with a hash url corresponding to the menu's ID. The
> menu has an aria-labeledby attribute corresponding to the button's ID.
> Is this adequate?
> - for the aria-activedescendent attribute, we were assuming that could
> use a roving ID for the focused element. Is this proper?
> Here is a demo of our current code if you happen to have time to test
> it on an AT device
I didnīt looked carefully to your questions, so i try to answer:
1. role: application. Like i sayed, i donīt think, that an application-
role is needed to get the menu/menubar to work
2. menubutton. if you mix the role: button with the property haspopup,
jaws and nvda will recognize a menubutton (but we should test the
menubutton). to label the menu with the menubutton is a nice idea. i
canīt tell wether this increases a11y (but it doesnīt harm, so itīs
good).
3. your activedescendent question: this is a really hard question. i
suppose using only one id and roving it through the items wonīt work.
You have to change the attribute itself, i guess (+ like I mentioned
above: the element, that has this attribute has to have focus)
There are some nice video-demos by Todd Kloots form yahoo (http://
video.yahoo.com/mypage/video/2846939).
He shows also an example of a menubutton with the activedescendent-
method, but i donīt know where we can get the source-files.
There is also a nice video form him called 'Developing Accessible
Widgets using ARIA'. He describes 2 techniques to manage focus. One
called rouming tabindex and the other is the activedecendent-method.
He doesnīt talk a lot about the activedescendent-mehtod, but like I
understand him, that you have to change the attribute vlaue itself. At
least he advice developers to use the roaming tabindex technique.
regards
alex
On Mar 31, 6:55 pm, ScottJehl <sc...@scottjehl.com> wrote:
> We've been working on getting keyboard and ARIA support into our
> flyout/iPod menu prototype that will prove as a starting point /
> resource for the jQuery UI menu widget.
> The following markup is the basic structure we went with. It validates
> now in the HTML 5 validator tool but I wanted to see if anyone had
> input on this structure and whether we're using all of the attributes
> properly. I've attached some questions at the bottom, as well as a
> link to our current implementation which has all this built-in.
> Questions:
> - should the role="application" attribute be lower in the markup?
> Perhaps on a div wrapper of the menu? Just wondering since we probably
> can't count on adding that to just any page that has a menu... right?
> - We're a little confused by the relation of the menu button to the
> menu itself. Should it be a button element? Should it be a link with a
> role of button? What about a role of spinbutton? Currently, we're
> using an anchor with a hash url corresponding to the menu's ID. The
> menu has an aria-labeledby attribute corresponding to the button's ID.
> Is this adequate?
> - for the aria-activedescendent attribute, we were assuming that could
> use a roving ID for the focused element. Is this proper?
> Here is a demo of our current code if you happen to have time to test
> it on an AT device
> I didnīt looked carefully to your questions, so i try to answer:
> 1. role: application. Like i sayed, i donīt think, that an application-
> role is needed to get the menu/menubar to work
> 2. menubutton. if you mix the role: button with the property haspopup,
> jaws and nvda will recognize a menubutton (but we should test the
> menubutton). to label the menu with the menubutton is a nice idea. i
> canīt tell wether this increases a11y (but it doesnīt harm, so itīs
> good).
> 3. your activedescendent question: this is a really hard question. i
> suppose using only one id and roving it through the items wonīt work.
> You have to change the attribute itself, i guess (+ like I mentioned
> above: the element, that has this attribute has to have focus)
> There are some nice video-demos by Todd Kloots form yahoo (http://
> video.yahoo.com/mypage/video/2846939).
> He shows also an example of a menubutton with the activedescendent-
> method, but i donīt know where we can get the source-files.
> There is also a nice video form him called 'Developing Accessible
> Widgets using ARIA'. He describes 2 techniques to manage focus. One
> called rouming tabindex and the other is the activedecendent-method.
> He doesnīt talk a lot about the activedescendent-mehtod, but like I
> understand him, that you have to change the attribute vlaue itself. At
> least he advice developers to use the roaming tabindex technique.
> regards
> alex
> On Mar 31, 6:55 pm, ScottJehl <sc...@scottjehl.com> wrote:
> > We've been working on getting keyboard and ARIA support into our
> > flyout/iPod menu prototype that will prove as a starting point /
> > resource for the jQuery UI menu widget.
> > The following markup is the basic structure we went with. It validates
> > now in the HTML 5 validator tool but I wanted to see if anyone had
> > input on this structure and whether we're using all of the attributes
> > properly. I've attached some questions at the bottom, as well as a
> > link to our current implementation which has all this built-in.
> > Questions:
> > - should the role="application" attribute be lower in the markup?
> > Perhaps on a div wrapper of the menu? Just wondering since we probably
> > can't count on adding that to just any page that has a menu... right?
> > - We're a little confused by the relation of the menu button to the
> > menu itself. Should it be a button element? Should it be a link with a
> > role of button? What about a role of spinbutton? Currently, we're
> > using an anchor with a hash url corresponding to the menu's ID. The
> > menu has an aria-labeledby attribute corresponding to the button's ID.
> > Is this adequate?
> > - for the aria-activedescendent attribute, we were assuming that could
> > use a roving ID for the focused element. Is this proper?
> > Here is a demo of our current code if you happen to have time to test
> > it on an AT device
1. I seem to remember something in the ARIA talk at SXSW about using
role="application" to free up tab order without using tabindex -1
everywhere. Do you have any idea on that? It seems odd that the role
is never necessary though... maybe Jaws is being lenient on that?
2. Good info, we'll try that thanks. Also, is the hash link to the
menu content the best way to transfer focus? What about aria-owns?
3. Hmm interesting, ok. I'll watch the videos, thanks.
A few questions about your code sample:
1. You aren't using the menu role, just menubar... isn't menu more
appropriate? Why the switch?
2. If we put the menuitem roles on anything but an immediate child of
menu, the validator says it's incorrect. In our markup, the spec says
these roles need to be on the LI's. Have you seen any other markup
examples for a proper ARIA menu that also works in screenreaders?
1. application role
I think, the role is necessary in a real application or a site wich
contains a lot of aria-widgets and forms, but very few text-sematic
(i.e. p, heading etc.). In these cases the user should be always in
apllication mode and should not switch. but my understanding is not
very good here. But I donīt know where much about the screen reader
modes.
2. transfer focus (I donīt know, wether i understand you right, here.)
To transfer focus, you should use the DOM-method focus (if you would
use the hash, the hole site would jump). aria-owns isnīt right here.
aria-controls would be better (but your aria-labeldby already connects
the two elements),
My code:
1. menubar
i didnīt want to switch your code to menubar. I was only using menubar
+ menu roles in my old testcase.
the differences between menubar and menu:
a) menubar is horizontal, menu is vertical (keyboard interaction has
to take this into account)
b) menubar is initially visible and every menuitem has a poup with the
role menu. the menu should be always hidden and opened by an
interaction (click on menuitem in menubar, click on menubutton etc.)
(<- i didnīt read something about this, but i couldnīt get a menu work
properly if it was initialy visible and was focused by a normal tab
action. I think it has something to do with the fact, that in windows
the menubar is assigned to the msaa role popupmenu.)
2. Most examples i have seen, doesnīt try to use a semantic
fallback.the structure was often like this:
<div role="menu">
<span role="menuitem" aria-haspopup="true">Open Menue</span>
<div role="menu">....</div>
</div>
YUI is also using an ul-structure and they are adding the presentation
role to the ul and li and the menuitem-role to the anchor (+ they don
īt use a href-attribute):
http://developer.yahoo.com/yui/examples/menu/menuwaiaria_source.html
I played yesterday a little bit with your menu, but couldnīt get it
work (it was very strange...).
regards
alex
On Apr 2, 4:19 pm, ScottJehl <sc...@scottjehl.com> wrote:
> 1. I seem to remember something in the ARIA talk at SXSW about using
> role="application" to free up tab order without using tabindex -1
> everywhere. Do you have any idea on that? It seems odd that the role
> is never necessary though... maybe Jaws is being lenient on that?
> 2. Good info, we'll try that thanks. Also, is the hash link to the
> menu content the best way to transfer focus? What about aria-owns?
> 3. Hmm interesting, ok. I'll watch the videos, thanks.
> A few questions about your code sample:
> 1. You aren't using the menu role, just menubar... isn't menu more
> appropriate? Why the switch?
> 2. If we put the menuitem roles on anything but an immediate child of
> menu, the validator says it's incorrect. In our markup, the spec says
> these roles need to be on the LI's. Have you seen any other markup
> examples for a proper ARIA menu that also works in screenreaders?
I tested in FF3, Windows with JAWS10. I am not sure how this should
work, but when I navigate the menu items with the keyboard I am not
alerted to any state change by JAWS, so if I were blind I would have
no idea where I am in the menu.
On Mar 31, 12:55 pm, ScottJehl <sc...@scottjehl.com> wrote:
> We've been working on getting keyboard and ARIA support into our
> flyout/iPod menu prototype that will prove as a starting point /
> resource for the jQuery UI menu widget.
> The following markup is the basic structure we went with. It validates
> now in the HTML 5 validator tool but I wanted to see if anyone had
> input on this structure and whether we're using all of the attributes
> properly. I've attached some questions at the bottom, as well as a
> link to our current implementation which has all this built-in.
> Questions:
> - should the role="application" attribute be lower in the markup?
> Perhaps on a div wrapper of the menu? Just wondering since we probably
> can't count on adding that to just any page that has a menu... right?
> - We're a little confused by the relation of the menu button to the
> menu itself. Should it be a button element? Should it be a link with a
> role of button? What about a role of spinbutton? Currently, we're
> using an anchor with a hash url corresponding to the menu's ID. The
> menu has an aria-labeledby attribute corresponding to the button's ID.
> Is this adequate?
> - for the aria-activedescendent attribute, we were assuming that could
> use a roving ID for the focused element. Is this proper?
> Here is a demo of our current code if you happen to have time to test
> it on an AT device
> I tested in FF3, Windows with JAWS10. I am not sure how this should
> work, but when I navigate the menu items with the keyboard I am not
> alerted to any state change by JAWS, so if I were blind I would have
> no idea where I am in the menu.
> On Mar 31, 12:55 pm, ScottJehl <sc...@scottjehl.com> wrote:
> > We've been working on getting keyboard and ARIA support into our
> > flyout/iPod menu prototype that will prove as a starting point /
> > resource for the jQuery UI menu widget.
> > The following markup is the basic structure we went with. It validates
> > now in the HTML 5 validator tool but I wanted to see if anyone had
> > input on this structure and whether we're using all of the attributes
> > properly. I've attached some questions at the bottom, as well as a
> > link to our current implementation which has all this built-in.
> > Questions:
> > - should the role="application" attribute be lower in the markup?
> > Perhaps on a div wrapper of the menu? Just wondering since we probably
> > can't count on adding that to just any page that has a menu... right?
> > - We're a little confused by the relation of the menu button to the
> > menu itself. Should it be a button element? Should it be a link with a
> > role of button? What about a role of spinbutton? Currently, we're
> > using an anchor with a hash url corresponding to the menu's ID. The
> > menu has an aria-labeledby attribute corresponding to the button's ID.
> > Is this adequate?
> > - for the aria-activedescendent attribute, we were assuming that could
> > use a roving ID for the focused element. Is this proper?
> > Here is a demo of our current code if you happen to have time to test
> > it on an AT device
> 1. I seem to remember something in the ARIA talk at SXSW about using > role="application" to free up tab order without using tabindex -1 > everywhere. Do you have any idea on that? It seems odd that the role > is never necessary though... maybe Jaws is being lenient on that?
The roles "application" and "document" put the screen reader in modes appropriate for web applications or documents, respectively.
In application mode, pages can only be navigated with tab/shift+tab, which moves among focusable elements such as links and form controls, or whatever you choose to make focussable.
Document mode allows one to tab as normal, but also allows the user to arrow through the document, and adds a host of shortcut keys which do things like move to next/previous html heading, list element, paragraph, etc.
> 2. Good info, we'll try that thanks. Also, is the hash link to the > menu content the best way to transfer focus? What about aria-owns?
I'm not totally sure on this, but in one approach focus is transfered by widgit code in an event handler via code like: setTimeout(function () { element.focus(); }, 0);
The other approach uses aria-owns somehow (I think you set it to the ID of an element which is to gain focus and the screen reader actually changes the focus). Again, I'm not so clear on this myself so check out the following for more:
Rich, thanks for the info, it's really helpful -- I'll definitely
check out those links.
I also wanted to let you all know that the key events are working now
in IE & Safari...and hopefully elsewhere. If you have a chance to
check out the menus again, let us know if you notice a difference.
> > 1. I seem to remember something in the ARIA talk at SXSW about using
> > role="application" to free up tab order without using tabindex -1
> > everywhere. Do you have any idea on that? It seems odd that the role
> > is never necessary though... maybe Jaws is being lenient on that?
> The roles "application" and "document" put the screen reader in modes
> appropriate for web applications or documents, respectively.
> In application mode, pages can only be navigated with tab/shift+tab, which
> moves among focusable elements such as links and form controls, or whatever
> you choose to make focussable.
> Document mode allows one to tab as normal, but also allows the user to arrow
> through the document, and adds a host of shortcut keys which do things like
> move to next/previous html heading, list element, paragraph, etc.
> > 2. Good info, we'll try that thanks. Also, is the hash link to the
> > menu content the best way to transfer focus? What about aria-owns?
> I'm not totally sure on this, but in one approach focus is transfered by
> widgit code in an event handler via code like:
> setTimeout(function () { element.focus(); }, 0);
> The other approach uses aria-owns somehow (I think you set it to the ID of
> an element which is to gain focus and the screen reader actually changes the
> focus). Again, I'm not so clear on this myself so check out the following
> for more:
There were several problems in the script. for example: You were using
both the focus- and the activedescendant-approach at once. But you
have to choose one of them. I implemented the activedescendant-
approach. In the ui.menu, I would recommend to use the "roaming
tabindex technique".
There are still 2 problems in your script:
1. You are handling mouse- and keyboard interaction the same way, but
this isnīt allowed. for example focusing a mneuitem with a submenu
doesnīt open the submenu. Only a useraction (key right or key enter)
should immediately open it.
2. The submenu itself has to be hidden (aria-hidden + display: none).
But the first submenu is wrapped by position-helper and the .fg-menu-
container, wich are making the submenu hidden or visible.
I didnīt wanted to fix these problems, because this would mean a
rewrite of your script. Instead I made a workaround for the first
submenu. (This workaround doesnīt work in NVDA, but I wrote a
testcase, wich works properly)
I would suggest to start implementing Aria + Keyboard-Interaction to
the real UI menu to accelerate the progress. I would help Scott in
this case. I also would suggest, that we add keyboard interaction
directly to the menu-script, but aria-support in an extension.
Last has 2 pros:
1. By creating an extension, we can test theflexibility of the
existing Menu-API
2. Aria-Suport in case off the menu-script adds a lot of performance-
load to the script
> 1. I seem to remember something in the ARIA talk at SXSW about using > role="application" to free up tab order without using tabindex -1 > everywhere. Do you have any idea on that? It seems odd that the role > is never necessary though... maybe Jaws is being lenient on that?
First, sorry this whole thread got lost in my stack.
Probably the best way to think about using the landmark role="application" is when you want to tell assistive technology that this part of the dom is not really just a bunch of words to be read (via keyboard commands), but is instead an interactive UI, so "please let the keyboard events pass through to the browser/dom".
----- Original Message ----- From: "alexander farkas" <i...@corrupt-system.de>
To: "jQuery Accessibility" <jquery-a11y@googlegroups.com>
Sent: Wednesday, April 15, 2009 9:52 AM
Subject: Re: Hierarchical menu ARIA markup -- looking for input
There were several problems in the script. for example: You were using
both the focus- and the activedescendant-approach at once. But you
have to choose one of them. I implemented the activedescendant-
approach. In the ui.menu, I would recommend to use the "roaming
tabindex technique".
There are still 2 problems in your script:
1. You are handling mouse- and keyboard interaction the same way, but
this isnīt allowed. for example focusing a mneuitem with a submenu
doesnīt open the submenu. Only a useraction (key right or key enter)
should immediately open it.
2. The submenu itself has to be hidden (aria-hidden + display: none).
But the first submenu is wrapped by position-helper and the .fg-menu-
container, wich are making the submenu hidden or visible.
I didnīt wanted to fix these problems, because this would mean a
rewrite of your script. Instead I made a workaround for the first
submenu. (This workaround doesnīt work in NVDA, but I wrote a
testcase, wich works properly)
I would suggest to start implementing Aria + Keyboard-Interaction to
the real UI menu to accelerate the progress. I would help Scott in
this case. I also would suggest, that we add keyboard interaction
directly to the menu-script, but aria-support in an extension.
Last has 2 pros:
1. By creating an extension, we can test theflexibility of the
existing Menu-API
2. Aria-Suport in case off the menu-script adds a lot of performance-
load to the script
thx for your feedback. I forgot some debug code in the keydown
eventhandler, this caused an error in my script. Now, you can test it
again. Plz, be also patient with this menu-script. There are several
little problems I didnīt wanted to fix, because it would take too much
work and time. Like already said, we should put this effort in the
real script and not in a prototype.
regards
alex
On 15 Apr., 19:25, Rich Caloggero <rich_calogg...@wgbh.org> wrote:
> The demo you mention below still does not work for me using Jaws10 and
> FF rv:1.9.1b4pre) Gecko/20090415 Shiretoko/3.5b4pre
> I cannot tell if the problems are with the demo itself, or Jaws support; I
> cannot see the screen at all so am relying soley on Jaws.
> Try this demo; it does mostly work keyboard-only and Jaws mostly behaves
> (although it still does not do the right thing when attempting to move
> across the menubar when all menus are closed. Demo is at:http://test.cita.illinois.edu/aria/menubar/view_inline.php?title=Menu...
> There were several problems in the script. for example: You were using
> both the focus- and the activedescendant-approach at once. But you
> have to choose one of them. I implemented the activedescendant-
> approach. In the ui.menu, I would recommend to use the "roaming
> tabindex technique".
> There are still 2 problems in your script:
> 1. You are handling mouse- and keyboard interaction the same way, but
> this isnīt allowed. for example focusing a mneuitem with a submenu
> doesnīt open the submenu. Only a useraction (key right or key enter)
> should immediately open it.
> 2. The submenu itself has to be hidden (aria-hidden + display: none).
> But the first submenu is wrapped by position-helper and the .fg-menu-
> container, wich are making the submenu hidden or visible.
> I didnīt wanted to fix these problems, because this would mean a
> rewrite of your script. Instead I made a workaround for the first
> submenu. (This workaround doesnīt work in NVDA, but I wrote a
> testcase, wich works properly)
> I would suggest to start implementing Aria + Keyboard-Interaction to
> the real UI menu to accelerate the progress. I would help Scott in
> this case. I also would suggest, that we add keyboard interaction
> directly to the menu-script, but aria-support in an extension.
> Last has 2 pros:
> 1. By creating an extension, we can test theflexibility of the
> existing Menu-API
> 2. Aria-Suport in case off the menu-script adds a lot of performance-
> load to the script
OK, on the flat menu, the keyboard controls work (woohoo)!
How do I display the other menus (I see lots of nested lists in the HTML; should this be able to display somehow or is this old or unused code).
Question: are you assigning a role="application" somewhere? I am not able to read the menu log (which should tell me which item is selected in the menu).
The idea behind the two modes (application and document) is this. WIth screen readers like Jaws, the reader takes a snapshot of the website when the page loads. It converts this to a flat textual representation which can then be perused at will using many built-in shortcut keys etc. This facility is called the virtual buffer. The problem is that when we want input from the user, we need to switch modes and allow all keyboard input to go directly to the application (the browser). In normal operation this mode switching is supposed to happen automatically when an input control such as text input form control or select list gets focus. Since aria lets you build arbitrary widgits from other HTML bits, you can force keyboard control to the widgit by setting its role to application. However, if there is a part of the page which should be able to be perused at will (like the log in this case), we need a way of telling the screen reader that this subtree should be made available through the screen reader's virtual buffer as is normally the case. This is why one should never put a role of application on the entire document. I'm also not sure if Jaws is correctly switching from mode to mode as focus moves through the document.
Just put role="document" on the menu log and I'll test it again. I was going to do it myself, but didn't want to deal with getting all the external .js files on my machine...
----- Original Message ----- From: "alexander farkas" <i...@corrupt-system.de>
To: "jQuery Accessibility" <jquery-a11y@googlegroups.com>
Sent: Wednesday, April 15, 2009 3:33 PM
Subject: Re: Hierarchical menu ARIA markup -- looking for input
Hi Rich,
thx for your feedback. I forgot some debug code in the keydown
eventhandler, this caused an error in my script. Now, you can test it
again. Plz, be also patient with this menu-script. There are several
little problems I didnīt wanted to fix, because it would take too much
work and time. Like already said, we should put this effort in the
real script and not in a prototype.
regards
alex
On 15 Apr., 19:25, Rich Caloggero <rich_calogg...@wgbh.org> wrote:
> The demo you mention below still does not work for me using Jaws10 and
> FF rv:1.9.1b4pre) Gecko/20090415 Shiretoko/3.5b4pre
> I cannot tell if the problems are with the demo itself, or Jaws support; I
> cannot see the screen at all so am relying soley on Jaws.
> Try this demo; it does mostly work keyboard-only and Jaws mostly behaves
> (although it still does not do the right thing when attempting to move
> across the menubar when all menus are closed. Demo is > at:http://test.cita.illinois.edu/aria/menubar/view_inline.php?title=Menu...
> There were several problems in the script. for example: You were using
> both the focus- and the activedescendant-approach at once. But you
> have to choose one of them. I implemented the activedescendant-
> approach. In the ui.menu, I would recommend to use the "roaming
> tabindex technique".
> There are still 2 problems in your script:
> 1. You are handling mouse- and keyboard interaction the same way, but
> this isnīt allowed. for example focusing a mneuitem with a submenu
> doesnīt open the submenu. Only a useraction (key right or key enter)
> should immediately open it.
> 2. The submenu itself has to be hidden (aria-hidden + display: none).
> But the first submenu is wrapped by position-helper and the .fg-menu-
> container, wich are making the submenu hidden or visible.
> I didnīt wanted to fix these problems, because this would mean a
> rewrite of your script. Instead I made a workaround for the first
> submenu. (This workaround doesnīt work in NVDA, but I wrote a
> testcase, wich works properly)
> I would suggest to start implementing Aria + Keyboard-Interaction to
> the real UI menu to accelerate the progress. I would help Scott in
> this case. I also would suggest, that we add keyboard interaction
> directly to the menu-script, but aria-support in an extension.
> Last has 2 pros:
> 1. By creating an extension, we can test theflexibility of the
> existing Menu-API
> 2. Aria-Suport in case off the menu-script adds a lot of performance-
> load to the script
the other lists arenīt used, because I wanted to focus on a simple
list.
I donīt assign the application-role.
The menu-log isnīt really part of the menu-script. It should only show
how a select-callback works. To get the thing done, I added an alert-
role. You will hear the selected menuitem, but without the text "you
chose".
regards
alex
On 15 Apr., 22:44, Rich Caloggero <rich_calogg...@wgbh.org> wrote:
> OK, on the flat menu, the keyboard controls work (woohoo)!
> How do I display the other menus (I see lots of nested lists in the HTML;
> should this be able to display somehow or is this old or unused code).
> Question: are you assigning a role="application" somewhere? I am not able
> to read the menu log (which should tell me which item is selected in the
> menu).
> The idea behind the two modes (application and document) is this. WIth
> screen readers like Jaws, the reader takes a snapshot of the website when
> the page loads. It converts this to a flat textual representation which can
> then be perused at will using many built-in shortcut keys etc. This facility
> is called the virtual buffer. The problem is that when we want input from
> the user, we need to switch modes and allow all keyboard input to go
> directly to the application (the browser). In normal operation this mode
> switching is supposed to happen automatically when an input control such as
> text input form control or select list gets focus. Since aria lets you build
> arbitrary widgits from other HTML bits, you can force keyboard control to
> the widgit by setting its role to application. However, if there is a part
> of the page which should be able to be perused at will (like the log in this
> case), we need a way of telling the screen reader that this subtree should
> be made available through the screen reader's virtual buffer as is normally
> the case. This is why one should never put a role of application on the
> entire document. I'm also not sure if Jaws is correctly switching from mode
> to mode as focus moves through the document.
> Just put role="document" on the menu log and I'll test it again. I was going
> to do it myself, but didn't want to deal with getting all the external .js
> files on my machine...
> -- Rich
> ----- Original Message -----
> From: "alexander farkas" <i...@corrupt-system.de>
> To: "jQuery Accessibility" <jquery-a11y@googlegroups.com>
> Sent: Wednesday, April 15, 2009 3:33 PM
> Subject: Re: Hierarchical menu ARIA markup -- looking for input
> Hi Rich,
> thx for your feedback. I forgot some debug code in the keydown
> eventhandler, this caused an error in my script. Now, you can test it
> again. Plz, be also patient with this menu-script. There are several
> little problems I didnīt wanted to fix, because it would take too much
> work and time. Like already said, we should put this effort in the
> real script and not in a prototype.
> regards
> alex
> On 15 Apr., 19:25, Rich Caloggero <rich_calogg...@wgbh.org> wrote:
> > The demo you mention below still does not work for me using Jaws10 and
> > FF rv:1.9.1b4pre) Gecko/20090415 Shiretoko/3.5b4pre
> > I cannot tell if the problems are with the demo itself, or Jaws support; I
> > cannot see the screen at all so am relying soley on Jaws.
> > Try this demo; it does mostly work keyboard-only and Jaws mostly behaves
> > (although it still does not do the right thing when attempting to move
> > across the menubar when all menus are closed. Demo is
> > at:http://test.cita.illinois.edu/aria/menubar/view_inline.php?title=Menu...
> > There were several problems in the script. for example: You were using
> > both the focus- and the activedescendant-approach at once. But you
> > have to choose one of them. I implemented the activedescendant-
> > approach. In the ui.menu, I would recommend to use the "roaming
> > tabindex technique".
> > There are still 2 problems in your script:
> > 1. You are handling mouse- and keyboard interaction the same way, but
> > this isnīt allowed. for example focusing a mneuitem with a submenu
> > doesnīt open the submenu. Only a useraction (key right or key enter)
> > should immediately open it.
> > 2. The submenu itself has to be hidden (aria-hidden + display: none).
> > But the first submenu is wrapped by position-helper and the .fg-menu-
> > container, wich are making the submenu hidden or visible.
> > I didnīt wanted to fix these problems, because this would mean a
> > rewrite of your script. Instead I made a workaround for the first
> > submenu. (This workaround doesnīt work in NVDA, but I wrote a
> > testcase, wich works properly)
> > I would suggest to start implementing Aria + Keyboard-Interaction to
> > the real UI menu to accelerate the progress. I would help Scott in
> > this case. I also would suggest, that we add keyboard interaction
> > directly to the menu-script, but aria-support in an extension.
> > Last has 2 pros:
> > 1. By creating an extension, we can test theflexibility of the
> > existing Menu-API
> > 2. Aria-Suport in case off the menu-script adds a lot of performance-
> > load to the script
