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

On Tue, Aug 14, 2012 at 9:15 PM, Janina Sajka <janina@rednote.net> wrote:
> You also have problems with currently spec'd legitimate uses of
> ARIA-Describedby.

Seems like the thread has dealt with all the problems you've brought
to the table. Can you elaborate on what other problems you're thinking
of here?

> So, now we have a Describedby that sometimes displays, and sometimes
> does not; that sometimes waits for users to request access to the
> Describedby content, and other times auto displays it.
>
> You've overloaded this simple ARIA construct

I think @aria-describedby is fairly complex and difficult approach to
solving problems associating help text with a form field or a long
description with an image, not a "simple … construct".

This dual behavior you mention is straight out of the ARIA specs which
continue to insist that @aria-describedby implies both a plain text
accessible description and a pointer to (potentially complex) content:

"Note that aria-describedby may reference structured or interactive
information where users would want to be able to navigate to different
sections of content. User agents MAY provide a way for the user to
navigate to structured information referenced by aria-describedby and
assistive technology SHOULD provide such a method."

http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_relations_reverse_relations

AFAICT the specs don't suggest how AT is supposed to decide when to
render the computed accessible description, or provide a hook for
navigating to a long accessible description, or both. Hopefully PFWG
will consult implementors on this point, since implementors have
recently been struggling with the rather similar problem of deciding
when to surface a computed accessible name and when to surface element
content, resulting in a "explicit name" attribute being proposed for
IA2:

http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2011-July/001490.html

http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2012-July/001628.html

http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2012-August/001633.html

It's true that PFWG very recently altered the ARIA drafts to exclude
hidden content from the accessibility tree:

"The following elements are not exposed via the accessibility API and
user agents MUST NOT include them in the accessibility tree …
Elements, including their descendents, that have host language
semantics specifying that the element is not displayed, such as CSS
display:none or visibility:hidden or HTML 5 hidden attribute."

http://www.w3.org/WAI/PF/aria-implementation/#exclude_elements2

This doesn't really make sense, as CSS isn't an ARIA host language.
More importantly, it seems deeply unlikely to lead to interoperable
implementations since "element is not displayed" is really very vague
- what about offscreen elements? clipped elements? elements inside a
closed <details> or <dialog>?

Anyway, this provision doesn't prevent the HTML spec from specifying
the semantics of hidden such that user agents can display it if focus
enters it, in which case a user agent would be required (by ARIA no
less) to expose it to the accessibility tree.

> And, am I correct that this is still vaporware?

I don't think the dismissive term "vaporware" is applicable to an
implementation idea.

"Vaporware is a term in the computer industry that describes a
product, typically computer hardware or software, that is announced to
the general public but is never actually released nor officially
cancelled. Vaporware is also a term sometimes used to describe events
that are announced or predicted, never officially cancelled, but never
intended to happen. The term also generally applies to a product that
is announced months or years before its release, and for which public
development details are lacking. "

http://en.wikipedia.org/wiki/Vaporware

I can appreciate your scepticism about the likelihood of such
implementations sufficiently widely and interoperably to justify
calling this technique "accessibility supported", but it does seem to
me your language is incredibly dismissive of an implementation idea
from an engineer who works on accessibility code for a major
accessibility vendor.

--
Benjamin Hawkes-Lewis

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