RE: Drop longdesc, get aria-describedat?

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 06:34:55 UTC