- From: Charles McCathie Nevile <chaals@yandex-team.ru>
- Date: Tue, 27 Nov 2012 16:50:08 +0400
- To: "Steve Faulkner" <faulkner.steve@gmail.com>, "James Craig" <jcraig@apple.com>
- Cc: "HTML Accessibility Task Force" <public-html-a11y@w3.org>
Hi James, chair hat off. TL;DR: Yes, it is possible to do things better. But all such proposals have proven to be vapourware, or not actually better either through design flaws or because they failed to be as versatile as longdesc. longdesc is actually real and moving the spec forward seems valuable, although I would be perfectly content to see some better alternative overtake it in the market. On Mon, 26 Nov 2012 22:51:44 +0400, James Craig <jcraig@apple.com> wrote: > On Nov 20, 2012, at 4:15 AM, Steve Faulkner <faulkner.steve@gmail.com> > wrote: > >> We are calling for consensus on the HTML5 Image Description Extension >> specification [1] We have asked for and received feedback on the >> specification from task force members. ... >> http://dvcs.w3.org/hg/html-proposals/raw-file/4893614e89f2/longdesc1/longdesc.html > > I do not currently plan to make any formal objection, but I need to go > on record again as stating that I do not support longdesc, for the > following reasons. > > 1. Longdesc uses an approach that is sometimes referred to as "separate > but equal," meaning the alternative content is not stored with the media > or the linking document, This is not true. Please see the first example in the specification, and the final use case, which explicitly covers this case. You might also find the discussion in the thread "longdesc as #id" illuminating - it shows that most early implementors of longdesc considered content in the page an obvious use case. And anecdotally, among the hand-trawled collection of examples in the wild (warning - some of these are things people might find confronting - if you don't like the F-word, don't follow the link) are some that use this pattern: http://www.d.umn.edu/~lcarlson/research/ld.html#onpageanchor A "nice" subset: http://bembelterror.de/frankfurt/bday-2007 http://www.w3.org/WAI/PF/HTML/consensus-procedures and the test cases for a 2005-2008 implementation as a firefox extension http://www.splintered.co.uk/experiments/archives/firefox_longdesc_extension/#samepage > which IMO is a flawed design pattern, as these external resources often > become stale and outdated, remaining separate but rarely equal. Yes. But the issue of how well people maintain content is something we have limited ability to resolve. Were there a better alternative on offer I might find this argument less unconvincing. > 2. Longdesc is frequently championed as needed by book publishers > despite the lack of evidence that any major publisher implements > longdesc in its catalogs. The single request quoted from the publishers > association did not actually request retention of longdesc. I have no special comment on this - it isn't one of the use cases which lead to requirements, just a generic functionality request. > It requested ~"longdesc or an equivalent feature" and since many of > these equivalent features already exist in HTML 5 It is possible, with various combinations of approach, to cover various combinations of the use cases. Much as I like the approach of the picture element, it fails to handle the important use case of content which is not on the same page. A development environment where there is thoughtful management of resources is typical in the sort of high-cost situations where people will spend the money to develop descriptions in the first place, and alternatives are the same design without the benefit of a simple standardised mechanism. > I'd prefer to leave the poorly-implemented, and IMO poorly-designed, > longdesc marked as obsolete. Were there an effective replacement, I might agree with your conclusion, although I do not agree that it is poorly designed. Indeed, 7 years of argument from people who say it is poorly designed but offer something with the same design (the major improvement offered is a more generalised application of the design, the major different design only deals with more restricted use cases), but a different name confirms my belief that the design is pretty good at solving the requirements which follow from the use cases. > I would be fine having longdesc as "obsolete but conforming" rather than > non-conforming, which would result in validators issuing a warning > rather than an error. Frankly, I'm all in favour of that - it is why I restricted the existing proposal to what has been implemented, basically for the img element. But it presupposes a better option, and "the same design with a new attribute name" doesn't strike me as an obvious improvement. > 3. Longdesc is under-designed and under-specified with regards to how > the URL is accessed in contexts other than standard web browsers. What > happens when a longdesc URL is activated in a web view in an app context > that does not expect the need for "back" buttons or tabs? Whatever happens with any linked content. This is not a new issue - the same problems occurred in the WAP walled gardens of the late 1990's, and people learned that a back button was not a bad geenric functionality. People who build apps with specific goals not to be an open web browser have the benefit of a decade and a bit of experience in dealing with this problem. One possible strategy is to open the description on deamnd in a "lightbox" - although there are other approaches and which one is chosen depends on the use case. > What happens when a longdesc URL is activated in the context of a e-book > such as EPUB, where the long description content is not available "on > the Web" or within the normal reading flow of the book? The same thing that happens to any linked content which is developed in this context. It doesn't take a genius to use one of the 3 or 4 existing approaches to collecting resources required for offline use (widgets, JSON/zip packaging, appcache, authoring for the offline case, MHTML, "save with linked resources"...) that have been implemented repeatedly and successfully for years. When longdesc was being designed in the late 90s, I was using commercially available software like webgrinder (because I was too lazy to write my own) to distribute millions of CD-ROM versions of content that had been designed for the open web for places like Vietnam and outback Australia where connecting to the real web wasn't an option. This has been succesfully dealt with by all six browsers I have as quick-launching applications, and a great deal of other software. People working in this context have several different models to copy, most of them many years old. > These questions represent holes in the specification for a feature that > was designed as a stop-gap measure more than a decade ago Is that an accurate representation of the design effort? My understanding is that the feature was designed to fulfil known needs. My experience is that although it is a difficult problem to solve, the solution they came up with does a reasonably good job compared to alternatives. > and has not been updated to resolved problems with modern content that > are better > addressed by other existing features like the IFRAME element, the > FIGURE element, an authored Shadow DOM, or embedded accessibility such > as SVG+ARIA. I spent a significant amount of effort arguing the case for the modern design of ARIA that enabled it to be easily integrated with both HTML5 and SVG. Aaron Leventhal, Anne van Kesteren, Simon Pieters, Anders Markussen, and others I have unfortunately forgotten came up with the design, I just managed to convince people like the TAG that it made sense. I worked hard on shadow DOMs. I believe that these approaches could potentially offer something better than longdesc. But their deployment and implementation* half a decade later make longdesc look like a resounding market success and a de facto standard already - which makes me wonder why it isn't formalised, and led me to propose this extension. cheers Chaals I note the outstanding work Apple shipped for SVG accessibility, only a decade after "Accessibility features of SVG" suggested it, as one of the leading efforts. If those are the timescales we are dealing with, let's ship the longdesc spec and get on with making the web better than that. -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex chaals@yandex-team.ru Find more at http://yandex.com
Received on Tuesday, 27 November 2012 12:50:46 UTC