Re: FORMAL OBJECTION (was RE: Working Group Decision on ISSUE-204 aria-hidden)

On Tue, Aug 14, 2012 at 10:25 PM, John Foliot <john@foliot.ca> wrote:
> Benjamin Hawkes-Lewis wrote:
>>
>> Obviously, if we wanted to create a
>> mechanism where any user without specialised AT could open long
>> descriptions we wouldn't design it the way we've stumbled upon and
>> around this feature.
>
> And herein lies one of the fundamental problems we are grappling with: The Chairs decided that Issue 30 @longdesc would be deferred until a resolution of Issue 204 was decided. It is abundantly clear (at least to me) that now that Issue 204 paves the way for embedding @hidden longer textual descriptions that include structured content, and further suggests that Accessibility APIs are to process that structured content AS structured content*, that this decision will be held up as "THE ALTERNATIVE" that allows for the obsolescence of @longdesc.
>
> It isn't, it falls significantly short of allowing all users access to longer textual descriptions, and further now introduces a number of new access issues for those users who require some form of accommodation or alternative consumption model - examples that I and others continue to bring forth.

Indeed ARIA introduces all sorts of accessibility problems.

> It is deeply troubling to me that we still need to remind this Working Group that on-line accessibility is more than just accommodating blind users.

You don't …

The replies of Maciej and I specifically addressed the requirements of
people other than blind users, as did discussion around this issue
before.

> (* It should also be noted that no AT vendor - outside of VoiceOver - has even suggested that they can or will provide such additional support at this time.)

Or to put it another way, a major AT vendor has suggested that they
could support an HTML accessibility feature.

(And, as I described, it's easy to imagine - in terms of technical
design - browsers rather than AT shouldering most of the work here.)

>> Now there could be a problem when Dragon is used in combination with
>> other AT such as JAWS (as it sometimes is),
>
> Sure: Jawbone (http://www.speechtechnology.com/products/disabilities/jawbone.html)
>
>
>> if the AT was responsible
>> for rendering an visual overlay. In that case you'd need to ensure the
>> overlay itself was exposed to the accessibility hierarchy for use by
>> other AT. The same goes for other interfaces rendered by JAWS such as
>> the links list.
>
> Simply put, this is a bad idea.

Not persuasive!

> That it can be hacked together to sort of work for users of Accessibility API consuming tools (a.k.a. AT) misses the larger issue.

The words "hacked" and "sort of" seem unjustified. Please explain why
you think these sort of reconfigurations of content are so different
to VoiceOver's Item Chooser, Opera's Link List, JAWS's virtual buffer,
or JAWS's summary feature …

> There are a myriad of tools and combinations of tools that people with disabilities use to access not only web content, but to simply interact with their computing devices: we should be designing HTML to work for all users, without insisting that they have AAPI aware tools to do so.

This sentiment (which I wholely agree with) militates for obsoleting
most of ARIA, as it's been half-designed from an utterly
irreconcilable perspective in which HTML is a crude visual layout tool
that needs patching up with metadata, but anyway the proposal adopted
allows all these tools to be changed to access hidden descriptions and
expose the content to end users who want to see them. The proposal
doesn't encourage the user agent to expose the semantics to AAPIs but
to "Assistive Technology". That technology might be in the user agent
itself. I agree the expression is clunky, but I think this clunkiness
is similar to that in ARIA, e.g.:

"The WAI-ARIA specification neither requires or forbids user agents
from enhancing native presentation and interaction behaviors on the
basis of WAI-ARIA markup. Mainstream user agents might expose WAI-ARIA
navigational landmarks (for example, as a dialog box or through a
keyboard command) with the intention to facilitate navigation for all
users. User agents are encouraged to maximize their usefulness to
users, including users without disabilities."

http://www.w3.org/WAI/PF/aria/complete#ua-support

Whether enough tools are _likely_ to implement features as suggested
by Maciej is different question from whether it's a good idea, just as
whether enough tools are likely to implement @longdesc is a different
question from whether it's a good idea on some theoretical level.

--
Benjamin Hawkes-Lewis

Received on Tuesday, 14 August 2012 21:57:15 UTC