- From: John Foliot <john@foliot.ca>
- Date: Thu, 8 Mar 2012 22:33:38 -0800
- To: "'Silvia Pfeiffer'" <silviapfeiffer1@gmail.com>, "'Leif Halvard Silli'" <xn--mlform-iua@xn--mlform-iua.no>
- Cc: "'Laura Carlson'" <laura.lee.carlson@gmail.com>, "'Steve Faulkner'" <faulkner.steve@gmail.com>, "'W3C WAI-XTECH'" <wai-xtech@w3.org>, "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>, "'Michael Smith'" <mike@w3.org>, "'Janina Sajka'" <janina@rednote.net>, "'Judy Brewer'" <jbrewer@w3.org>
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