Hierarchical menu ARIA markup -- looking for input
949 views
Skip to first unread message
ScottJehl
Mar 31, 2009, 12:55:12 PM3/31/09
to jQuery Accessibility
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.
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Menu ARIA Test</title>
</head>
<body role="application">
<a id="menubutton" href="#menu">ARIA Tree Example</a>
<ul id="menu" role="menu" aria-labelledby="menubutton" aria-
activedescendant="active-menuitem" tabindex="0">
<li role="menuitem"><a href="#">Menu Item</a></li>
<li role="menuitem"><a href="#">Menu Item</a></li>
<li role="menuitem"><a href="#">Menu Item</a></li>
<li role="menuitem"><a href="#">Menu Item</a></li>
<li role="menuitem" aria-haspopup="true">
<a href="#">Menu Item</a>
<ul role="menu" aria-expanded="false">
<li role="menuitem"><a href="#">Menu Item</a></li>
<li role="menuitem"><a href="#">Menu Item</a></li>
<li role="menuitem"><a href="#">Menu Item</a></li>
<li role="menuitem"><a href="#">Menu Item</a></li>
</ul>
</li>
<li role="menuitem" aria-haspopup="true">
<a href="#">Menu Item</a>
<ul role="menu" aria-expanded="true">
<li role="menuitem"><a href="#">Menu Item</a></li>
<li id="active-menuitem" role="menuitem"><a href="#">Menu Item</a></
li>
<li role="menuitem"><a href="#">Menu Item</a></li>
<li role="menuitem"><a href="#">Menu Item</a></li>
</ul>
</li>
</ul>
</body>
</html>
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
http://www.filamentgroup.com/examples/menus/
Thanks so much !
- FG
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.
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Menu ARIA Test</title>
</head>
<body role="application">
<a id="menubutton" href="#menu">ARIA Tree Example</a>
<ul id="menu" role="menu" aria-labelledby="menubutton" aria-
activedescendant="active-menuitem" tabindex="0">
<li role="menuitem"><a href="#">Menu Item</a></li>
<li role="menuitem"><a href="#">Menu Item</a></li>
<li role="menuitem"><a href="#">Menu Item</a></li>
<li role="menuitem"><a href="#">Menu Item</a></li>
<li role="menuitem" aria-haspopup="true">
<a href="#">Menu Item</a>
<ul role="menu" aria-expanded="false">
<li role="menuitem"><a href="#">Menu Item</a></li>
<li role="menuitem"><a href="#">Menu Item</a></li>
<li role="menuitem"><a href="#">Menu Item</a></li>
<li role="menuitem"><a href="#">Menu Item</a></li>
</ul>
</li>
<li role="menuitem" aria-haspopup="true">
<a href="#">Menu Item</a>
<ul role="menu" aria-expanded="true">
<li role="menuitem"><a href="#">Menu Item</a></li>
<li id="active-menuitem" role="menuitem"><a href="#">Menu Item</a></
li>
<li role="menuitem"><a href="#">Menu Item</a></li>
<li role="menuitem"><a href="#">Menu Item</a></li>
</ul>
</li>
</ul>
</body>
</html>
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
http://www.filamentgroup.com/examples/menus/
Thanks so much !
- FG
Rich Caloggero
Mar 31, 2009, 2:40:28 PM3/31/09
to jquer...@googlegroups.com
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
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
alexander farkas
Apr 1, 2009, 4:02:35 PM4/1/09
to jQuery Accessibility
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:
<ul id="nav" role="menubar" class="ui-menubar">
<li role="presentation">
<span aria-haspopup="true" class="hasSubmenu" role="menuitem"
tabindex="0">Menue 2</span>
<ul class="menu" aria-hidden="true" role="menu" style="">
<li role="presentation">
<span role="menuitem" tabindex="0" class="">Menue 2.1</
span>
</li>
<li role="presentation">
<span role="menuitem" tabindex="0" class="">Menue 2.2</
span>
</li>
<li role="presentation">
<span role="menuitem" tabindex="0">Menue 2.3</span>
</li>
</ul>
</li>
</ul>
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
I made some very little changes to the keyboard navigation and this
fact made it totally inaccessible. The HTML-structure looked like
this:
<ul id="nav" role="menubar" class="ui-menubar">
<li role="presentation">
<span aria-haspopup="true" class="hasSubmenu" role="menuitem"
tabindex="0">Menue 2</span>
<ul class="menu" aria-hidden="true" role="menu" style="">
<li role="presentation">
<span role="menuitem" tabindex="0" class="">Menue 2.1</
span>
</li>
<li role="presentation">
<span role="menuitem" tabindex="0" class="">Menue 2.2</
span>
</li>
<li role="presentation">
<span role="menuitem" tabindex="0">Menue 2.3</span>
</li>
</ul>
</li>
</ul>
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
Rich Caloggero
Apr 1, 2009, 4:07:42 PM4/1/09
to jquer...@googlegroups.com
FYI: Jaws10 is the most recent version of Jaws and should be used for
testing.
Jaws 10 has much better ARIA support than Jaws9.
testing.
Jaws 10 has much better ARIA support than Jaws9.
alexander farkas
Apr 1, 2009, 5:57:42 PM4/1/09
to jQuery Accessibility
@Scott
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
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
alexander farkas
Apr 1, 2009, 5:59:44 PM4/1/09
to jQuery Accessibility
You can find the video + a transcript of Developing Accessible
Widgets using ARIA @ http://ericmiraglia.com/blog/?p=132
Widgets using ARIA @ http://ericmiraglia.com/blog/?p=132
ScottJehl
Apr 2, 2009, 10:19:32 AM4/2/09
to jQuery Accessibility
Thanks Rich and Alex,
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?
Thanks!
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?
Thanks!
alexander farkas
Apr 2, 2009, 2:18:49 PM4/2/09
to jQuery Accessibility
Hello,
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
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
ScottJehl
Apr 2, 2009, 5:39:35 PM4/2/09
to jQuery Accessibility
Thanks for your feedback so far. We posted a lab article with the menu
to get for feedback:
http://www.filamentgroup.com/lab/jquery_ipod_style_and_flyout_menus/
I'll read through this thread again and comment soon.
to get for feedback:
http://www.filamentgroup.com/lab/jquery_ipod_style_and_flyout_menus/
I'll read through this thread again and comment soon.
Aaron
Apr 3, 2009, 10:06:37 AM4/3/09
to jQuery Accessibility
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.
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.
alexander farkas
Apr 3, 2009, 1:51:40 PM4/3/09
to jQuery Accessibility
@Aaron
yes, we know, but we will get this work :-)
yes, we know, but we will get this work :-)
Rich Caloggero
Apr 7, 2009, 5:13:18 PM4/7/09
to jquer...@googlegroups.com
> 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?
> 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:
http://wiki.codetalks.org/wiki/index.php/Web_2.0_Accessibility_with_WAI-ARIA_FAQ
http://www.travisroth.com/2008/10/28/aria-tree-markup/
Maggie Wachs
Apr 7, 2009, 5:23:57 PM4/7/09
to jQuery Accessibility
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.
http://www.filamentgroup.com/examples/menus/
Thanks,
Maggie
> http://wiki.codetalks.org/wiki/index.php/Web_2.0_Accessibility_with_W...
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.
http://www.filamentgroup.com/examples/menus/
Thanks,
Maggie
alexander farkas
Apr 15, 2009, 9:52:54 AM4/15/09
to jQuery Accessibility
Hi,
I made some changes to your script and now it works in Jaws9/10. You
can find a demo @ http://www.protofunc.com/scripts/jquery/fg-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
regards
alex
I made some changes to your script and now it works in Jaws9/10. You
can find a demo @ http://www.protofunc.com/scripts/jquery/fg-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
regards
alex
David Bolter
Apr 15, 2009, 10:04:01 AM4/15/09
to jquer...@googlegroups.com
On 4/2/09 10:19 AM, ScottJehl wrote:
> Thanks Rich and Alex,
>
> 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?
>
> Thanks Rich and Alex,
>
> 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".
(see http://www.w3.org/WAI/PF/aria/#application)
Hope this helps,
D
Rich Caloggero
Apr 15, 2009, 1:25:53 PM4/15/09
to jquer...@googlegroups.com
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=Menubar%20Example%201&ginc=includes/menubar1_inline.inc&gcss=css/menubar1_inline.css&gjs=../js/globals.js,../js/widgets_inline.js,js/menubar1_inline.js
If the URL above does not work, try the following and then look for the menu
demo pages:
http://test.cita.illinois.edu/aria/
-- Rich
----- Original Message -----
From: "alexander farkas" <in...@corrupt-system.de>
To: "jQuery Accessibility" <jquer...@googlegroups.com>
Sent: Wednesday, April 15, 2009 9:52 AM
Subject: Re: Hierarchical menu ARIA markup -- looking for input
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=Menubar%20Example%201&ginc=includes/menubar1_inline.inc&gcss=css/menubar1_inline.css&gjs=../js/globals.js,../js/widgets_inline.js,js/menubar1_inline.js
If the URL above does not work, try the following and then look for the menu
demo pages:
http://test.cita.illinois.edu/aria/
-- Rich
----- Original Message -----
From: "alexander farkas" <in...@corrupt-system.de>
To: "jQuery Accessibility" <jquer...@googlegroups.com>
Sent: Wednesday, April 15, 2009 9:52 AM
Subject: Re: Hierarchical menu ARIA markup -- looking for input
alexander farkas
Apr 15, 2009, 3:33:36 PM4/15/09
to jQuery Accessibility
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...
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
>
> If the URL above does not work, try the following and then look for the menu
> demo pages:http://test.cita.illinois.edu/aria/
>
> -- Rich
>
> ----- Original Message -----
> From: "alexander farkas" <i...@corrupt-system.de>
> To: "jQuery Accessibility" <jquer...@googlegroups.com>
> Sent: Wednesday, April 15, 2009 9:52 AM
> Subject: Re: Hierarchical menu ARIA markup -- looking for input
>
> Hi,
>
> I made some changes to your script and now it works in Jaws9/10. You
> can find a demo @http://www.protofunc.com/scripts/jquery/fg-menu/.
> If the URL above does not work, try the following and then look for the menu
> demo pages:http://test.cita.illinois.edu/aria/
>
> -- Rich
>
> ----- Original Message -----
> From: "alexander farkas" <i...@corrupt-system.de>
> To: "jQuery Accessibility" <jquer...@googlegroups.com>
> Sent: Wednesday, April 15, 2009 9:52 AM
> Subject: Re: Hierarchical menu ARIA markup -- looking for input
>
> Hi,
>
> I made some changes to your script and now it works in Jaws9/10. You
Rich Caloggero
Apr 15, 2009, 4:44:50 PM4/15/09
to jquer...@googlegroups.com
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...
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...
alexander farkas
Apr 15, 2009, 5:58:54 PM4/15/09
to jQuery Accessibility
Hi,
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
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
R. Rajesh Jeba Anbiah
May 29, 2009, 3:41:34 AM5/29/09
to jQuery Accessibility
On Mar 31, 9:55 pm, ScottJehl <sc...@scottjehl.com> wrote:
<snip>
> http://www.filamentgroup.com/examples/menus/
It's not accessible without JavaScript. You may alter it with
jQuery.addClass('js') and then in CSS file instead of .hidden{} may
use .js .hidden{}
--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/
<snip>
> http://www.filamentgroup.com/examples/menus/
It's not accessible without JavaScript. You may alter it with
jQuery.addClass('js') and then in CSS file instead of .hidden{} may
use .js .hidden{}
--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/
Reply all
Reply to author
Forward
0 new messages