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

On Wed, Aug 15, 2012 at 1:39 AM, John Foliot <john@foliot.ca> wrote:
> 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.

   * I didn't say "complex descriptions" I said "complex hidden long
descriptions" with "no default visual indicator that they even exist".

   * I didn't say "non-sighted users" I said "a minority of users".
(Given I just complained about your repeated implication that we need
reminding that accessibility is not just about blind users, this
misreading is frustrating.)

   * I didn't say "only … of use" I contrasted "so useless" and "so useful".

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

The perjorative rhetoric about "Browsers … washing their hands" is
deeply unfair, since the confusion about how user agents should handle
ARIA comes from differences in opinion among people working on the
spec and the failure to commit by the spec itself.

Anyway we've had more than one vendor make positive noises about using
more ARIA semantics within their main UI:

Firefox: http://lists.w3.org/Archives/Public/public-html-a11y/2012Mar/0261.html

Opera: http://lists.w3.org/Archives/Public/public-html/2012Mar/0604.html

I'm sceptical, of course, but we shouldn't just discount vendor feedback.

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

FWIW MS apparently expressed doubt:

"At the recent F2F, Microsoft representatives said that they believed
exposing full semantics for aria-describedby content would be very
hard to do in IE (in combination with the mainstream screen readers on
Windows)."

http://lists.w3.org/Archives/Public/public-html/2012May/0131.html

Having said that, that view might change based on Maciej's
implementation ideas. Or maybe it was based on misconceptions like
those expressed in Richard's response. Without a written record it's
hard to know.

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

AFAICT no ARIA spec has ever been designated for "non-sighted-users -
only", or restricted the use of its semantics to accessibility APIs,
or limited its requirements to accessibility APIs. Maybe you can cite
the bits of the specs you think say this.

> As a mechanism to express roles, states and properties it's actually fairly adept.

If we were authoring "native" HTML to be interpreted according to its
semantics for all users, ARIA would be redundant.

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

Nobody believes that.

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

Your test of whether an AT vendor is "major" by looking at whether
they "address the needs of the other major disability groups" would
probably exclude Freedom Scientific and Ai Squared. As it happens, I
think Apple do include key features for the groups you mention. For
example:

   * Mobility: sticky keys, on-board speech recognition
   * Auditory: iPhone TTY Adapter, captions in QuickTime
   * Cognitive: bit of a broad category but see discussion at:
http://images.apple.com/education/docs/L419373A-US_L419373A_AppleTechDisabilities.pdf

Whether they do a "good job" for these users I dunno. There certainly
seem to be some happy mobility-impaired iPad users:

"Not having the full use of my hands, accessing the full potential of
a computer was a challenge, as computers became more sophisticated,
they became increasingly more difficult for me to use easily. I began
using a headstick,and finally a mouthstick to type. … When Apple first
introduced the iPad in 2010, I did not pay much attention … I had to
come up with a new piece of equipment … So, one day, I found the
perfect solution to this problem -- a capacitive tip. … The iPad has,
believe it or not, changed my life. This is a piece of technology that
almost everyone has, so I do not stand out as having a specialized
piece of equipment. It has helped me be more integrated in mainstream
society."

http://www.lmcohenour.com/p/article-ipad-accessibility.html

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

I think authors creating complex descriptions with a default visual
indicator is a better 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.
>>
>> 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).

Doesn't answer my question at all.

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

Focusing on motivations rather than substance and effects of CPs seems
unhelpful.

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

Never said it was.

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

That's one of the things it's designed to do. It's certainly not the only.

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

One example of how you are wrong her is that speech-to-text software
solutions depend on accessibility APIs and ARIA changes how HTML
documents are represented to those accessibility APIs.

> It is a specific and limited technology with a specific design goal and modest footprint.

Hardly.

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

Not when it's displayed, no, and *there's no problem with that*.

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

Up to the implementors of the UA.

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

Poverty of existing @longdesc values in the corpus would be the
strongest argument against user agents doing this.

Disinterest among implementors such as the Firefox accessibility
engineers in doing this would be a practical reason not to spec it.

> All of this therefore questions the value of the proposal in the first place.

A key rationale for allowing @aria-describedby to reference hidden
content was that authors will do this whatever the specs say.
Similarly, authors might reference complex hidden content whatever the
specs say.

For example, consider the suggested ARIA technique of using
@aria-describedby to reference a hidden tooltip as help text for a
control:

    http://www.w3.org/WAI/PF/aria-practices/#kbd_tooltips

What happens if authors need to include controls such as links in the
rich tooltips providing help for form fields, for example:

   <label>Send me relevant information from third parties <input
type=checkbox aria-describedby=marketing-opt-in-tooltip></label>
   <p id=marketing-opt-in-tooltip hidden>You may wish to view our <a
href="/privacy-policy.html">privacy policy</p>.</p>

If we follow the current "ARIA thinking", AAPI clients won't be able
to access the link unless the tooltip is unhidden.

If we follow the current "HTML5 thinking", AAPI clients might be able
to access the link even when the tooltip is hidden. This would be
handy if (for example) the author fades the tooltip out and then hides
it after briefly displaying it on focus, or if the author doesn't show
it on focus at all (only hover).

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

I think it's impossible to untangle WAI-ARIA and HTML in practice,
short of giving up on making HTML a conforming ARIA host language and
just going ahead and defining aria-* and role independently.

--
Benjamin Hawkes-Lewis

Received on Wednesday, 15 August 2012 18:58:51 UTC