Re: Longdesc change proposal update

On Mon, May 9, 2011 at 12:31 AM, Benjamin Hawkes-Lewis
<bhawkeslewis@googlemail.com> wrote:
> 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).

Yeah, there are different ways of dealing with metadata and making it
available on a (separate) page has been comparably successful, though
of course not machine-readable, which is what microdata and RDFa try
to fix. I'm not saying this is the only way to provide image metadata
- the RDFa and microdata approach is really for machines. This would
allow to also expose it to users.

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

I think it actually makes that separate page a lot more useful. It
would also make it really easy for lots of sites that provide such
pages already to simply extend it to also include a long description
requirement. For example Wikipedia could easily have an additional
entry field for transcribing the content of the image for blind users.

We can, however, require that the @longdesc attribute must point at
the exact fragment on the page that contains the long description for
the screen reader to pick up, thus making it easier for
vision-impaired users to get directly to the point in the page where
the important piece of text sits. Sighted users can always scroll
around on the page to find the other content, too.


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

That's not a use case for longdesc IMHO, since it is really short text
and would thus go into the @alt attribute. Even in this case I would
expect the long description to contain a textual description of the
content of the page. Wouldn't you? Do you have other examples?


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

It is the exact right word for providing something optional:
http://tools.ietf.org/html/rfc2119
"MAY This word, or the adjective "OPTIONAL", mean that an item is
truly optional."


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

I don't expect @longdesc to do the same. The text that longdesc points
to should not be used for inline replacement, that would be a mistake
IMO. The link could be exposed, though, together with the alt text.
The link could even simply sit behind the alt text.

Maybe it's a formulation problem: how about we replace "the page's
normal rendering" with "the page's layout" or something?


> 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

That's, however, not inline text. It's outside the normal flow of the page.


> See also Dirk Ginader's JQuery implementation:
>
> https://github.com/ginader/Accessible-Longdesc

Browsers aren't going to do that and most people that publish a web
page will not want browser to screw with their layout in this way
either. I think this will always just be an approach that plugins can
use and really should not even be mentioned in HTML.


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

OK, it seems "expected" is the word to use for rendering. :-)


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

Because it will lead to incompatible implementations in different
browsers. All browsers should do one thing only so that people can
rely on this behaviour. That plugins and other tools may change or add
additional behaviour is fine, but should not be in the standard.


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

What are "switch users"?


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

Sorry, I meant vision-impaired users here. And it could be done by a
plugin or AT.


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

Oh, I see. I think I fundamentally disagree with that. If that is the
way it is implmented then why wouldn't the page author already include
the text in the page? AT can do this, but I think it's a really bad
idea to require this by all UAs. I don't expect such a requirement
would ever be implemented or  even accepted by page authors. That
surely is a requirement that would be the death of the @longdesc
attribute.

Cheers,
Silvia.

Received on Sunday, 8 May 2011 22:24:41 UTC