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

Hi benjamin

>/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'".


"There are also mainstream benefits of providing navigation landmarks. Your
browser may assign key sequences to move focus to these sections as they can
be set on every site. Navigation to these landmarks is device independent. A
personal digital assistant (PDA) could assign a device key to get to them in
your document."
http://www.w3.org/WAI/PF/aria-practices/#kbd_layout

This passage from the best practices guide indicates that ARIA landmarks
could be used to provide keyboard navigation in mainstream user agents. and
it would make sense in the case of the <nav> element it was mapped to the
shortcut as role="navigation", though it would not makes sense for some
other HTML5 elements to be mapped onto landmark roles.

regards
stevef

2009/9/2 Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>

> 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
>
>


-- 
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