- From: John Foliot <john@foliot.ca>
- Date: Wed, 28 Mar 2012 17:05:23 -0400
- To: david bolter <david.bolter@gmail.com>
- Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Charles McCathieNevile <chaals@opera.com>, Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>, Richard Schwerdtfeger <schwer@us.ibm.com>, faulkner.steve@gmail.com, jbrewer@w3.org, George Kerscher <kerscher@montana.com>, laura.lee.carlson@gmail.com, mike@w3.org, public-html-a11y@w3.org, w3c-wai-pf@w3.org, W3C WAI-XTECH <wai-xtech@w3.org>
Quoting david bolter <david.bolter@gmail.com>: > Hi all, > > If there is increased need for media and visually complex html to have a > URL to something like a transcript or a description, isn't html ready for a > straight-up @hasurl which a browser would expose to everyone? > Hi David, Good to see you comment here. Without wanting to be confrontational, what in your mind would be different between @hasurl and @longdesc outside of the name? There has been some discussion about extending "the_native_HTML_thing_that_takes_a_URL_and_points_to_additional_text_description" so that it might be applied to a broader range of elements beyond <img> (which I think has broad support in principle), which would be one of the goals and benefits of an aria-attribute solution, although there is no reason why a new native HTML attribute (@hasurl) or even an existing HTML attribute (@longdesc) could not also do the same. To many of us, the key is the last part of your question: "...which a browser would expose to everyone". Without browser support, any benefit derived must be gleaned directly by 3rd party agents. This is what JAWs does today with @longdesc, and/but this is also why NVDA does not support @longdesc: both Jamie and Mick confirmed to me at CSUN '11 that they didn't want to have to create a new user-interaction, but wanted instead to map to an existing browser interaction method. If Firefox had a means for all users to discover and act on the longer textual descriptions, then NVDA could map to *that* and NVDA users would benefit as equally as sighted users. I have long maintained (personally) that "what" we call it is less important than the functionality we get from the "thing" that we are naming. We could call it @duck_soup and I would be happy if we got the functionality we required from the attribute, which is: a) Discoverability, b) Choice in consuming or not consuming, c) supports rich HTML markup (including tab-able elements such as <a>, <li> and <td>). The benefits of retaining @longdesc include backwards compatibility in both existing content, authoring tool-chains and consuming tools (that support @longdesc today). Your question pre-supposes that the need *does* exist, which is something that some of us have maintained for quite some time now (and was the reason why @longdesc was added to HTML 4 way-back-when). The long-known problem is that back then, there was no guidance on how it should work in browsers, and back then without clear guidance and the race that was "the original browser wars" @longdesc got left on the shelf, an important concept in need of love, but neglected. The benefits of introducing an equivalent aria-attribute is that it becomes language agnostic, and the same functionality can be extended to other mark-up languages. Once spec'ed and implemented in user-agents it could also pave the way to retire older, less robust means of achieving the end goal. As well, introducing something "new" (even if it is really an old concept) might see better take-up by the latest generation of web developers who never really learned about @longdesc, or how to use it, because testing it was complicated - you needed to have JAWs or some other @longdesc consuming tool. HOWEVER we don't have a spec yet, and we certainly don't have support yet, so this would be a "in the future, moving forward" exercise (which is how I believe the ARIA-WG and PFWG envision it today). Not ready for prime time, but "in development". What benefit do you see deriving from introducing a new, native HTML5 attribute that would outweigh either of the above? Honest and genuine question. Thank in advance for your thoughts. JF
Received on Wednesday, 28 March 2012 21:06:11 UTC