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

 James,

The ARIA task force did not reach consensus on this and you should not be
posting  what is at risk. I understand you have a personal issue on this
but that should not pass to group consensus.

Rich


Rich Schwerdtfeger



From:	James Craig <jcraig@apple.com>
To:	Janina Sajka <janina@rednote.net>
Cc:	WAI XTech <wai-xtech@w3.org>, Richard
            Schwerdtfeger/Austin/IBM@IBMUS, Dominic Mazzoni
            <dmazzoni@google.com>
Date:	12/08/2014 01:04 PM
Subject:	Re: Is ARIA A11y only? [Was: @aria-describedat at-risk ...]




> On Dec 8, 2014, at 10:46 AM, Janina Sajka <janina@rednote.net> wrote:
>
> James Craig writes:
>> 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.
>
> No, I'm not trying to characterize your views about DescribedAt.

Okay, my mistake. It may have been better to start a new thread than
retitle the aria-describedat thread.

> I'm
> extracting one issue that ends up buried in among all kinds of
> discussion about DescribedAt as well as about Longdesc.
>
> I'm trying to clearly say that this same question is emerging from other
> contexts. I named Dpub as an additional source of additional ARIA that
> may be even attractive to mainstream.
>
>> The recommended approach (quoting from ARIA 1.0 Section 1.1):
>>
> Exactly. That was 1.0..
>
> We've several times said we would revisit this concept in 1.1 and
> following. We need to do so apart from any particular feature.

I have heard Cynthia say that from time-to-time though not regarding any
specific feature.

For the record, I disagree with the idea to make ARIA change any mainstream
behavior of user agents.

James


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