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...
> 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" <jquery-a11y@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/.
> 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
