Re: longdesc - beside the box

On Tue, Apr 26, 2011 at 5:10 PM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
>>>> @longdesc is hidden metadata by design;
>>>
>>> The 'Techniques for User Agent Accessibility Guidelines 1.0' from 2002
>>> did not design it as hidden:
>>>
>>> http://www.w3.org/TR/UAAG10-TECHS/guidelines#long-descriptions
>>
>> No popular user agent presents a "forced visual encumberance" for
>> @longdesc, and @longdesc's lack of a "forced visual encumberance"
>> is a major plank in the rationale for making it conforming that
>> has been presented to the WG.
>
> "By design" was your wording - not mine.

UAAG 1.0 Techniques is not the design document for @longdesc, but anyway
I'm mainly talking about the invisible @longdesc that the Change
Proposals to retain @longdesc have advocated.

> And popular user agents which do not implement @longdesc at all, do
> not count when we look at how it @longdesc "by design" operates.

I disagree. The hiddenness of @longdesc in popular GUI browsers is
directly relevant to the request for an invisible long description
mechanism. If @longdesc were not hidden, then it would not be a
suitable tool for authors with strict design requirements excluding
long descriptions.

Indeed, one potential drawback with advocating better @longdesc
discovery is that design requirements might extend to excluding
discovery aids like hover effects. Consider, for example, that designers
regularly seek to remove focus stylings, the IE image toolbar, the
destinction between visited and unvisited links, etc. This factor likely
needs to be worked into the costs/benefits analysis.

> As it turns out, only a single user agent, iCab, has a unobtrusive
> visual indication when there is a @longdesc.

s/unobtrusive visible/hidden but discoverable/

> Many images in need of longdesc will also invite to hover above it to
> see if something "happens" - either because its content looks
> interesting and yet not fully accessible as a image, or for other
> reasons.

My contention is not that making @longdesc more discoverable is bad,
but that merely making it more discoverable does not make it "visible
data" unless you actually make the indicator or the description visible
by default.

> It might even be that most images on the Web are links - which sets
> expectations.

Indeed, which won't be the case for images and long descriptions.

> Nevertheless, testing whether a piece of text or an image
> is a link, is something I often do as a user.

Me too, but that process is symptomatic of bad design. It's like having
to go to a door and having to try pulling or pushing on it to work out
which it requires rather than it being visually obvious from the design
of the door. Don Norman's "The Design of Everyday Things" is a good
discussion of this point.

> An author will know - that's the most important part, that's what keep
> their links updated. Authors as well do not need much more than iCab
> provides in order to keep images with @longdesc updated.

An always-visible long description indicator is less error-prone than one
that you must take action to reveal, and an always-visible long
description is less error-prone still.

How /much/ less error-prone is a central question in demonstrating that
the benefits of an invisible long description mechanism outweigh the
costs.

>>> Wether there by *default* should be visible indicator on the picture
>>> itself - that's a detail that we still need to discuss more.
>>
>> I think the debate about how to handle long descriptions in HTML is
>> mostly about this question of whether we need to provide features
>> dedicated to making them invisible. Much as with table summaries.
>
> It would have helped the debate if more members of the HTMLwg could
> _see_ what we are talking about. For that purpose, I can only recommend
> iCab. :-)

I doubt WG members who have not seen iCab have a hard problem imagining
a cursor change, and I doubt WG members objecting to @longdesc on hidden
metadata grounds regard a cursor change as visible data. I'm also sure
they'd recognize a cursor change as closer to the ideal of visible data
then no GUI discoverability at all.

--
Benjamin Hawkes-Lewis

Received on Tuesday, 26 April 2011 17:23:40 UTC