Re: Drop longdesc, get aria-describedat?

Some clarification.


Rich Schwerdtfeger

John Foliot <john@foliot.ca> wrote on 03/14/2012 09:42:36 AM:

> From: John Foliot <john@foliot.ca>
> To: Steve Faulkner <faulkner.steve@gmail.com>,
> Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Silvia
> Pfeiffer <silviapfeiffer1@gmail.com>, Charles McCathieNevile
> <chaals@opera.com>, Richard Schwerdtfeger/Austin/IBM@IBMUS, W3C WAI-
> XTECH <wai-xtech@w3.org>, HTMLAccessibility Task Force <public-html-
> a11y@w3.org>
> Date: 03/14/2012 09:52 AM
> Subject: Re: Drop longdesc, get aria-describedat?
>
> Quoting Steve Faulkner <faulkner.steve@gmail.com>:
>
> > the bug is in the IE implementation
> > acc description is for a human readable description not to pass URL's
> >
> > the implementation is broken and poorly thought out.
>
> Hi Steve,
>
> I think you are mistaken here (and FWIW I checked this with Rich).
>
> At issue is the AAPI (and now ARIA) processing of non-visible content.
>   The ARIA Implementation Guide states:
>
>       "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 hidden, such as CSS
> display:none or visibility:hidden or HTML 5 hidden attribute."
> - http://www.w3.org/WAI/PF/aria-implementation/#exclude_elements
>
> Since active links (and other Semantic structure) should normally be
> exposed to the Accessibility Tree, but hidden content NOT exposed, the
> URL for the longer description that @longdesc references
> (ROLE_SYSTEM_LINK) must not be conveyed, thus it defaults to
> AccDescription (which is string text):
>
We need to separate out what ARIA specifies and how IE or other browser
handle longdesc. First formal longdesc mappings to accessibility API was
never done by industry. Consequently implementations vary. As I understand
it IE maps the URL string to a description which to me is of little value.
Imagine asking for the help text and hearing "http://www... ". Yuck. The
reason they may have done this because MSAA was very limited when it
released and its use was not well documented. So, developers did the best
they could and they would stick information into the limited property set
available. The IE folks probably thought "accDescription, it take a string.
Put it there." It is what it is. We can do better.

What longdesc should be for is referencing rich content that can be seen in
a browser or accessed by and AT for browsing the content. Stuffing a string
with a URL does not achieve that.

aria-describedby was designed to reference local content that can be seen
and reviewed by a user unless it is hidden to the user in which case the
content being pointed to is provided a human speakable help string in the
accessibility API.

These are different use case. Steve and I are working on an ARIA placement
for longdesc that we intent to be better specified to meet the use case.
Example use case: User walks into a museum and sees a kiosk with images
that indicate more information is available. The user commands the user
agent to render rich content related to that object in the form of HTML
content in the context at which they are operating. When done, that content
goes away and returns the user to where they left off on the original page.
This is different from aria-describedby that only reference content on the
local page.


>       "The text alternative for a given node is computed as follows:
> Skip hidden elements unless the author specifies to use them via an
> aria-labelledby or aria-describedby being used in the current
> computation. By default, users of assistive technologies won't receive
> the hidden information, but an author will be able to explicitly
> override that and include the hidden text alternative as part of the
> *label string* sent to the accessibility API." (emphasis mine)
> - http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd
>
> IE is actually getting it right!
>
> In all working example of @longdesc today (whether via a screen reader
> or 3rd-party browser extension) they all operate by querying the DOM,
> which IMHO is not actually "broken or poorly thought out" - in fact it
> simply underscores that any HTML consuming tool *could* do something
> useful with @longdesc, they simply choose not to.
>
> JF
>
>