Re: Longdesc change proposal update

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

I'm trying to turn the way in which people look at @longdesc around
from being a burden that is only useful to a small number of people to
one that is useful to everyone. Therefore, it makes sense to encourage
people to add other information to that page and to encourage browser
vendors to add a link to the context menu. Nothing in the normative
text has to say anything about other purposes. This can all be kept in
a non-normative note. But it will make a world of a difference to
uptake of the attribute IMHO.


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

Leif had the same issue. I'm happy with that, too.


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

OK, that makes sense for @alt. But does it for @longdesc?


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

Ups, yes. :-)


>> Wouldn't you?
>
> No.
>
>> Do you have other examples?
>
> Not off-hand.

None of the examples that Laura has collected has something like that
either. I'll wager that no such examples exist. Happy to be proven
wrong though!


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

OK. "expected to" is is then. :-)


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

"Inline" to me indicates that it is made part of the flow of the page.
Only one of the examples on the rendering page does that (the jquery
plugin) and it does it in such a way that Web page authors have to
actively want to have that change applied to their page layout.


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

Ah yes, and the original flow gets an icon or button image. That's
definitely not something that the Web browsers are going to implement,
because that changes the layout and rendering that the Web page
authors have designed. Such an approach is ok for AT to do or for a
plugin, but never for the UA.


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

Not really. I have created many Web sites and if the browsers suddenly
decided. To render my Web pages differently because I had provided a
@longdesc, I would be furious. So would everyone else, in particular
the corporate Web publishers. The first thing I would do is go through
all my Websites and remove all longdesc attributes.


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


That plugin adds an icon to every image on a page. @alt text doesn't
do that: it @alt text is there for occasions where images are not
rendered or for AT, but not for common rendering. If the icon appeared
when I had images turned off, that would be ok.


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

None of the rendering prevents any kind of implementation. In fact,
the spec will never prescribe to UAs how to render things - it only
ever provides recommendations. I am just saying that one
recommendation only is sufficient and that recommendation should be
context menu IMHO.


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

It's not productive to have 4 browsers implement 4 different means of
exposing the longdesc attribute. That will just lead to more
fragmentation and again less people making use of the attribute. And
it leads to poor usability because people cannot expect one means
where to find the information. All of this works against us.


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

If one browser implements the context menu link to the long
description and another implements the drop-down menu in the browser
toolbar, then I as a user cannot get used to one way of finding the
longdesc link, but have to learn two different way depending on which
browser I am using. Same problem as when one browser would implement
copy and paste with Ctrl-c /Ctrl-v and another with Meta-m / Meta-p -
it confuses users and it confuses developers even more who have to
make sure that their pages work in all browsers.


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

Differences in visual display wouldn't break for different screen
readers. They would rely on the markup that is provided, which would
not be different. That's all I meant.


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

All of the proposed solutions share the problem that the access for
sighted users requires use of a mouse or keyboard shortcuts in one way
shape or form. I don't think this is a problem that can be overcome.


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

The HTML spec is for the development of UAs. It doesn't specify the
functionality that AT or plugins should provide, FAIK.


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

Are we arguing past each other? Maybe we are agreeing that the
longdesc attribute on the image should be made available as a URL,
which AT can use to read out the long image description on demand?
Whether the long description is already loaded into the browser
because it's on the same page, or has to be retrieved by following the
link is up to the situation in which the browser finds it and really
doesn't need to be specified.


Silvia.

Received on Monday, 9 May 2011 05:10:06 UTC