- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Tue, 14 Aug 2012 22:28:23 +0100
- To: Maciej Stachowiak <mjs@apple.com>, Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>, John Foliot <john@foliot.ca>, Sam Ruby <rubys@intertwingly.net>, public-html@w3.org, HTML Accessibility Task Force <public-html-a11y@w3.org>
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:13 UTC