Re: Formal Objection to advancing the HTML Image Description document along the REC track

Hi Roy,

Thank you for the thoughtful technical comments. Reading your message,
it seems we are closer to agreement than might be evident at first
glance. We both say that there may be ‘long tail’ (your term) uses or
‘curated or historical environments’ (our terms) where longdesc is used.
Unfortunately, the scope of the extension spec as written is not limited
to the specialized cases you envision; instead, it positions longdesc as
a general accessibility feature for "content that is designed with the
Web as its sole user interface”. Part of our objection is based on this
over-broad applicability. The specification does not focus on, limit
longdesc to, or even mention, the cases and environments that you and we
cite.

Our recommendations closely match, as well: you suggest that longdesc be
documented but deprecated ("the proper way to deprecate a feature is to
define it as part of the language and warn against its future use” [1])
and one of our proposed remedies is that it be clearly stated that
longdesc SHOULD NOT be used (i.e. deprecated) in its documentation.

Your message talks about the extent to which pages can (or cannot) be
re-designed to aid accessibility. We presume that you mean visual
appearance here, as obviously most accessibility information directly
associated with a single image result would be reflected in edits to the
markup.[2] Unfortunately, your presumption that addition of longdesc
to an image will not result in changes to visual appearance:

> The fact that longdesc is not displayed by visual user agents is
> exactly why they are using it.

is not supported by the extension spec’s UA requirements:

> If the longdesc value is valid, User agents MUST make the link
> available to all users through the regular user interface(s).
> 
> If the longdesc value is valid, User agents MUST expose the link to
> relevant APIs, especially accessibility-oriented APIs.
> 
> User agents SHOULD enable users to discover when images in a page
> contain a long description.

It would appear to be entirely conforming for a user-agent to put an
icon or text link near, or over, the image, resulting in a significant
change to the visible rendering. In contrast, several of the techniques
we describe as alternatives clearly do not cause visible change.

This discussion raises a whole area which we did not discuss in our
Formal Objection, as we thought the objection quite long enough already:
the documentation is inadequate, not only for the user-agent (as
discussed above), but also for authoring. Here, for example, are the
extension spec’s requirements for the attribute’s value:

> The longdesc attribute must contain a valid non-empty URL potentially
> surrounded by spaces. The URL is a hyperlink to a description of the
> image that the parent img element represents.
> 
> The linked description should be in a broadly accessible format.

It seems to be entirely conforming, and not even advised against, for
the longdesc of an image to link to another inaccessible image, or to an
audio or video resource that could only be perceived in a single
modality. In other words, though both examples are conforming with the
longdesc specification, neither example is perceivable [WCAG 2.0
Principle 1] or understandable [WCAG 2.0 Principle 3] by a deaf-blind
user on a braille display. We presume that this doesn’t meet the intent
of the attribute (to provide a description to those who cannot see
images, still or moving). It is nowhere stated that the long description
should be perceivable in multiple modalities, and there is nothing
corresponding to the careful exposition of when and how to use the ‘alt’
attribute in HTML5 [3].

If there were not so many other, larger problems with longdesc, we feel
that these specification problems alone should hold up progression along
the Recommendation track.


Ted

1. http://lists.w3.org/Archives/Public/public-html/2010Aug/0131.html
2. If it’s a hard requirement to not change the markup at all, a
   self-describing SVG with an <svg:image> element pointing to the
   original raster image can be used. If it isn’t a hard requirement,
   then several of the other techniques we described in our objection
   may be applied.
3. http://www.w3.org/TR/html5/embedded-content-0.html#alt

Received on Monday, 25 August 2014 21:32:48 UTC