Keyboard Navigation & ARIA
kahun...@gmail.com
Practices, and from what I've read elsewhere, the general practice
either via tabindex or aria-activedescendent is to allow tabbing
between DHTML widgets, and within widgets enable other keys such as
ENTER, UP, DOWN, SPACE etc. As I understand it the reasoning behind
this is that we don't want to force AT users to have to tab through
whole hierarcies to get to the next focusable item in document order.
Also, by using a roving tab index, we can assure that an AT user can
go back to the last active item within a widget after tabbing away.
1) Are my statements above accurate?
2) If so, how do blind folks know, for example in a menu widget, that
RIGHT will expand a menu item? Or DOWN will go to the next menu item
on a vertical menu as opposed to a horizontal menu? My workmate
suggests that I should ignore this advice and allow Tabbing inside a
widget as well. If it is some ARIA attribute that informs a
screenreader user what to expect when pressing a key, the fact is that
ARIA is not prime-time yet. IE, for example, doesn't support much of
ARIA with many screen readers.
3) Is ARIA mature enough and implemented well enough in various
browsers/ATs that I can use activedescendent instead of roving
tabindex? I assume not...that I must use the roving tabindex
technique. Thanks for guidance in advance...
David Bolter
The keyboard operation of a focused widget generally mirrors what
happens on the desktop. When you use role="menuitem" haspopup="true"
the screen reader user, like sighted keyboard users, is going to
expect right arrow to open the submenu. The roving tabindex pattern
just works well generally, so I highly recommend it; and for the
reasons you mention. If you are concerned about people using less
accessible browsers you could pursue a progressive enhancement
approach combined with WAI-ARIA.
cheers,
David
On Jun 2, 9:33 am, "kahunaco...@gmail.com" <kahunaco...@gmail.com>
wrote:
Scott González
2) If so, how do blind folks know, for example in a menu widget, that
RIGHT will expand a menu item? Or DOWN will go to the next menu item
on a vertical menu as opposed to a horizontal menu? My workmate
suggests that I should ignore this advice and allow Tabbing inside a
widget as well. If it is some ARIA attribute that informs a
screenreader user what to expect when pressing a key, the fact is that
ARIA is not prime-time yet. IE, for example, doesn't support much of
ARIA with many screen readers.
I believe users will know what action each keystroke will perform because they are used to dealing with these types of widgets every day on the desktop. As for horizontal vs. vertical menus, perhaps that's the difference between menu and menubar? Hopefully someone with more knowledge can chime in.
3) Is ARIA mature enough and implemented well enough in various
browsers/ATs that I can use activedescendent instead of roving
tabindex? I assume not...that I must use the roving tabindex
technique. Thanks for guidance in advance...
From what I've seen recommended, my guess is that you should generally just use roving tabindexes.
Rich Scwerdtfeger
brings up a popup as this is how it has worked on Windows for over a
decade.
Aria- activedescendant works first in IE with IE 8. It is in FF. I
have not tried the Safari 4 beta or Opera.
Rich Schwerdtfeger
Sent from my IPhone handheld
On Jun 2, 2009, at 8:33 AM, "kahun...@gmail.com" <kahun...@gmail.com
Scott González
Blind users know right arrow key on aria-haspopup, in a menu item,
brings up a popup as this is how it has worked on Windows for over a
decade.
Going back to the original question about horizontal vs. vertical menus, is it always the case that the right arrow will open the popup? I know that if I put focus on a horizontal menu in Windows and then use the right/left arrows it will move across the menu bar, not open the popups. I think it makes sense for right/left to control popups in the context of visually impaired users who may not be aware of the orientation, but it seems counter-intuitive for sighted users who are navigating via the keyboard. Has this concern been addressed somehow?
Rich Scwerdtfeger
Hi Scott,
mj
poster on this thread) coworkers. I need some help understanding this
focus control/TAB key issue. This note is to the experts on this
thread; thanks for your time.
I was introduced to this topic briefly today, and the question of how
tabs should work has been a bit controversial in our group. I'm pretty
uninformed on this stuff, so please bear with me.
Apparently designers of keyboard focus control on desktops chose to
use tab to move among controls, and arrow keys to move within them.
The designers of Web browsers made the same choice, but the controls
where arrow keys meant something (text input, select item, etc.) were
fewer. Links on web pages are treated as controls.
Desktops have menus, and nested menus, so "internal" focus control
(arrow keys) means something there. But web pages don't have controls
for menus per se--a nested menu is probably a nested lists of links
(as a CSS selector: ul li a). In a web page, a menu isn't a menu, it's
a nested list of links (when it's not some botched mess of divs and
tables and stuff.)
Web browser users, sighted or otherwise, are accustomed to TAB meaning
"go to the next link or control". In the case of a menu, that means
the next link of the menu. But your advice is to use arrow keys for
that, instead of TAB, because that's what desktops do. Even though TAB
has meant "go to the next link" for a decade and a half in web
browsers. That "menu" is only a menu because the HTML treats it as
such. But it's still just links on a web page.
I'm using menu as an example here, but the same principle applies to
other components that are implemented as a layer of behavior on top of
markup. The advice that DHTML components should hijack not just visual
behavior, but also tab order, seems invasive to me. The consensus
seems to be to use JavaScript to redesign, by fiat, how the browser
interprets the TAB key, to make it act like a desktop. That new
behavior violates the expectations of users who are accustomed to how
browsers handle tabs. And that includes screen reader users who are
accustomed to web pages working like web pages, not like desktops. As,
in fact, most web pages do.
I imagine that "TAB+ARROW" focus control *is* easier for screen reader
users. Assuming they can figure out that *this* web page works like a
desktop, instead of working like a web page. But that's quite an
assumption. And it also may confuse or annoy other keyboard
navigators, including people with limited motion control, and geeks
who despise the mouse because it loses keyboard home position. How are
any of these users supposed to know to start using arrow keys for
"internal" focus control, when that simply isn't how web pages have
ever worked?
I'll say up front that I lean heavily towards your advice, despite
these objections, because I would rather slightly inconvenience a few
people who use the keyboard by choice, than greatly inconvenience all
those who have no choice. And because it seems to be the accessibility
community consensus, up to and including building it into tools like
jQuery.ui.
But I would sure like to hear a convincing explanation of why we
should redesign how browsers work in JavaScript, when doing so will
violate expectations that have built over years. I'm clearly missing
something--please enlighten me.
Thanks
--Mark
James Teh
You raise some very interesting and valid points, which I'll try to
address from my point of view below:
On 8/07/2009 8:42 AM, mj wrote:
> The designers of Web browsers made the same choice, but the controls
> where arrow keys meant something (text input, select item, etc.) were
> fewer. Links on web pages are treated as controls.
True. However, when you change the visual appearance of a link, you are
changing the user interface. More below.
> Desktops have menus, and nested menus, so "internal" focus control
> (arrow keys) means something there. But web pages don't have controls
> for menus per se--a nested menu is probably a nested lists of links
> (as a CSS selector: ul li a). In a web page, a menu isn't a menu, it's
> a nested list of links
This is true, and when it is simply a nested list of links with no
JavaScript, it's probably best to leave it as is. However, when you use
JavaScript to make this nested list of links behave more like a
desktop-style drop down menu with sub-menus, you have made a significant
alteration to the user interface. You're now clearing trying to
replicate a desktop-style menu structure. In this case, the tab key no
longer makes sense, because its next target depends highly on which
menus are visible at the time.
> Web browser users, sighted or otherwise, are accustomed to TAB meaning
> "go to the next link or control". In the case of a menu, that means
> the next link of the menu. But your advice is to use arrow keys for
> that, instead of TAB, because that's what desktops do. Even though TAB
> has meant "go to the next link" for a decade and a half in web
> browsers.
In recent years, we're seeing a trend towards rich web applications
which use JavaScript and CSS to create new widgets. I'm totally blind
myself, but as I understand it, these widgets are starting to look more
and more like widgets in desktop applications. Indeed, web applications
themselves are starting to look like (and in some cases, even replace)
desktop applications. I think that keyboard access in these web
applications needs to change accordingly.
>The advice that DHTML components should hijack not just visual
> behavior, but also tab order, seems invasive to me.
On the contrary, I'd argue that a change in visual behaviour means a
change to the core user interface, and keyboard access should follow.
That is, if you're going to make a web app appear more like a desktop
app, then the keyboard access should also behave more like a desktop app.
> The consensus
> seems to be to use JavaScript to redesign, by fiat, how the browser
> interprets the TAB key, to make it act like a desktop. That new
> behavior violates the expectations of users who are accustomed to how
> browsers handle tabs.
It could be argued that changing the visual appearance similarly
violates user expectations of browser appearance, but this has become an
accepted trend, at least for sighted users...
> And that includes screen reader users who are
> accustomed to web pages working like web pages, not like desktops.
> I imagine that "TAB+ARROW" focus control *is* easier for screen reader
> users. Assuming they can figure out that *this* web page works like a
> desktop, instead of working like a web page.
Ah! And here's where ARIA enters the picture. You've basically
identified one of the core challenges that ARIA was created to solve:
now that we have web applications that are acting more like desktop
applications, how do we make these accessible?
In over-simplified terms, ARIA allows web authors, using simple
markup/DOM attributes, to specify semantic information about a control
which can be communicated to assistive technologies such as screen
readers. So you have a widget which appears and behaves like a menu? Set
role="menu" on it, and set role="menuitem" on its items. If I'm using a
supporting screen reader and browser, when that menu gets focus, I'll
now hear about it as if it was a menu in a desktop application, not a
link in a nested list.
> And it also may confuse or annoy other keyboard
> navigators, including people with limited motion control, and geeks
> who despise the mouse because it loses keyboard home position. How are
> any of these users supposed to know to start using arrow keys for
> "internal" focus control, when that simply isn't how web pages have
> ever worked?
As above, I'd argue that once you change the visual design, users can
expect a similar change in keyboard access. Sure, this isn't true right
now for many web applications, but I think it's a fair expectation.
Hope this helps, and apologies for any inaccuracy or misleading
over-simplification. :)
Jamie
--
James Teh
Email/MSN Messenger/Jabber: ja...@jantrid.net
Web site: http://www.jantrid.net/
Scott González
I think the most simplistic answer to "why we should redesign how browsers work in JavaScript, when doing so will
violate expectations that have built over years" is that ARIA takes users out of the web context. By applying ARIA roles to various elements, AT devices will recognize them as the element specified in the role as opposed to the actual DOM element that was used to represent the widget. So in your example, the nested list of links will actually be reported as a menu and not just a list of links. This makes it pretty easy for AT users to know what functionality to expect.
However, we do face a challenge with the average user who isn't using any AT device. As you've pointed out, these users are accustomed to the browser's default behavior and will be surprised when they encounter the modified behavior. However, the web is evolving and user expectations are changing. You used to be able to say that users expect an anchor tag to open a new page. That all changed when ajax became popular and you could pretty easily say that was straying from the user's expectation. However, it was a logical step in moving from web pages to web apps. The same can be said about most of ARIA. Web apps are creating widgets that we can't build semantically using HTML, and in many cases the apps are just mimicking desktop controls. Following this logic, ARIA is the logical next step for web apps. We now have a way to add semantics and meaning to the various controls we've been building on the web. Modifying the user interaction to match the interaction we're already used to from desktop applications just makes sense.
My biggest concern is that not all sites will implement ARIA, or some might but won't implement the corresponding functionality. This will result in some sites having tab-focus and some sites having arrow-focus for the same types of controls. This could potentially put us in a worse situation than we're in now where all web apps work one way and all desktops apps work another way, but you always know what to expect.
Out of curiosity, why don't browsers automatically implement this functionality based on the roles assigned to elements?
David Bolter
are in a period of transition. I've seen tablists that look like I can
tab among them, but of course I need to arrow. I think this can be
alleviated with better styling for sighted keyboard users, often an
afterthought.
On Jul 7, 8:26 pm, Scott González <scott.gonza...@gmail.com> wrote:
> Out of curiosity, why don't browsers automatically implement this
> functionality based on the roles assigned to elements?
Fair question, since browsers prescribe the keyboard interaction for
things like input elements, however WAI-ARIA is purely descriptive in
this respect. Just like a role of menuitem on a listitem doesn't cause
the browser to control the rendering, neither does it control the
keyboard interaction. I think this consistency is "a good thing". Let
me know if you want the essay on that.
I do think ARIA 2.0, if we need to seriously consider a way for
authors to describe the keyboard interaction that has been
implemented.
cheers,
David
David Bolter
Victor Tsaran
You bring some very valid points. Developers in many web companies
struggle with similar questions. I will therefore throw in some comments
rather than trying to directly answer your questions:
1. It is true that a lot of keyboard users are used to relying on the
TAB key to move them from link to link. However, I doubt that in a real
world anyone would like to tab through the whole menu -- it is laborious
and often impractical.
2. We are entering an era in the field of web accessibility where we
have a responsibility not only to develop new widgets and make them
accessible but also educate users on the new interaction model we are
putting forth. Yes, it's going to be painful for everyone (developers
and users), but I don't see any other way out at the moment.
3. Keyboard access itself is becoming an issue, just have a look at the
DHTML Style Guide, http://dev.aol.com/dhtml_style_guide, and you will
see what I mean. The new web introduced a bunch of new widgets that did
not exist on the desktop.
Take it for what it's worth! :)
Thanks Mark for asking. We need more curious people like you!
Vic
---
I tweet about music and accessibility at http://www.twitter.com/vick08
or check my site at http://www.victortsaran.com
---
Schnabel, Stefan
control on request.
I requested this for ARIA 1.0 but without success.
The consensus was: read the user manual.
Interesting thing is that even MSAA provides an Interface for Help texts
but unfortunately it was not used
by any ARIA 1.0 property.
- Stefan
nickfitz
>
> But I would sure like to hear a convincing explanation of why we
> should redesign how browsers work in JavaScript, when doing so will
> violate expectations that have built over years. I'm clearly missing
> something--please enlighten me.
>
watch/4073211/10996186> by Todd Kloots from Yahoo! which (amongst
other examples) demonstrates the use of ARIA to improve a screenreader
user's perception of a menu widget. Without ARIA the rendition of the
menu as a list of links is actually quite confusing, failing to
properly convey any idea of what those links may be for. Using ARIA,
the screeenreader is able to present it as a menu, in the same manner
as it does for desktop applications.
Remember, screenreaders aren't just used with web browsers, but to
interact with all applications, as well as operating system components
(such as the Windows Start menu, or Control Panel dialog boxes). Users
of assistive technologies are used to these modes of interaction.
Web developers use JavaScript and CSS to turn a bit of HTML into
something that looks like the widgets found in other parts of the OS:
that is, we take the visual metaphors and interactions of the desktop
and implement them in the browser. Fully able users are familiar with
these metaphors, and thus are comfortable using them.
In the same way, ARIA allows that widget to be presented to users of
Assistive Technologies using those metaphors and representations (such
as spoken descriptions of menus and menu items) that are found in
their other interactions with such widgets in their other usage of the
computer. Thus the same goal is achieved of producing the experience
of an interactive widget of a kind with which the user is familiar.
Far from being confused by this change in behaviour, users of
screenreaders are (just like sighted users) more likely to immediately
recognise and be comfortable interacting with such a component, for
rather than being an unwieldy list whose purpose must be deciphered,
it is presented as a functional whole whose purpose and operation they
already understand.
Regards,
Nick.
--
Nick Fitzsimons
http://www.nickfitz.co.uk/
John Foliot
>
> My biggest concern is that not all sites will implement ARIA,
> or some might but won't implement the corresponding functionality.
> This will result in some sites having tab-focus and some sites
> having arrow-focus for the same types of controls. This could
> potentially put us in a worse situation than we're in now where
> all web apps work one way and all desktops apps work another way,
> but you always know what to expect.
This is the single greatest reason I give for using some of the better JS
libraries out there (Dojo, YUI, jquery) as much of the ARIA goodness is
being baked into the codebases there. Not all libraries are fully there,
but they continue to evolve and grow: the basics are already covered
across the libraries (AFAIK) and the fringier functions are coming online
at various paces. As I am writing this off line I cannot provide a
resource to you, but search for Todd Kloots video (from Yahoo!) about
accessible web 2.0 widgets and architecture - I believe it can be found at
Yahoo!'s developer site - for some idea of what is happening. Becky
Gibson of IBM is also doing some great work with Dojo... (for 2
implementations I am aware of).
> Out of curiosity, why don't browsers automatically implement this
> functionality based on the roles assigned to elements?
Hopefully once ARIA becomes an official part of HTML5 (likely, but not a
given), we may start to see this happen. Author demand would help
strengthen the needs requirement.
JF
Aaron Leventhal
On Jul 8, 2009, at 6:52 PM, John Foliot wrote:
>> Out of curiosity, why don't browsers automatically implement this
>> functionality based on the roles assigned to elements?
>
> Hopefully once ARIA becomes an official part of HTML5 (likely, but
> not a
> given), we may start to see this happen. Author demand would help
> strengthen the needs requirement.
Actually, I disagree. That's what using the HTML 5 widgets will do.
If you use the out of the box widgets you'll get key nav, mouse nav,
look and feel, semantics, etc.
ARIA doesn't try to be HTML. If the role and ARIA attributes started
driving behavior instead of acting just as an informer to ATs, then it
would break everything that uses ARIA right now. For a given browser
it would be unpredictable. The strength of ARIA is that it makes it
possible to do your own thing and make it accessible. You don't have
to retest your site for mainstream usage if you add ARIA, because it
doesn't affect that. Mainstream usage will remain stable with or
without ARIA markup, and whether or not a given browser supports ARIA.
It's invisible to everything but ATs. That's a good thing.
Of course not everyone will add ARIA, but it is at least possible.
That means people can still innovate and be accessible while we wait
for the next great thing.
- Aaron
Scott González
Octavian Rasnita
> Of course not everyone will add ARIA, but it is at least possible.
> That means people can still innovate and be accessible while we wait
> for the next great thing.
The next great thing should be to be able to use standard widgets that
provide accessibility like ARIA does, without needing to know anything about
accessibility or how it is helpful for the disabled.
Most web developers won't be interested in offering accessibility but the
pages they make should be accessible.
Otherwise... a few big companies and the disabled web developers themselves
will probably make accessible sites, but the others won't do it.
Octavian
Aaron
should have to spend so much effort with this stuff, except for the
fact that HTML was never designed to do what it does now in terms of
rich page controls.
Aaron
accessibility community have a seat at the table?
Aaron Leventhal
they start out with ARIA. We tried to answer people's honest concerns
in this FAQ: http://wiki.codetalks.org/wiki/index.php/Web_2.0_Accessibility_with_WAI-ARIA_FAQ
Yes there are accessibility people involved in HTML 5 development.
They could always use more people who understand the technical issues.
There seem to be some annoying politics, but overall I think/hope/
believe things are headed in the right direction. That's more of a
long term thing, and as far as I know HTML is not planning to address
everything ARIA addresses (such as live regions).
- Aaron
Aaron
keyboard navigation with javascript widgets that I am developing.
One thing that I don't get is that screenreaders seem to take over the
keyboard for their own functions. So, if I have a menu widget that
allows arrow keys for navigating the menu, how do I use those keys to
navigate when using the screenreader? For example, if I click the
right arrow, the screenreader (NVDA or Jaws) will start reading the
next letter of the word I am currently on.
This results in widgets that are keyboard accessible if I am not using
a screenreader, but not when I am. Can someone explain? Thanks.
Octavian Râsnita
So they are simple links, but they are recognized as menus and you can
activate them by turning the forms mode on (by pressing enter when using
Jaws, if Jaws is not set to automaticly switch to forms mode on).
After you switch the forms mode on, the menu is seen, or rather it should be
seen exactly like a desktop app menu, so if you'll press the right arrow
key, it won't read the next letter, but it would select the next menu.
It would be like in the case of a edit field form element so if the forms
mode is on and the focus is in an edit field, if you'll press the down arrow
or the up arrow, this wouldn't move the cursor to the next or previous page
element, but just stay in the form field.
Octavian
James Teh
> One thing that I don't get is that screenreaders seem to take over the
> keyboard for their own functions.
> So, if I have a menu widget that
> allows arrow keys for navigating the menu, how do I use those keys to
> navigate when using the screenreader?
Aside from manually switching to focus/forms mode, recent versions of
NVDA and JAWS should automatically switch modes (so that you can use
these keys for their normal purpose) when an interactive widget (such as
a form field or menu) gains focus. In the case of a menu, this obviously
requires correct ARIA markup. If this does not happen, it's probably a bug.
Schnabel, Stefan
before.
In consequence, later in time collisions with JS KB Handlers were
unavoidable.
There are a couple of AT issues known related to that.
By principle, AT should check (yes it should, not it could) if JS key
handlers are attached to a node
and if so, react appropriately on that. I think this happens, but
non-transparent for the rest of the world.
As a last resort, there are always means to redefine interfering AT keys
as part of the AT user's configuration settings.
- Stefan
-----Original Message-----
From: free...@googlegroups.com [mailto:free...@googlegroups.com] On
Behalf Of Aaron
Sent: Montag, 13. Juli 2009 20:57
To: Free ARIA Community
Benjamin Hawkes-Lewis
> ARIA doesn't try to be HTML. If the role and ARIA attributes started
> driving behavior instead of acting just as an informer to ATs, then it
> would break everything that uses ARIA right now. For a given browser
> it would be unpredictable. The strength of ARIA is that it makes it
> possible to do your own thing and make it accessible.
Regrettably, I think the convention that UAs shouldn't use ARIA works to
prevent that.
ARIA certainly makes it possible to make arbitrary markup accessible to
users of AT (or automation frameworks) that interact and represent via
the system accessibility API.
But in so far as it restricts user agents to simply exposing ARIA
information to assistive technology, it risking leaving out users who
either aren't using AT, aren't using AT that queries the system API, or
are using complex combinations of AT and user agent UIs.
ARIA can certainly help towards partially repairing things when authors
have made the mistake of treating HTML as HyperText Made Up Language
(like with the Dojo project that rebuilt checkbox controls with "div"
elements). Sadly, I think the target market for reinventing controls in
this way is already moving on to direct draw technologies not covered by
ARIA, like "canvas".
ARIA can also improve the accessibility for some system-API-based AT
users of interfaces that are already pretty accessible to other user
groups (I'm thinking especially of live regions here, even though
they've lost the handy ability to prioritize messages).
But I don't this adds up to a licence to "do your own thing".
There's a danger of "accessibility" looking like shorthand for "now
works for blind users of new versions of popular screenreaders" here.
Just to take one example - consider Susan. She has early onset
Parkinson's and struggles to use a mouse but can peck away slowly at a
keyboard. She accesses an SVG-based interface that has landmark and
heading roles. Why shouldn't a keyboard-friendly user agent like Opera,
which already binds keyboard shortcuts to things like headings, links,
and form controls, bind a keyboard shortcut to the "heading", "main" and
"search" landmark roles so Susan can skip between headings, to the main
content, or to site search. How does it make sense for some logical
headings to be handled by Opera's shortcuts and other logical headings
by some hypothetical AT add-on? Or again, if there's a drag and drop
interface, why shouldn't Susan be able to use Opera-provided shortcuts
to manipulate it?
One quickly arrives at the conclusion that if ARIA can't help in these
use-cases, then the recommendation should be to mix XHTML and SVG inline
in order to use XHTML's heading elements, and forget about
role="heading" entirely.
Incidentally, it's not very clear to me whether Opera would be clearly
breaching an actual conformance requirement, as opposed to convention,
if it exposed such shortcuts or not. "WAI-ARIA processing by the user
agent MUST NOT interfere with the normal operation of the built-in
features of the host language", says the spec, but would exposing
keyboard navigation to a "text" element with a "heading" role (say)
constitute such interference?
--
Benjamin Hawkes-Lewis
RichS
On Jun 2, 8:33 am, "kahunaco...@gmail.com" <kahunaco...@gmail.com>
> Hi, from reading some of the W3C docs on ARIA, including Best
> Practices, and from what I've read elsewhere, the general practice
> either via tabindex or aria-activedescendent is to allow tabbing
> between DHTML widgets, and within widgets enable other keys such as
> ENTER, UP, DOWN, SPACE etc. As I understand it the reasoning behind
> this is that we don't want to force AT users to have to tab through
> whole hierarcies to get to the next focusable item in document order.
> Also, by using a roving tab index, we can assure that an AT user can
> go back to the last active item within a widget after tabbing away.
>
> 1) Are my statements above accurate?
>
> 2) If so, how do blind folks know, for example in a menu widget, that
> RIGHT will expand a menu item? Or DOWN will go to the next menu item
> on a vertical menu as opposed to a horizontal menu? My workmate
> suggests that I should ignore this advice and allow Tabbing inside a
> widget as well. If it is some ARIA attribute that informs a
> screenreader user what to expect when pressing a key, the fact is that
> ARIA is not prime-time yet. IE, for example, doesn't support much of
> ARIA with many screen readers.
>
workmate goes
to a menu on the desktop does he/she tab their way through it? If you
are a screen reader user you will
hear things like menuitem when landing on those particular elements.
It will sound and behave as expected
on the desktop. Screen reader help systems are geared to announce the
keyboard navigation information if queried.
You should not allow for tabbing within the widget.
Just because IE support for ARIA is incomplete does not mean that it
is not "prime time." Over 50 IBM products
are now using ARIA and the number is growing. At the moment we are
working with Firefox but at the same time
members of the W3C WAI PF working group are working with the browser
manufacturers to support ARIA. You may have
noticed that Apple announced partial support for ARIA in the IPhone.
Granted, Firefox support is ahead of the browsers but
a measure of what is Prime Time requires more than assessment of
whether a preferred browser has full support.
Yahoo, Microsoft, Oracle, SAP, Google, Apple, Freedom Scientific,
NVDA, Adobe, and a long list of other major
software companies are adding support in their products. Given that
level of investment I would argue that ARIA
has gone beyond hitting "prime time."
I would add that Microsoft is heavily involved with ARIA in the W3C
standards effort. So, although IE is behind it is
safe to say this is a minor bump in the road.
> 3) Is ARIA mature enough and implemented well enough in various
> browsers/ATs that I can use activedescendent instead of roving
> tabindex? I assume not...that I must use the roving tabindex
> technique. Thanks for guidance in advance...
checked Webkit and Opera. The one thing that would
make aria-activedescenant more powerful would be a pseudoclass to
render the focused active descendant.
Benjamin Hawkes-Lewis
> ARIA doesn't try to be HTML. If the role and ARIA attributes started
> driving behavior instead of acting just as an informer to ATs, then it
> would break everything that uses ARIA right now. For a given browser
> it would be unpredictable. The strength of ARIA is that it makes it
> possible to do your own thing and make it accessible.
Not really.
ARIA makes it possible to make arbitrary markup accessible to users of
AT (or automation frameworks) that interact and represent via the system
accessibility API.
A website that uses ARIA can therefore be more accessible than a website
that does not.
But we shouldn't confuse that with making it accessible
You don't have
> to retest your site for mainstream usage if you add ARIA, because it
> doesn't affect that. Mainstream usage will remain stable with or
> without ARIA markup, and whether or not a given browser supports ARIA.
> It's invisible to everything but ATs.
This doesn't match the goals of the spec:
* defining what information may be controlled by the author;
* supporting device independence for new devices such as telephones,
PDAs, and televisions;
* improving the accessibility of dynamic content generated by scripts;
* providing for interoperability with assistive technology.
Benjamin Hawkes-Lewis
On 8/7/09 20:40, Aaron Leventhal wrote:
> ARIA doesn't try to be HTML. If the role and ARIA attributes started
> driving behavior instead of acting just as an informer to ATs, then it
> would break everything that uses ARIA right now. For a given browser
> it would be unpredictable. The strength of ARIA is that it makes it
> possible to do your own thing and make it accessible.
Regrettably, I think the convention that UAs shouldn't use ARIA works to
prevent that.
ARIA certainly makes it possible to make arbitrary markup accessible to
users of AT (or automation frameworks) that interact and represent via
the system accessibility API.
But in so far as it restricts user agents to simply exposing ARIA
Aaron
quite well with ARIA, JAWS10 and NVDA.
On Jul 14, 12:46 pm, Benjamin Hawkes-Lewis
Schnabel, Stefan
Drop us a line to the URL.
Regards
-----Original Message-----
From: free...@googlegroups.com [mailto:free...@googlegroups.com] On Behalf Of Aaron
Sent: Mittwoch, 15. Juli 2009 16:29
To: Free ARIA Community
Subject: [LIKELY JUNK][free-aria] Re: Keyboard Navigation & ARIA
Aaron
screereaders at this point.
Some background:
We are working on an unobtrusive, declarative widget framework, based
on jQuery UI. We modify some of UI's widgets, and have developed our
own based on their framework. We decided against YUI because it is
coming out with a new version soon and jQuery is simpler to work with.
The menu widget we are developing is similar to YUI's menubar, except
it uses simple <ul> semantics in contrast to YUI's embedded divs
within <ul>s. Here it is (it is not really styled much at this point).
Here you go:
http://mini.ncbi.nih.gov/4e1
Comments are welcome.
On Jul 16, 2:38 am, "Schnabel, Stefan" <stefan.schna...@sap.com>
wrote:
Aaron
- It uses event delegation. All events are bound to the root ul node
- It does not traverse the entire menu on init to add classes, aria
roles and states. It only adds classes/aria markup/elements when a
submenu opens, and only the first time it is opened.
Scott González
The menu widget we are developing is similar to YUI's menubar, except
it uses simple <ul> semantics in contrast to YUI's embedded divs
within <ul>s. Here it is (it is not really styled much at this point).
Here you go:
http://mini.ncbi.nih.gov/4e1
I get a 403 forbidden when I follow that link.
Octavian Rasnita
This page gives:
403 Forbidden
Forbidden
You don't have permission to access /4e1 on this server.
Additionally, a 403 Forbidden error was encountered while trying to use an
ErrorDocument to handle the request.
Thanks.
--
----- Original Message -----
From: "Aaron" <kahun...@gmail.com>
To: "Free ARIA Community" <free...@googlegroups.com>
Aaron
try again.
Aaron
Scott González
Octavian Râsnita
Aaron
the page that the apaches servers were blocking.
http://mini.ncbi.nih.gov/4e1
On Jul 17, 11:04 am, Octavian Râsnita <orasn...@gmail.com> wrote:
> Yes I can, but I still can't accesshttp://mini.ncbi.nih.gov/4e1
Aaron
some display bugs in Safari and there might be some console.info s
which will make IE choke.
On Jul 17, 5:01 pm, Aaron <kahunaco...@gmail.com> wrote:
> Ok. Can you please try again. Apparently I had some internal URLs in
Octavian Râsnita
Aaron
permissions are right. I will contact the unix folks that maintain the
production apache servers and see what gives. Thanks for your
patience.
On Jul 17, 5:27 pm, Octavian Râsnita <orasn...@gmail.com> wrote:
> It still gives the same error.
>
> Octavian
>
> ----- Original Message -----
> From: "Aaron" <kahunaco...@gmail.com>
> To: "Free ARIA Community" <free...@googlegroups.com>
> Sent: Saturday, July 18, 2009 12:01 AM
> Subject: [free-aria] Re: Keyboard Navigation & ARIA
>
> Ok. Can you please try again. Apparently I had some internal URLs in
Aaron
firewall. This should work:
http://www.ncbi.nlm.nih.gov/staff/mjohnson/cohenaa/jig/doc/examples/ncbimenu.html
Please remember it's still in progress. -Aaron
Aaron
examples. But take a look at their tabs aria plugin:
http://developer.yahoo.com/yui/examples/tabview/tabview-ariaplugin_clean.html
When I tab to the control, the only way I can arrow to the next tab is
by reading through the tab title. Shouldn't the user be able to tab to
the widget, hit ENTER and navigate the tabs with the arrow keys?
Also, I cannot get NVDA to read "tab 1 of n tabs", which is what I
would expect. What am I missing?
On Jul 19, 8:17 pm, Aaron <kahunaco...@gmail.com> wrote:
> My bad. I was using an alias that can't be used for folks outside our
Todd Kloots
If you cannot use the arrow keys that usually means that the virtual
buffer is on. Most of the time you need to toggle the virtual buffer
off in order for any keyboard functionality you've added via
JavaScript to work. I say most of the time because some screen
readers like JAWS have the ability to automatically toggle the virtual
buffer off when the user tabs to an ARIA-enabled widget. If you
aren't familiar with the concept of the virtual buffer, let me know
and I will explain further.
I hope that helps.
- Todd
Aaron
(http://developer.yahoo.com/yui/examples/menu/menuwaiaria_source.html)
it does not work as expected with the virtual buffer off.If it is off,
the keyboard does not work as expected, nor do menubar items hilite as
expected. When I turn on the vb, by pressing INSERT+SPACE NVDA
announces submenus, "item 1 of 4" etc.
On Jul 22, 2:43 pm, Todd Kloots <klo...@yahoo-inc.com> wrote:
> Hi Aaron -
>
> If you cannot use the arrow keys that usually means that the virtual
> buffer is on. Most of the time you need to toggle the virtual buffer
> off in order for any keyboard functionality you've added via
> JavaScript to work. I say most of the time because some screen
> readers like JAWS have the ability to automatically toggle the virtual
> buffer off when the user tabs to an ARIA-enabled widget. If you
> aren't familiar with the concept of the virtual buffer, let me know
> and I will explain further.
>
> I hope that helps.
>
> - Todd
>
> On Jul 22, 2009, at 11:25 AM, Aaron wrote:
>
>
>
> > I try to base what I am doing on some of YUI's excellent ARIA widget
> > examples. But take a look at their tabs aria plugin:
>
> read more »
Todd Kloots
No, I didn't mean the opposite. When I load the page NVDA starts out
in Browse Mode (meaning the virtual buffer is on). Then I use the tab
key to navigate from the browser's address bar to the YUI Menubar.
When the YUI Menubar initially receives focus NVDA automatically
switches to Focus Mode (meaning the virtual buffer is now off). When
in Focus Mode, I can use the arrow keys to navigate the MenuBar and
its submenus just fine--all of the items in the menubar and submenu
highlight just fine. For reference I am using:
NVDA 0.6p3.2
Firefox 3.5
Windows XP
Hope that helps.
- Todd
Aaron
1) Load the page (http://developer.yahoo.com/yui/examples/menu/
menuwaiaria_source.html)
2) From the address navigate by tabbing to the google search bar > the
Firefox tab > the iframe > first item in menubar
3) Hit ENTER.
4) The file menu hilites
5) When I click the down arrow items under file just gain focus
6) I hear "Menu clickable new file" I cannot use the right arrow to
open submenu
If I click INSERT + SPACE I hear "Virtual buffer passthrough on"
Then I can navigate menu as expected and I hear the ARIA enhancements.
Any idea what I am doing wrong?
Windows XP
FF 3.5.1
NVDA 0.6p2
>
> read more »
James Teh
> NVDA 0.6p2
You need to be running a more recent version of NVDA for this stuff to
work correctly. At the very least, you should be running the latest
official release (NVDA 0.6p3.2). At best, because of the ever-evolving
nature of NVDA's ARIA support, you should be running a development
(bleeding edge) snapshot:
http://www.nvda-project.org/snapshots/
I suspect this will solve all of your problems.
Also note that in older versions such as 0.6p2, browse mode/focus mode
was called "virtual buffer pass through" on/off. When NVDA says "virtual
buffer pass through on", this is not turning *on* the virtual buffer;
it's turning on *pass through* for the buffer, meaning that everything
passes right through it instead of being captured. This created quite a
bit of confusion and was rather technical terminology, so we renamed it
to browse/focus mode.
Jamie
--
James Teh
Email/MSN Messenger/Jabber: ja...@jantrid.net
Web site: http://www.jantrid.net/
Victor Tsaran
virtual buffer when it detects form control or an ARIA widget.
---
I tweet about music and accessibility at http://www.twitter.com/vick08
or check my site at http://www.victortsaran.com
---
Victor Tsaran
have you seen screencasts? We have thoroughly tested the functionality
and have seen the widgets work! Are you using the latest?
V
Aaron
>have you seen screencasts? We have thoroughly tested the functionality
and have seen the widgets work! Are you using the latest?
seen all of them, including Todd's presentation. It is great stuff.
The only reason we are rolling our own instead of using YUI's is
because our organization decided to go with jQuery as a library
instead of YUI. We did not want to be using two different JS libs.
>
> read more »
Aaron
now:
1) Load page
2) Tab to Menubar
3) When I land on menubar "File Submenu 1 of 2, focus mode."
4) When I click ENTER to open the File menu, it opens and then using
the arrows just focuses each item but does not hilite nor reads n of n
5) To get the menu to read like a menu, I then have to click Enter
again to get to focus mode. It seems like it goes out of focus mode
when I try to enter the file menu.
Is this expected, or a bug in NVDA, or am I doing something wrong?
FF 3.5.1
Windows XP
NVDA 0.6p32
>
> read more »
Todd Kloots
Just tried using your repro steps and experienced the same behavior
that you are. Looks like pressing enter/clicking on an item in the
menubar does in fact do something to toggle NVDA's virtual buffer back
on. This may be a bug in NVDA, but I am not sure. I'll defer to the
NVDA guys for more info. That said, pressing enter while focused on
an item in the menubar isn't what I would consider the defacto user
interaction pattern to open a submenu. If you press the down arrow
key the submenu will open and NVDA will remain in Focus Mode. Same
goes for submenus of submenus: use the right and left arrow keys to
open and close them.
- Todd
Aaron
that necessary for proper screen reading. I don't have a wrapping div
and my menubar role is on the ul. I cannot get my menubar to read as
well as yours.
>
> read more »
Aaron
kills the reading. If I take off the href, it reads as expected
>
> read more »