W3C home > Mailing lists > Public > public-html-a11y@w3.org > September 2012

Re: 48-Hour Consensus Call: InstateLongdesc CP Update

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>
Message-ID: <op.wkqwycmsy3oazb@chaals.local>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 16 September 2012 20:39:01 GMT