Testing Assistive Technology For ARIA Compatibility
Kelly Ford
I wanted to bring up an issue related to testing assistive technology for
ARIA because I've seen a couple references to something that I don't think
is comprehensive enough. I'd be interested in what others think.
I noticed that the wiki referenced in this group links to some tests on the
Paciello Group site at
http://www.paciellogroup.com/blog/aria-tests/role-tests.html.
The tests on that page tell you to turn off the JAWS virtual PC mode and the
equivalent Window-Eyes browse mode and then tab to the different objects. I
think this is not nearly comprehensive enough and in reality you really need
at least three tests for most AT products, in particular any that do some
kind of a buffered view of a web page which is what things like the JAWS
Virtual PC or Window-Eyes browse modes are.
To me the three tests are:
1. Does the ARIA role info get reported in the buffered view of the web
page? For example in testing IE8 with some AT products I've noticed
instances where the ARIA role doesn't get reported, depending on the
underlying item that has the ARIA info added.
2. Can the AT's default mode for exiting buffered mode allow the user to
interact with the ARIA control. Typically this means pressing enter on the
object. In such cases JAWS will indicate forms mode and Window-Eyes Browse
mode off.
3. Does the ARIA info get reported correctly in the AT's interactive mode.
This is really what the tests I indicated earlier are actually testing and
to me they are really the least interesting of the testing criteria.
By way of disclosure, although my personal e-mail address is subscribed to
this group I do work for Microsoft and on the IE team. Part of my
responsibilities there do involve IE accessibility, of which ARIA is part of
the work we are doing.
Thanks,
Kelly
Frank DiPalermo
Let me try to clarify, if I may. I suspect that the reason the tests
refer to turning off the JAWS Virtual Cursor stems from the fact that
one of the goals of the ARIA project is to accommodate web based rich
internet apps. We would like to have JAWS work a web based
application in a similar fashion to a PC based app. That means that
the user tabs around in the app and JAWS follows focus and announces
activity. If the application is tagged as an application, JAWS drops
out of Virtual Cursor automatically. However, this was not the case
early on and so the suggestion to turn off the Virtual Cursor to
simulate JAWS Application Mode.
On Oct 30, 7:09 am, "Kelly Ford" <ke...@kellford.com> wrote:
> Hello All,
>
> I wanted to bring up an issue related to testing assistive technology for
> ARIA because I've seen a couple references to something that I don't think
> is comprehensive enough. I'd be interested in what others think.
>
> I noticed that the wiki referenced in this group links to some tests on the
Steven Faulkner
have broken them down into subsets based on the ARIA spec.
Have completed the first set of tests for JAWS, Window Eyes, NVDA,
Zoomtext. using firefox 3
ARIA User Input Widget role tests - Firefox 3 + Assistive Technology -
http://www.paciellogroup.com/blog/aria-tests/user-input-widgets.html
For JAWS have provided results in virtual PC cursor , Forms and PC cursor modes.
Window eyes, browse and non browse modes
NVDA - virtual buffer pass through endable/disabled.
feedback welcome.
regards
steve
2008/10/31 Frank DiPalermo <fdi...@gmail.com>:
with regards
Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium
www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html
James Teh
Thanks for your work. I've identified a couple of issues which need to
be fixed in NVDA.
Just one thought:
In the second table, for NVDA with the radio group, I don't think the
test is correct. Pressing down arrow while a virtual buffer is enabled
should not move you to the next control; it should move you to the next
line of the buffer. In NVDA's case, this is not necessarily one and the
same. NVDA defaults to using a more screen oriented layout; i.e. the two
radio buttons are on the same line and the [radio group] text is on the
next line. Thus, you were hearing "radio group" because you moved to the
next line, which is correct behaviour.
Note that in NVDA snapshots, there is a feature called "Automatic focus
mode for focus changes" which is similar to auto forms mode in JAWS. It
will also be available in the next preview release of 0.6, which we hope
to release before the new year.
On 4/12/2008 2:47 AM, Steven Faulkner wrote:
> Hi all, have updated the tests
> have broken them down into subsets based on the ARIA spec.
> Have completed the first set of tests for JAWS, Window Eyes, NVDA,
> Zoomtext. using firefox 3
> ARIA User Input Widget role tests - Firefox 3 + Assistive Technology -
> http://www.paciellogroup.com/blog/aria-tests/user-input-widgets.html
>
> For JAWS have provided results in virtual PC cursor , Forms and PC cursor modes.
> Window eyes, browse and non browse modes
> NVDA - virtual buffer pass through endable/disabled.
>
> feedback welcome.
>
>
> regards
> steve
--
James Teh
Email/MSN Messenger/Jabber: ja...@jantrid.net
Web site: http://www.jantrid.net/
Steven Faulkner
I will remove the issue you pointed out, this result was based on my
limited knowledge of how NVDA should work in this circumstance.
regards
steve
2008/12/3 James Teh <ja...@jantrid.net>:
Steven Faulkner
do you think the correct behaviour in the case you mentioned, would be
for NVDA to announce the radio group label prior to announcing the
radio button?
I have left the lack of radio group label announcement in as an issue,
if you don't think it is, then will remove it.
James Teh
On 4/12/2008 8:31 PM, Steven Faulkner wrote:
> do you think the correct behaviour in the case you mentioned, would be
> for NVDA to announce the radio group label prior to announcing the
> radio button?
used as a comment below the radio group itself in the same table cell.
So, in terms of NVDA's virtual buffer, the first line will contain the
two radio buttons, while the second line will contain the "[radio
group]" text. When you press down arrow, you are moving to the next line
of the buffer, so you hear "[radio group]".
Am I misunderstanding your question?
James Teh
to most of the radio group tests.
When many ATs (including JAWS and NVDA) are in their virtual buffer
browsing mode, tab moves between controls, but the cursor keys move up
and down through the virtual buffer, a flat representation of the
document. Thus, pressing tab to move to the radio group and then
pressing down arrow to move to the next radio button in the group does
not do what you expected. As I noted, pressing down arrow moves to the
next line of the virtual buffer and reads it according to the virtual
buffer browsing mode. In both NVDA and JAWS, the role is read before the
text when browsing the buffer because this is more logical when reading
a document; one wants to know when a link begins, rather than only
knowing once it ends that the text was a link. You note the following
issue for JAWS:
"Role and name announced in reverse order. (second radio button)"
As I've described, this is by design; pressing down arrow was not meant
to be passed to the control, but instead, it moved to the next line in
the buffer and read it accordingly.
This is one of the reasons for features which automatically switch to
focus/forms mode. If a user presses tab, it is logical to assume that
they probably want to interact with the control and not the buffer.
Thus, pressing tab to move to the radio group will enable focus/forms
mode and down arrow will then do what you expect because you are
interacting with the control.
Does (any of) this make sense?
Steven Faulkner
apologies for not explaining myself better.
In the radio group test what is being tested is whether the radio
group name "label" information gets associated with the radio buttons
contained within the radio group. the expected behaviour when in
application/forms mode is (in my opinion) that the radio group label
is announced before the name of each radio button in the radio group.
In the first table JAWS and Window Eyes announce the radio group name
"label" before each radio button name "radio 1" and "radio 2".
NVDA announces the radio group label before the first radio button
label, but not the second.
regards
steve
2008/12/4 James Teh <ja...@jantrid.net>:
James Teh
> In the radio group test what is being tested is whether the radio
> group name "label" information gets associated with the radio buttons
> contained within the radio group. the expected behaviour when in
> application/forms mode is (in my opinion) that the radio group label
> is announced before the name of each radio button in the radio group.
> In the first table JAWS and Window Eyes announce the radio group name
> "label" before each radio button name "radio 1" and "radio 2".
> NVDA announces the radio group label before the first radio button
> label, but not the second.
NVDA has a concept of focus ancestors and only speaks changes in the
ancestry. If you enter a dialog, screen readers don't read the dialog
name and role every time you tab to a control in that dialog. We take
this concept and extend it to apply to *any* container object. Thus, if
you enter a grouping, the grouping is only read once when you enter it
and is not read again as long as the focus stays within that grouping.
This is by design, although I agree that it is inconsistent with most
screen readers, which announce grouping information for each control in
the grouping. I would argue that it is consistent with other containers
- as noted, dialogs aren't read every time the user tabs to a control
within the dialog.
Steven Faulkner
will remove the issue related to this for NVDA in the test results.
Steven Faulkner
After thinking about it, I have created a test page
(http://www.paciellogroup.com/blog/aria-tests/fieldset.html) that
contains a native HTML group box and label , containing 2 radio
buttons, using the fieldset and legend elements.
I would expect that assitive tech would behave in the same way with
the fieldset as with the ARIA radio group. So will test with the
fieldset example and modify the radio group issue results based on the
fieldset tests.
thanks for all your feedback.