W3C home > Mailing lists > Public > public-html-a11y@w3.org > March 2012

Re: Drop longdesc, get aria-describedat?

From: Steve Faulkner <faulkner.steve@gmail.com>
Date: Wed, 14 Mar 2012 15:14:45 +0000
Message-ID: <CA+ri+Vn0=8BnN8cFsKyQCNV0jhbgM3xQPx_KNw2GjJveEsq86g@mail.gmail.com>
To: John Foliot <john@foliot.ca>
Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Charles McCathieNevile <chaals@opera.com>, RichardSchwerdtfeger <schwer@us.ibm.com>, W3C WAI-XTECH <wai-xtech@w3.org>, HTMLAccessibility Task Force <public-html-a11y@w3.org>
Hi John,

>I think you are mistaken here (and FWIW I checked this with Rich).

I am checking with rich will get back to you on his reply,

example of brokenness: IE's implementation breaks when an accessible
description on an image is provided using aria-describedby


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

If tools are querying the DOM they can just access the longdesc directly,
IE'simplementation does not help with that in any way, all it does i
pollute the accessible description.

If IE wanted to fudge it they could pass the longdesc value to the acc
value property perhaps.

best regards
Steve

On 14 March 2012 14:42, John Foliot <john@foliot.ca> wrote:

> 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<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):
>
>     "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<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
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Received on Wednesday, 14 March 2012 15:15:39 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:27 UTC