ARIA widget question
Peter Parente
I'm writing a rating widget using Dojo and have a question about the
proper role to assign it. The rating widget uses lit and unlit stars
to visually depict its current value. In looking at the WAI-ARIA spec
about roles, I believe I want to assign a role that subclasses the
abstract "range" type so I can set a minimum, maximum, current value,
and text description of the current value. Of the subclasses of
"range", the definition of sliders seems the most applicable:
slider: A user input where the user selects a value from within a
given range. A slider represents the current value and range of
possible values via the size of the slider and position of the thumb.
It is typically possible to add or subtract to the value by using
directional keys such as arrow keys.
After implementing my widget and testing with NVDA and Orca, I get
mixed results. NVDA reports the proper aria-valuetext as I change the
rating widget value using the keys. However, NVDA also reads the CSS-
hidden span nodes that the widget uses to represent the current value
when stylesheets are turned off (e.g., for high contrast mode).
Orca 2.22.1 properly ignores the hidden spans. However, it reports the
aria-valuenow property as floating point values (1.0, 2.0, etc.) and
ignores aria-valuetext.
Does anyone have a best practice recommendation for this widget?
Peter Parente
writing a custom accessible, internationalized Dojo widget. I want to
make sure I'm giving sound advice on how to implement the ARIA
properties.
Pete
Benjamin Hawkes-Lewis
> After implementing my widget and testing with NVDA and Orca, I get
> mixed results. NVDA reports the proper aria-valuetext as I change the
> rating widget value using the keys. However, NVDA also reads the CSS-
> hidden span nodes that the widget uses to represent the current value
> when stylesheets are turned off (e.g., for high contrast mode).
>
> Orca 2.22.1 properly ignores the hidden spans. However, it reports the
> aria-valuenow property as floating point values (1.0, 2.0, etc.) and
> ignores aria-valuetext.
Could you perhaps link to example markup that triggers these issues?
(Also, which version of NVDA are you testing with?)
--
Benjamin Hawkes-Lewis
Peter Parente
This link takes you to a live copy of the widget on a simple test
page: http://mindtrove.info/html/rating-tutorial.html. You can play
with the widget there and hear how NVDA reads it. Notice as you change
the value using the arrow keys that NVDA speak both the aria-textnow
(e.g., "2 stars") as well as the hidden span node representation of
the stars (e.g., "asterisk asterisk").
Since the widget is built with Dojo, the runtime markup is produced
dynamically through JavaScript. If you're familiar with Dojo, the
widget JS code is here: http://mindtrove.info/scripts/mindtrove/Rating.js.
The Dijit template file is here: http://mindtrove.info/scripts/mindtrove/templates/Rating.html.
The tutorial is meant to accompany these files to explain the Dojo
portions, so they may not be entirely clear on their own. Let me know
if you need clarification on any of the items. I can link you to the
draft of the tutorial if that helps as well.
I used the latest preview release of NVDA for testing, 0.6p2.
Thanks for your interest,
Pete
On Sep 18, 3:24 am, Benjamin Hawkes-Lewis
Aaron Leventhal
The NVDA problem goes away if you update to Firefox 3.1 nightly builds.
We were adding your slider descendant text to the accessible name.
There is an additional problem that we are putting your title in the
accDescription. That's causing NVDA to read that, which is redundant
with the value. I think you should remove the title attribute from the
example.
The Orca problem is that they're not supporting aria-valuetext. Firefox
has to expose this via the "valuetext" object attribute since the
AtkValue interface only supports numbers. (MSAA screen readers don't
have this issue since they tend to ignore the value interface and
accValue, which is a string).
However, Orca is not checking the valuetext which is a bug on their part.
I cannot find a bug in bugs.gnome.org for this so if you're willing,
please file it at http://bugs.gnome.org/
- Aaron
Aaron Leventhal
Once you remove the title attribute do you mind adding your testcase to
http://wiki.codetalks.org/wiki/index.php/Set_of_ARIA_Test_Cases
Just make sure it's clear from the testcase description that the
valuetext should be read.
- Aaron
On 9/18/2008 1:57 PM, Peter Parente wrote:
Becka11y
It's great to see others working on new accessible dojo widgets!
I do have some concerns about removing the title attribute as the
title information is displayed on mouse over and could help people
with cognitive disabilities to better understand the representation.
FWIW I tried this in FF 3.01 (I have updated to FF trunk, yet) in JAWS
9 and the latest 10 beta. JAWS reads the description as "Rate this
tutorial: ( )( )( )( )( )". With my settings it reads "left parend,
right parend" five times then tells me it is a "right-left slider use
the arrow keys to change the value". If the value is set it adds
"star" between the parends. And it reads each value as a percentage
1,2,3,4, or 5. Both JAWS 9 and 10 behave the same
-becky
> Once you remove the title attribute do you mind adding your testcase tohttp://wiki.codetalks.org/wiki/index.php/Set_of_ARIA_Test_Cases
Peter Parente
Can we come to a consensus on title and aria-textnow in this case?
Leaving one or the other off has the potential to disadvantage certain
users.
The parentheses business in the widget was there for testing with
stylesheets turned off. I meant to use asterisks only and will remove
the parens.
I think the problem of JAWS reading the hidden text will still remain,
however. I believe the same reasoning Aaron gave above for NVDA
applies here for JAWS: Firefox 3 puts the hidden descendant text in
the accessible name. I mimicked the close button in dijit.Dialog from
Dojo 1.0 with it's hidden "X" character. Does JAWS read it as well?
I will file the Orca bug and include the tutorial / widget link on the
test cases page as soon as the loose ends are straightened out and I
publish the tutorial.
Pete
Aaron Leventhal
Is the hidden text in the name even for you in nightly builds? For me it
goes away:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
As far as the title. We're putting that in the accDescription because it
could be additional info. That's often how it's used. Some ATs have code
to help avoid speaking redundant strings, but NVDA doesn't have that.
I'm not sure that we should stop exposing that in the accDescription. I
guess we can't come to an immediate decision if you really want to have
that in the title. In that case we'll probably have to think this over
with the various screen reader vendors, and see if they want to check
for redundant text.
- Aaron
Becka11y
Since the close icon in the dijit dialog never get focus, the screen
reader issue of speaking the "x" never occurs. The screen reader or
keyboard user will just press the escape key to close a dialog. We do
have this issue of speaking hidden text with other widget, though.
For example, in the accordion pane the screen reader will speak the
hidden '+' or '-' character that appears at the beginning of the
Accordion title that we make visible only when we detect high contrast
mode. It would really be nice to be able to mark text nodes as
presentation and have them ignored by the screen readers.
-becky
Peter Parente
exposing the text in hidden nodes via IAccessible1/2. Do you know if
other browsers have the same problem?
Aaron Leventhal
> It would really be nice to be able to mark text nodes as
> presentation and have them ignored by the screen readers.
> -becky
>
Starting with Firefox 3.1 (nightlies) have this, we have support for
aria-label.
So you should be able to wrap the text in a span and put aria-label=""
- Aaron
Aaron Leventhal
> > From what Aaron is saying, the problem is fixed in Firefox 3.1 by not
> exposing the text in hidden nodes via IAccessible1/2. Do you know if
> other browsers have the same problem?
We're still defining the accessible name computation. I don't think it's
been well-defined for long enough for browsers to have all the little
details right.
It'd be interesting to start writing tests against these things.
Here's the current name computation we have defined:
http://developer.mozilla.org/en/ARIA_User_Agent_Implementors_Guide#Name_Computation
- Aaron
Benjamin Hawkes-Lewis
> For example, in the accordion pane the screen reader will speak the
> hidden '+' or '-' character that appears at the beginning of the
> Accordion title that we make visible only when we detect high contrast
> mode. It would really be nice to be able to mark text nodes as
> presentation and have them ignored by the screen readers.
In addition to the aria-label solution Aaron mentions, this is an
obvious use-case for CSS generated content using the content property
targeted at the screen and projector media types. Admittedly, this
doesn't work in IE6 and IE7 because they don't support the content
property, but it should work in the forthcoming IE8.
--
Benjamin Hawkes-Lewis
Aaron Leventhal
our testcases have had that, but nothing you'd actually serve for the
general web.
- Aaron
Peter Parente
text appear when CSS is turned off in the browser.
On Sep 22, 11:05 am, Benjamin Hawkes-Lewis