- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Wed, 14 Mar 2012 10:43:35 +0000
- To: Léonie Watson <lwatson@nomensa.com>
- Cc: Joshue O Connor <joshue.oconnor@cfit.ie>, Laura Carlson <laura.lee.carlson@gmail.com>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>
On Wed, Mar 14, 2012 at 9:09 AM, Léonie Watson <lwatson@nomensa.com> wrote: > Isn't the basic problem that longdesc is poorly implemented/supported, and that it's unlikely to gain much more traction in the future? The core functionality is the bit that's important (as you say), so wouldn't a new attribute/element/whatever create an opportunity to improve implementation/support? Why? >From an author perspective @longdesc poses the problem that many popular implementations do not expose @longdesc to end-users, so it's not a reliable way of providing long text alternatives that are necessary to understand content. >From a user agent perspective @longdesc poses two problems: 1. It is hard to design a way to make long description links discoverable without altering the default rendering of the page. 2. The web corpus contains a lot of @longdesc values that are not useful to expose to users (the "longdesc lottery"). Minting a new attribute for hidden long description links makes the problem of support worse (since it will have no implementations, to start with) and does not help with the user interface design problem. It also means that existing content that uses @longdesc correctly will remain poorly supported by future user agents. The best we could hope is that authors would misuse the new attribute less than they misused @longdesc. I admit a name change could help here. For example, we could include "link" or "url" or "href" in the name of the attribute to make it clear it is a link. ("aria-describedat" is a terrible name; it's got the meaningless "aria" prefix, it's easy to confuse with "aria-describedby", and it's not clear that it takes a URL as a value rather than an IDREF.) But I think to get really good usage, you need to solve the design problem, so that it's obvious to users that long descriptions are available and it's obvious to authors that they've made long descriptions available (or failed to do so). Then we need to give user agents a consistent message to implement the attribute, accompanied by design recommendations. Finally, once user agents actually implement the attribute, we can advise authors who want to hide long descriptions to use it. Until then, the only advice that will result in widely accessible long descriptions is to provide them using visible content in the page (e.g. an <a> element or a <details> element). My gut feeling is that supporting existing content using @longdesc correctly and backwards compatibility with existing user agents is more important than the reduced error rate of a name change. (If we want to start renaming badly named elements and attributes in HTML, there are other striking candidates like "href" and "address".) The worst case scenario is that we mint a new attribute and we end up exactly where we are with @longdesc in a decade. We should wait for implementations in the user interface of mainstream user agents like Firefox for any new attribute before suggesting it replace @longdesc. The design problem can be solved as easily with @longdesc as a new attribute, there's less work to do to get widespread support, and there's no obstacle to expanding @longdesc to cover <video> etc if we want to do so. If our main rationale for preferring a new attribute is to name things clearly to encourage correct usage, then arguably we should be minting a more explicit name for <video> anyway, such as "transcriptlink". -- Benjamin Hawkes-Lewis
Received on Wednesday, 14 March 2012 10:44:28 UTC