Re: aria vs native alternatives [was: Re: feedback requested on WAI CG Consensus Resolutions on Text alternatives in HTML 5 document]

On 02/09/2009 15:29, Smylers wrote:
 > Jim Jewett writes:

[snip]

 >> Why can't lynx or firefox use the aria-* attributes?
 >
 > Aria has not been designed with non-accessibility uses in mind.  What's
 > best for accessibility software may not be best for other purposes.

It's true that helping people with disabilities is the practical goal of 
ARIA.

It doesn't follow from /this/ that user agents like Lynx or Firefox 
cannot use aria-* attributes to do more than expose them to the DOM and 
accessibility APIs. Not all people with disabilities use assistive 
technologies; user agents have accessibility requirements that go beyond 
exposing APIs (http://www.w3.org/TR/WAI-USERAGENT/). For example, all 
popular browsers allow users to customize text color, font, and size to 
increase legibility and all popular browsers support keyboard navigation 
and operation.

The stated goals of the ARIA editor's draft 
(http://www.w3.org/WAI/PF/aria/) are: "supporting device independence 
for new devices such as telephones, PDAs, and televisions; improving the 
accessibility of dynamic content generated by scripts; and providing for 
interoperability with assistive technology."

ARIA imposes some requirements on the functionality provided by host 
languages (like HTML). These requirements definitely include features 
that /any/ user agent can use when providing a user interface. 
Specifically (§6.1.3):

"An implementing host language MUST provide support for the author to 
make arbitrary elements focusable, such as the 'tabindex' attribute in 
HTML."

This appears to be how ARIA helps televisions. ;)

For conforming user agents, ARIA states: (§7.1):

"WAI-ARIA processing by the user agent MUST NOT interfere with the 
normal operation of the built-in features of the host language.

"Scripted changes in the DOM and style rules which change the 
presentation of the content based on selectors sensitive to WAI-ARIA 
markup MUST be considered as part of normal operation. On the other 
hand, the mapping to accessibility APIs MUST be considered, in applying 
this rule, to be above and beyond normal operation. The WAI-ARIA 
processing MAY alter the mapping of the host language features into an 
accessibility API, but the mapping to the API MUST not alter the DOM."

And (§8.2): "User agents SHOULD expose role, state, and property 
information provided by the author to accessibility APIs available in 
their operating system."

For conforming assistive technologies, ARIA states (6.1.3):

"If the host language incorporates WAI-ARIA support and there is a 
conflict between a host language feature and an WAI-ARIA feature, 
assistive technologies SHOULD assign preference to the WAI-ARIA feature. 
Also, if the user agent supports an accessibility API, user agents 
SHOULD convey the WAI-ARIA metadata to the accessibility API."

Note ARIA does not require or prohibit user agents providing UI based on 
ARIA where doing so does not "interfere with the normal operation of the 
built-in features of the host language". A lot hinges on how you 
interpret this phrase, but the draft doesn't give much help.

The descriptions of some WAI-ARIA features seem to envisage user agents 
making direct use of them.

The description of "aria-invalid" says (§5.4): "User agents SHOULD 
inform the user of the error. … User agents MAY refuse to submit the 
form as long as there is an element for which aria-invalid is true."

The description of "aria-flowto" says (§5.4): "In the case of one or 
more IDREFS, user agents or assistive technologies SHOULD give a user 
the option of navigating to any of the elements targeted."

The description of "aria-live" says (§5.4): "Politeness levels are 
essentially an ordering mechanism for updates and serve as a strong 
suggestion to user agents or assistive technologies." For the 
"assertive" value, "This information has the highest priority and user 
agents SHOULD notify the user immediately."

A lot also hinges on how you interpret the distinction between "user 
agent" and "assistive technology". The draft does not provide normative 
definition of these terms, only an informative glossary (§9.2).

User agent is defined as: "Any software that retrieves and renders web 
content for users, such as web browsers, media players, plug-ins, and 
other programs including assistive technologies."

Accessibility technology has a much longer definition that doesn't make 
it much clearer which conformance requirements apply to which software:

"Hardware and/or software that acts as a user agent, or along with a 
mainstream user agent, to meet the interface requirements of users with 
disabilities beyond those offered by the mainstream user agents.

"Services provided by assistive technologies include alternative 
presentations (e.g., synthesized speech or magnified content), 
alternative input methods (e.g., speech recognition), additional 
navigation or orientation mechanisms, and content transformations (e.g., 
to make tables more accessible).

"Assistive technologies often communicate with mainstream user agents by 
using and monitoring accessibility APIs.

"The distinction between mainstream user agents and assistive 
technologies is not absolute. Many mainstream user agents provide some 
features to assist individuals with disabilities. The basic difference 
is that mainstream user agents target broad and diverse audiences that 
usually include people with and without disabilities, assistive 
technologies target users with specific disabilities. The assistance 
provided by assistive technologies is more specific and appropriate to 
the needs of its target users.

"Examples of assistive technologies that is important in the context of 
this document include the following: screen magnifiers, which are used 
to to enlarge and improve the visual readability of rendered text and 
images; screen readers, which are most-often used to convey information 
through synthesized speech, sound iconography, or Braille; 
text-to-speech software, which is used to convert text into synthetic 
speech; speech recognition software, which is used to allow spoken 
control and dictation; alternate keyboards (including head pointers, 
single switches, and sip/puff devices), which are used to simulate the 
keyboard; alternate pointing devices, which are used to simulate mouse 
pointing and clicking."

I /think/ it's safe to say that PFWG intend that while mainstream user 
agents like Opera could provide a shortcut key for HTML5's "nav" element 
(for example), they should not provide the same shortcut key for "div 
role='navigation'". The advantage of this approach is that divitis-based 
Ajax frameworks like Dojo can incorporate ARIA to provide support to 
assistive technology that uses system accessibility APIs without any 
side-effects for other users and that ARIA can be used as a bridge while 
support for HTML5 is still developing. The disadvantage of this approach 
is that ARIA cannot serve as a general solution for making arbitrary 
markup "accessible", and that, in so far as other markup can be made 
"accessible" but still requires ARIA to expose the correct information 
to system accessibility APIs, it will require authors to encode the same 
information twice.

However, I don't believe this intention of PFWG is clearly reflected in 
conformance criteria in the current draft. Since "interfere with normal 
operation of the built-in features of the host language" is vague and 
"assistive technology" is not normatively defined, it's not clear to me 
on what basis one could say Opera (or Lynx!) would be non-conforming if 
they exposed the same shortcuts for "nav" and "div role='navigation'".

--
Benjamin Hawkes-Lewis

Received on Wednesday, 2 September 2009 17:46:04 UTC