W3C home > Mailing lists > Public > public-html-a11y@w3.org > May 2011

Re: Longdesc change proposal update

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sun, 8 May 2011 23:20:13 +1000
Message-ID: <BANLkTimmb-+NxGJEv_tPUUPmY-1KAuDHhQ@mail.gmail.com>
To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Cc: Laura Carlson <laura.lee.carlson@gmail.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>
On Sun, May 8, 2011 at 10:29 PM, Benjamin Hawkes-Lewis
<bhawkeslewis@googlemail.com> wrote:
> On Sun, May 8, 2011 at 12:56 PM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>> Hmm, that text could do with a bit of technical clean-up. May I
>> suggest some revised wording? How about something like the following?
>>
>> ===
>> The longdesc attribute may be present and contains a valid non-empty
>
> I think it's better to use formulation "must be" rather than "contains",
> to be clear we're talking about an authoring conformance requirement.
>
> cf. @cite at http://dev.w3.org/html5/spec/grouping-content.html#the-blockquote-element

I based it on other language for URLs (e.g. the @src attribute), but I
am not fussed.


>> URL potentially surrounded by spaces referencing a Web resource that
>> contains detailed information about the image that the Web page author
>> wants to make available, but not in the main flow of the Web page.
>
> A text alternative is not primarily "detailed information about an image",
> but text serving an equivalent purpose.
>
> In particular, we want to avoid @longdesc being misused (as on Wikipedia) to
> refer to a page of metadata about the image that does not include text serving
> an equivalent purpose.
>
> This is why our draft text follows WCAG2 in using the phrase "text alternative":
>
> http://www.w3.org/TR/WCAG20/#text-equiv

I wonder if that is actually a misuse. Sometimes you do have more
information about the image, but it may not be necessary to provide a
longer description. For example if it's a company logo, but it's just
simple text maybe in a color. However, there is a lengthy story behind
how that color was chosen etc. Then it's not just a11y content, but
still serves a similar purpose. The wikipedia page, however, is indeed
poor for a11y, which is why in the text that I suggested I pointed out
a11y in particular. The language could be a bit stronger though.


>> The longdesc resource will in particular contain a textual description of the
>> content of the image
>
> "A textual description of the content of the image" is not necessarily
> text serving an equivalent purpose.

I fail to understand the difference. I prefer plain language that
helps people decide what to write. If there are other purposes than
explaining what the image shows then it would be better to list them.
What other purposes do you have on mind?


>> that accessibility technology will make available to vision-impaired users.
>
> In line with WCAG2, we should present vision-impaired users as one of many
> groups who can use text alternatives, not the only one:
>
> http://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv.html
>
> The usual expansion of "AT" is "assistive technology"; this is the phrase
> ARIA uses for example.

Feel free to reformulate this appropriately. Hopefully it can be done
in a way such that it is still comprehensible.

> I'm not sure what "will" is doing here. Is it supposed to be a conformance
> requirement of some sort? AT is not currently a distinct HTML5
> conformance class.

Maybe replace "will" with "is expected to" or "may"? There is no
"must" in there on purpose, since I don't think HTML prescribes
anything for a11y technology.


>> The user agent should expose the longdesc link to the user, but it
>> should not interfere with the page's normal rendering.
>
> This formulation does not seem compatible within inline replacement,
> or with user agents opting out of the "normal rendering" part of HTML5.

I don't understand inline replacement. Is that something that is done
by AT? Expected from AT? A requirement by HTML? Also, I don't
understand how UAs opt out of the normal rendering part of HTML5? Are
these a11y specific things?


>> For example, it could be exposed in the image element's context menu.
>
> This sort of implementation suggestion is best reserved for the
> rendering section, as with @cite.

I would think it makes a lot of sense to have that here plain in sight
together with the element. Where video is described and @controls
defined, such rendering suggestions are also mentioned directly there.
Ultimately, I'm not fussed abut this though.


> Note the rendering text we've drafted:
>
> http://www.d.umn.edu/~lcarlson/research/ld-rendering.html

There's a lot of different alternatives there. I'm almost reluctant to
have more than one default method. The context menu approach seems the
simplest and most effective, while e.g. the additional menu approach
seems to make more sense for a11y users than for everyone, so would be
more useful just as a plugin. Why not keep the simple sentence in the
main part as I had it and in addition also keep this as
alternative/additional rendering options in the rendering section.


>> Note: The longdesc page can be regarded as the information page of the
>> image. It should in particular contain a detailed description of the
>> content of the image such that vision-impaired users can also
>> understand what is presented in the image. It may contain structured
>> markup, such as a table to explain a complex graphic like a statistics
>> chart. It can also contain the image itself, links back to all the
>> pages that contain that image, and metadata about the image such as
>> license and copyright information.
>
> This note does not make it clear that in this case the @longdesc attribute
> should point to the "detailed description" fragment not the surrounding
> paraphernalia.

See my other email. I do wonder what is acceptable to a11y users there.

Silvia.
Received on Sunday, 8 May 2011 13:21:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:38 GMT