Re: Is ARIA A11y only? [Was: @aria-describedat at-risk ...]

On Dec 8, 2014, at 10:14 AM, Janina Sajka <janina@rednote.net> wrote:

> There's an important question that's being lost when discussed in the
> context of ARIA-DescribedAt (or the context of HTML Longdesc). We need a
> clear consensus statement somewhere in our ARIA docs about whether, or
> not ARIA is restricted for use by AT user agents via Accessibility APIs.
> 
> In other words, do we insist the curb cut is for wheel chairs only? All
> skate boards and baby strollers must stay away.

This is a misinterpretation of the case against @aria-describedat. ARIA has always been an accessibility-only approach. If you want to use the curb cut analogy, native host language features are the curb cuts. @aria-describedat may be more equivalent to the bolt-on wheelchair elevators you sometimes see used to retrofit old staircases.

The recommended approach (quoting from ARIA 1.0 Section 1.1):

>> WAI-ARIA is intended to be used as a supplement for native language semantics, not a replacement. When the host language provides a feature that provides equivalent accessibility to the WAI-ARIA feature, use the host language feature. 

Using the native host language feature *is* the "curb cut" for everyone. ARIA is not, and never has been, a feature for everyone. ARIA provides amazing ability to retrofit legacy code and augment incomplete languages (including HTML) with additional accessibility semantics, but ARIA has never changed mainstream User Agent behavior. 

Case in point: tabindex. TabIndex is not part of ARIA for the same reason that @aria-describedat cannot be. It changes the behavior of the browser in a way that affects everyone, so any feature that provides this functionality MUST be part of the native host language.

James


> It's probably the case that DescribedAt is the wrong context for this
> larger policy question because it's so freighted with deeply entrenched
> viewpoints and a long, contentious history in the form of HTML Longdesc.
> 
> However, other ARIA applications are shortly to emerge from our joint
> efforts with the Digital Publishing Interest Group in the W3C which will
> also raise the question of who can benefit from ARIA. This is why we
> need a more widely applicable, and clearly articulated group consensus
> on the question.
> 
> We have heard recently, and in years past the browser developers among
> us say that keeping ARIA restricted to AAPIs explains much of their
> success. Because there are not requirements on mainstream browsers, it's
> been relatively easy to add ARIA support. Here's David Bolter on this
> very question in 2012, though it, too, is hidden in discussion of
> Longdesc and DescribedAt:
> 
> http://lists.w3.org/Archives/Public/public-html-a11y/2012Mar/0405.html
> 
> My personal view is that we should probably clarify our ARIA spec
> language on this point. Where we currently have language such as "user
> agents should" should be broken out into something along the lines of
> "mainstream user agents may implement" with respect to their own UI, and
> "should provide interfaces for AT applications via AAPIs."
> 
> Can we perhaps separate the DescribedAt conversation along these lines?
> The feature itself, vs who's expected to do what with it as a separate
> conversation about who's allowed to benefit from ARIA in general?
> 
> Janina
> 
> -- 
> 
> Janina Sajka,	Phone:	+1.443.300.2200
> 			sip:janina@asterisk.rednote.net
> 		Email:	janina@rednote.net
> 
> Linux Foundation Fellow
> Executive Chair, Accessibility Workgroup:	http://a11y.org
> 
> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> Chair,	Protocols & Formats	http://www.w3.org/wai/pf
> 	Indie UI			http://www.w3.org/WAI/IndieUI/
>

Received on Monday, 8 December 2014 18:41:49 UTC