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

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.

Despite repeated attempts to explain these problems to many members of the Working Group, this understanding appears to not be getting through. Why that is I cannot say for certain, but it does lead to a certain sense of frustration. 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.

(* 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.)

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

JF

Received on Tuesday, 14 August 2012 21:26:11 UTC