Re: Drop longdesc, get aria-describedat?

Ok fair enough. That clarifies that point. Thanks.
Silvia.



On 09/03/2012, at 5:33 PM, "John Foliot" <john@foliot.ca> wrote:

> Silvia Pfeiffer wrote:
>> 
>>> First off: Steve yesterday confirmed that Internet Explorer's
>> longdesc
>>> implementation is plain wrong: It treats the URL as text string. Thus
>>> it implements it precisely the way the WHATWG blog once ridiculed the
>>> @longdesc usage for.  See this bug:
>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16268
>> 
>> If that is indeed the case, then all those people that have put
>> hyperlinks into the @longdesc attribute have ended up with non-usable
>> longdesc values in IE. @longdesc is therefore not usable for the
>> purposes that we intend it to be used for, since it is not implemented
>> compatibly across browsers.
>> 
>> This to me is a very strong argument to move on to a new attribute so
>> we can start on a clean slate for all relevant elements with well
>> defined implementation details.
> 
> Poppycock!
> 
> The problem is that nobody is actually testing or verifying what is going on
> here, but instead rushing to ill-formed conclusions based on unsubstantiated
> data.
> 
> I just tested a page with an image with @longdesc in IE8 on Windows XP using
> JAWs (13), and can (re)confirm that JAWS both announces the fact that a
> longer description exists, and to access it press "Enter". This is a
> repeatable, verifiable test that anyone who cares to can replicate.
> 
> So what is being reported to the AAPI is immaterial - it could very well
> tell the API that it smells like strawberries for all it matters, as the
> consuming tools that are doing something useful with @longdesc today do not
> access information about this attribute from the AAPI, but rather directly
> from the DOM.
> 
> The value exists, is being delivered to the end users, and is more proof
> that the attribute is both supported and useful today.
> 
> What we need, and what we lack natively from the browsers, is the 3 basic
> functions I outlined months ago. They are:
> 
> * Discoverability
> * The ability to proceed to learn more (consume the content referenced by
> @longdesc) or choose to skip over it
> * The need to support HTML rich content (Headings, lists, tables, links,
> etc.)
> 
> In the tools that support @longdesc, they do deliver on all 3 requirements,
> whereas today the Accessibility APIs have no mechanism in place to deliver
> the second and third functions: the AAPI can express that a thing is a thing
> (discoverability, via role and state), but the key other requirement of
> user-choice is a scripted-like function that the APIs currently cannot
> handle, because there is NOTHING in the Accessibility APIs that deliver
> these functions: both the APIs and ARIA were crafted to allow the ability to
> express widget function roles and states (sliders, buttons, etc.) *when they
> are scripted* and not to magically solve all accessibility problems.
> Additionally, "hiding" the longer text description using an ARIA mechanism
> *does* break the requirement for HTML rich content, as content not rendered
> on screen *is* processed by the APIs as string text today.
> 
> The real problem is not how we express the functionality in code (@longdesc,
> aria-describedat, @shiny_new_attribute) but where we are getting support for
> the users. Today, that support sits with some (not all) screen readers (via
> @longdesc), and generally not with the browsers. 
> 
> JF
>

Received on Friday, 9 March 2012 07:19:36 UTC