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

Benjamin Hawkes-Lewis wrote:
> 
> The premise of complex hidden long descriptions is that there will
> exist complex long descriptions that are so useless to most users that
> there must be no default visual indicator that they even exist, but so
> useful to a minority of users that they must be capable of being
> opened.

Not exactly. The premise of complex descriptions is that they should also be able to avail themselves to the full richness that HTML provides, which includes headings, lists, tables, and yes, hyperlinks. Jumping to the conclusion that they would only be of use to non-sighted users and "useless" to everyone else is a critical flaw in reasoning. Stashing them away into a div that is @hidden perpetuates this flawed reasoning, and is actually more harmful than useful to many of those "other" users, who cannot access that content without also using a screen reader. This is the fundamental flaw of the current Change Proposal.

> 
> Mouth-stick users who need to open complex long descriptions will need
> clientside software (whether that's a browser or AT or some
> combination of the two) that renders them on screen at least while
> focus is inside the long description.

Correct, and now, per this decision, that client-side software will need to be a screen reader or other ARIA/Accessibility API aware tool. Yet we really have no indication that any of the Browsers intend to make their tools ARIA-useful, but instead we have a history that suggests they will hand off the ARIA data to the AAPI, wash their hands, and proclaim they are doing what the ARIA spec says they should be doing. Unless of course you or others have evidence that this is NOT the case.


> 
> Mouth-stick users who don't need to open complex long descriptions
> won't need such clientside software and therefore won't be opening
> complex long descriptions, and therefore will not fall into an
> invisible keyboard trap.
> 
> Clientside software that moves focus into complex content hidden using
> the @hidden attribute without showing the content in some way would be
> buggy.

Yet, that is what we sort of have, or have proposals for, today. Maciej has commented extensively on how VoiceOver might do this and that, but we've not heard from any other implementer how this would work, and it places the burden of a mouth-stick user to always run VoiceOver, and then somehow magically trigger the non-visible link using their stick (or something like that... it is all very unclear how this would actually support such a user).


Later, Benjamin Hawkes-Lewis wrote:
> >
> > 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.

Actually, attempting to over-extend the value of ARIA is where the problems exist. ARIA was initially designed to be a bridge between HTML and the Accessibility APIs for non-sighted users - only. As a mechanism to express roles, states and properties it's actually fairly adept. It is when some people so fully embrace the *idea* of ARIA to believe that it will solve all access problems that we run into problems.


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

Without for one minute dismissing the value of VoiceOver, or the advances that Apple have achieved with VoiceOver, I find it a bit of a stretch to call Apple a major AT vendor. They are a hardware and software vendor that have added text-to-speech support to their operating system to assist non-sighted users. So have Microsoft, as well as the Open Source Linux community. Have Apple done a good job? Absolutely. Does it address the needs of the other major disability groups (Mobility, Auditory, Cognitive)? Perhaps Cognitive, in the same way that Read Write Gold and other 'read aloud' programs assist in comprehension for some users.

> >
> > Simply put, this is a bad idea.
> 
> Not persuasive!

Then you believe that creating complex descriptions that can only be accessed by ARIA aware AT is a good idea? Your counter-point is equally non-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 …

The Change Proposal seeks to fundamentally re-wire what and how ARIA was designed to operate, by adding 'features' that alledgedly benefit non-sighted users (or users who will now require an ARIA aware tool to access extended descriptions).

I call it a hack, because one of the motivators of the initial CP is to move an important, existing native HTML mechanism (@longdesc) into a quasi-ghetto of "and here's the stuff for AT only". As you yourself have pointed out, this is a poor and flawed design decision which *I* believe is based on inaccurate and mistaken understanding of what ARIA can and cannot do by its initial design, and an unreasonable drive to vindicate WHAT WG's decision to obsolete @longdesc. And make no mistake about it, in my opinion *THAT* more than anything else is the end game that Maciej, Jonas and Matt are working toward. (It likely goes without saying that Hixie will never back down on this point, and so there is also a desire to minimize the number of differences between his "Living Standard" and the W3C Recommendation. While I disagree with this goal, I must accept that it exists.)

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

Whoa! ARIA was not designed to be The Accessibility Savior. It was designed as a way for HTML (rather DHTML) and later other mark-up languages that were moving to "applications", to communicate with the same Accessibility APIs that screen readers used when it came to native GUI widgets. Period. 

ARIA was not designed to interact with alternate switching devices, speech-to-text software solutions, nor to address the needs of Deaf and HoH users, nor reduce the cognitive load or other comprehension issues that some users my need to deal with, be it due to dyslexia, color blindness or Down's Syndrome. It is a specific and limited technology with a specific design goal and modest footprint.


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

Hang on half a second here. A mouth stick + sticky keys *IS* considered AT by some: If the browser itself is to expose the @hidden content to those users, then it can no longer be hidden can it? And if it is to be exposed to that user, how will that exposure look? Both the actual content, as well as the indicator that would be required? And significantly, why cannot that same mechanism of exposure be applied to @longdesc today, thus taking advantage of legacy gains, no matter how small they may appear to be? All of this therefore questions the value of the proposal in the first place. You need to think this through a bit further.

The idea behind the current CP is that the content can remain hidden *to all* except those who are using ARIA aware tools (with the implied message that this is screen readers - thus my earlier comment). This, the reasoning goes, will allow authors to provide the rich descriptions that complex images require in-line, as opposed to linked (as @longdesc provides), and hide it from all the sighted users using @hidden, and then only expose it (and its richness) to <del>VoiceOver</del> <ins>AT</ins>, failing (from my perspective) to acknowledge that AT is more than just a screen reader.


> 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

If you have constructive feedback on the emergent ARIA Recommendation, there is a forum for that elsewhere that I encourage you to pursue. Meanwhile, we are focused on HTML, and specifically HTML5, in this discussion: slamming ARIA on this list is neither germane nor useful at this point.


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

And this is where there is a difference today: some (many?) tools HAVE adopted and support @longdesc - and tools that far transcend screen readers alone (for example, content authoring tools). But a small group of engineers have it in their minds that @longdesc must go, and are willing to swallow any hand-waving imagineering and "suggestions on how it might work" tomorrow, in their fevered push to oust @longdesc at all costs today.

JF

Received on Wednesday, 15 August 2012 00:40:04 UTC