Re: Longdesc change proposal update

On Sun, May 8, 2011 at 2:20 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
>> 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 only reason for having @longdesc in the spec is for providing
long text alternatives that serve an equivalent purpose to images.
W3C is looking at other features (microdata, RDFa) that could
be used to link to other data about images using hidden metadata
(and of course image formats themselves may include this data).

Granted in practice long text alternatives might include other
information about the information that isn't required to serve
an equivalent purpose. But I think it might be a mistake to cloud
the meaning of long text alternative.

>>> 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?

<button><img="pencil.jpg" alt="a yellow pencil with a red eraser on
top"></button> is bad because it describes the content of the image but
not the meaning.

<button><img="pencil.png" alt="Edit"></button> is good because it
describes the meaning of the image, even though it doesn't describe
the content.

>> 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"?

"may" is a special word in the spec, as it implies a conformance
suggestion:

http://dev.w3.org/html5/spec/infrastructure.html#conformance-requirements

> There is no "must" in there on purpose, since I don't think HTML prescribes
> anything for a11y technology.

Yep, it lays down requirements for user agents in general.

>>> 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.

Compare how @alt replaces images when images are disabled.

See the rendering proposal, at "Upon activating the icon or button the
image could disclose the description in addition to the image or it
could replace the image with the description" (a screenshot is
included):

http://www.d.umn.edu/~lcarlson/research/ld-rendering.html

See also Dirk Ginader's JQuery implementation:

https://github.com/ginader/Accessible-Longdesc

> Is that something that is done by AT?

User agents of any sort.

> A requirement by HTML?

An example implementation of a rendering expectation.

> Also, I don't understand how UAs opt out of the normal rendering part
> of HTML5?

See the introduction at http://dev.w3.org/html5/spec/rendering.html#rendering

> Are these a11y specific things?

What are you referring to by "these", sorry?

>>> 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.

Interesting. I see what you mean:

"Even when the [controls] attribute is absent, however, user agents may provide
controls to affect playback of the media resource (e.g. play, pause, seeking,
and volume controls), but such features should not interfere with the page's
normal rendering. For example, such features could be exposed in the media
element's context menu."

http://dev.w3.org/html5/spec/video.html

Dunno what "normal rendering" is supposed to mean here; this does seem
to mix in rendering expectations that belong in the rendering section:

http://dev.w3.org/html5/spec/rendering.html#embedded-content-2

>> 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.

Yes.

> I'm almost reluctant to have more than one default method.

Why?

> The context menu approach seems the simplest and most effective

  * Forces keyboard users to use caret navigation.
  * I suspect it fairly painful for switch users to use.

> , 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.

Who are "a11y users"?

> 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.

I don't object to that, as long as it's changed to make clear that user
agents should provide access to the long text alternative, not
necessarily access to a link to it.

In general, one could make the argument that rendering expectations
and suggestions should be sprinkled throughout the spec rather than
in a dedicated section, but in general that's not what the current
spec does.

--
Benjamin Hawkes-Lewis

Received on Sunday, 8 May 2011 14:32:29 UTC