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

Benjamin:

Your comments on the ARIA docs are welcome. Please remember that the
User Agent Implementation Guide and the Authoring Guide are not final.
Especially the Authoring Guide has a way to go.

A new stabilization draft of the UAIG is expected later this week, to be
followed by a second Last Call version later this year.

Regardless, all of these are specific to HTML 4, so should not be looked
to for normative guidance in HTML 5. To the extent we have ARIA in HTML
5, it has so far been negotiated between the PF and the HTML WGs. The
notable exception is this recent 204 decision.

Last comment for now, structure in Describedby is OK when displayed, not
when hidden according to latest ARIA thinking.

Janina

Benjamin Hawkes-Lewis writes:
> 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

-- 

Janina Sajka, Phone: +1.443.300.2200
   sip:janina@asterisk.rednote.net
  Email: janina@rednote.net

The Linux Foundation
Chair, Open Accessibility: http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Protocols & Formats http://www.w3.org/wai/pf
 Indie UI   http://www.w3.org/WAI/IndieUI/

Received on Tuesday, 14 August 2012 22:04:23 UTC