- From: Charles McCathie Nevile <chaals@yandex-team.ru>
- Date: Sun, 16 Sep 2012 22:38:26 +0200
- To: "Steve Faulkner" <faulkner.steve@gmail.com>, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
- Cc: "HTML Accessibility Task Force" <public-html-a11y@w3.org>
TL;DR: I think the explanation should be improved, but I can live with it. I don't see a viable alternative to longdesc after more than half a decade of many smart people trying, so I conclude we aren't ready to replace it. detail: For what it is worth, I believe the last two "Authoring requirements", for which consensus is being sought, should be further split and the priority changed as follows: [[[ Backward compatibility: Any solution SHOULD provide a simple method to update content written using HTML5/XHTML1 longdesc, that can be applied by an automated tool. Ease of authoring: Any solution MUST include example guidance to authors, that should be as the existing HTML4 longdesc Maintenance by Tools: Any solution MUST explain how to maintain long descriptions in a Content Management System which reduces pages to components ]]] Implementing longdesc to the average level of current implementations is really very easy, so any solution could say "and by the way implement longdesc for legacy content" and it could be achieved. Implementing it really well is something that has yet to become widespread - JAWS is rather more robust than TellMeMore, but neither are perfect demonstrations, just "ahead of the rest". There is also an author requirement that seems to have been misplaced into the "discoverability" user requirement: [[[ Any solution MUST allow both for the description to be in the same HTML page as the element described, or to be in a separate page. ]]] Come to that the discoverability requirement seems to cover far too much. The requirement as I see it is [[[ Images can have a description (which is not the functional replacement provided by e.g. the alt attribute) "linked" unambiguously, to allow automation of discoverability. ]]] And there is a user requirement that I thought was obvious, but seems to have got lost: [[[ Any solution MUST work with the changes to default presentation common for users with low-vision ]]] (This implies various things. The ability to control the layout of the description, ensuring that it can handle contrast changes and magnification, etc. I don't know if that needs to be spelled out in the requirement, but it needs to be understood as important - it is quite possibly more important for overall accessibility that people with low vision can get the description than it is for people with no vision at all...) I don't think the "forced visual encumbrance" *user* requirement is at all important (although I think the analagous author requirement is critical). All that said, I can live with the existing proposal. Further rationale below: On Sun, 16 Sep 2012 11:47:05 +0200, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > There is obviously a possibility to register bugs on all the browsers > and tools that are doing the wrong thing. Is the likelihood of them > fixing it high? And how long will it take? These are questions that are important. > Might it be faster to introduce something new an untainted? This is indeed a key question. Given the issue has been open for years (I formally raised it on 2012-02-06, 4 1/2 years ago but it has been known much longer), and apparently because of the vehement opposition, from some browser developers among others, we have seen many alternative proposals. The discussion over the last few years has been great. A lot of mental energy has been focused by many very clever people on trying to carefully describe and resolve an accessibility problem which, while only important in a small fraction of pages, can nevertheless make a big difference in the cases where it is relevant. Nothing has been implemented that meets the requirements, while longdesc *has* been implemented in authoring tools and the Opera browser in that time. > That's what I'm asking myself and I don't really have any answers. If there was an alternative that solved the requirements, and would resolve the issue, I originally expected that it would be implemented. The closest candidate was "aria-describedat" or something along those lines - i.e. an attribute that does the same thing with a different name. It didn't happen. While people have held off from supporting longdesc because the issue is open, they haven't done anything very useful instead. Beyond renaming the attribute I haven't seen a proposal that offers a useful replacement, and I consider that a renamed attribute is not an improvement. While I'd ditch a modestly-implemented longdesc for a widely-implemented solution that was only a bit worse, I haven't seen that on offer - both the proposal that is near enough (and I too have been trying to think of an improvement for years), and the will to actually implement, are apparently missing. I conclude that while implementation uptake has been very slow, it exists and shows that longdesc implementation is feasible and meets the requirements. Therefore dropping longdesc in the absence of a workable alternative is at best premature and probably harmful, and at worst an unequivocal step backwards for accessibility. Cheers Chaals > Silvia. > > > On Sun, Sep 16, 2012 at 7:31 PM, Steve Faulkner > <faulkner.steve@gmail.com> wrote: >> Hi all, >> >> I abstain from this CFC. >> >> I have made my antipathy towards longdesc clear in the past, the >> majority ( i think) of the taskforce can live with longdesc back in >> the spec or not in the spec. I could live with it back in the spec, I >> could live with it not in the spec. >> >> There are substandard features in the spec, there are features that >> are not yet supported, there are features that not yet accessibility >> supported. if longdesc is put back in the spec i would consider it >> appropriate to have a warning about its use. I would consider it a >> feature at risk CR wise unless its interoperable support in browsers >> is improved. I would consider it a failed feature unless it is >> meaningfully supported across the major browsers and AT. i.e. if >> browsers such as IE and webkit based browsers, and AT such as >> voiceover and NVDA do not implement meaningfull support for it. >> >> regards >> STeveF >> >> On 13 September 2012 18:10, Janina Sajka <janina@rednote.net> wrote: >>> Colleagues: >>> >>> The HTML-A11Y Task Force has twice resolved support for the >>> InstateLongdesc >>> Change Proposal on Issue-30 Longdesc reconsideration, most recently as >>> logged at: >>> >>> http://lists.w3.org/Archives/Public/public-html-a11y/2011May/0399.html >>> http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc >>> >>> As we expect reconsideration of the Issue-30 decision on longdesc will >>> be taken up by the HTML-WG soon, the Task Force Text Subteam has >>> provided a narrative wrapper for this CP which is intended to serve as >>> concise orientation at the top level of >>> the CP, leaving detailed evidence and argument to subpages. >>> >>> http://www.w3.org/html/wg/wiki/Talk:ChangeProposals/InstateLongdesc >>> >>> The Task Force teleconference on 13 September reviewed this approach >>> for >>> the second time and confirmed no objections to it: >>> >>> http://www.w3.org/2012/09/13-html-a11y-minutes.html#item02 >>> >>> As was noted during the teleconference, the Instatelongdesc CP had this >>> kind of top level presentation until the evidence in the CP became so >>> extensive that it seemed prudent to reformat the CP using subpages. >>> >>> The discussion page to review is at: >>> >>> http://www.w3.org/html/wg/wiki/Talk:ChangeProposals/InstateLongdesc >>> >>> If you have objections, comments, or proposed edits, please respond by >>> replying to this message no later than 12:00 PM (Noon), Boston Time, on >>> Tuesday 18 September. This is 16:00 UTC. >>> >>> All Task Force participants are also invited to attend the Task Force >>> Text Subteam teleconference at 1:00 PM Boston Time Tuesday, (17:00 >>> UTC), >>> when all comments received will be considered and the orientation page >>> finalized. >>> >>> The Text Subteam uses Zakim channel 2119#; and IRC channel #text. An >>> agenda will be published to the Task Force list before this >>> teleconference as usual. >>> >>> >>> -- >>> >>> Janina Sajka, Phone: +1.443.300.2200 >>> sip:janina@asterisk.rednote.net >>> Email: janina@rednote.net >>> >>> The Linux Foundation >>> Chair, Open Accessibility: http://a11y.org >>> >>> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) >>> Chair, Protocols & Formats http://www.w3.org/wai/pf >>> Indie UI http://www.w3.org/WAI/IndieUI/ >>> >>> >> >> >> >> -- >> with regards >> >> Steve Faulkner >> Technical Director - TPG >> >> www.paciellogroup.com | www.HTML5accessibility.com | >> www.twitter.com/stevefaulkner >> HTML5: Techniques for providing useful text alternatives - >> dev.w3.org/html5/alt-techniques/ >> Web Accessibility Toolbar - >> www.paciellogroup.com/resources/wat-ie-about.html >> > -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex chaals@yandex-team.ru Find more at http://yandex.com
Received on Sunday, 16 September 2012 20:39:00 UTC