Re: Longdesc change proposal update

On Sun, May 8, 2011 at 11:23 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
>> 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.

I didn't say it didn't. I'm saying we shouldn't cloud the purpose
of what @longdesc links to, which must be a text alternative
serving an equivalent purpose to the image.

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

Indeed.

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

Yes. The purpose of these examples is to illustrate the difference
between a mere description of an image and a text alternative that
serves an equivalent purpose.

> Even in this case I would
> expect the long description to contain a textual description of the
> content of the page.

Do you mean content of the image?

> Wouldn't you?

No.

> Do you have other examples?

Not off-hand.

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

Yeah - I'm saying it doesn't make sense to use the technical jargon of
conformance here.

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

I don't know what that means.
>
> 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.

No, it's not. It's replacing the image of the chart with a sort of
iframe-like viewport of the same size containing the fragment
referenced by @longdesc.

>> See also Dirk Ginader's JQuery implementation:
>>
>> https://github.com/ginader/Accessible-Longdesc
>
> Browsers aren't going to do that

Seems a bit premature to conclude that.

> and most people that publish a web
> page will not want browser to screw with their layout in this way
> either.

How does it "screw with their layout" any more than replacement
with @alt text?

> I think this will always just be an approach that plugins can
> use and really should not even be mentioned in HTML.

I don't think we should write spec text preventing this
sort of implementation without strong rationale.

>>> I'm almost reluctant to have more than one default method.
>>
>> Why?
>
> Because it will lead to incompatible implementations in different
> browsers.

"Different" is not the same as "incompatible".

In any case, I think baking a UI design for this feature into the spec,
before we've seen any entirely sound implementations in UAs, would
be hubristic. So I think it's better to create the user stories and
leave the options open.

> All browsers should do one thing only so that people can
> rely on this behaviour.

Can you give an example of how relying on one or the other
behavior would break the other behavior?

Later you say "AT can do this". But if it breaks for normal
UAs, it would also break for AT, so we shouldn't be assuming
that!

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

http://en.wikipedia.org/wiki/Switch_access

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

I don't think the rendering section should assume browsers aren't
catering to users with visual impairments in the absence of plugins
or system assistive technology.

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

Nowadays, content is regularly loaded for part of a page on demand
using XHR/JSONP. For example, in a tabview, the user clicks a different
tab, and the content is loaded.

I think saying the author should include the text on the page is a
little like saying the author should include all the content for all
the tabs on the page, rather than using a tabview.

> AT can do this, but I think it's a really bad idea to require this by
> all UAs.

The SHOULD requirement is to provide access. That access could be via a link
that opens a new window/tab. There is no proposed requirement that "all
UAs" (or even the subset of UAs actually implementing the rendering
section) should perform inline replacement. It's just an example of
how to meet the expectation.

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

Again, it's not a requirement, it's an example.

--
Benjamin Hawkes-Lewis

Received on Sunday, 8 May 2011 23:15:03 UTC