Re: 48-Hour Consensus Call: ARIA-DescribedAT & Longdesc

On Mon, 02 Apr 2012 03:33:58 +0200, Matthew Turvey <mcturvey@gmail.com>
wrote:

> On 1 April 2012 14:53, Geoff Freed <geoff_freed@wgbh.org> wrote:
[snip lots of stuff that has been said many times before...]
>> I recently spent two days with a major international textbook publisher,
>> training developers and authors there in Web-accessibility techniques.   
>> At least half of each session I conducted was consumed with approaches
>> to describing complex STEM images.  This publisher, and many others in
>> the industry, wants to convey image descriptions to users that need  
>> them (also see https://www.w3.org/Bugs/Public/show_bug.cgi?id=13461).  
>> Believe
>> it or not, visual design still matters and so using visible links and/or
>> using visible descriptions are not options.  longdesc *is* the only
>> option at this point, and it's a workable option (see above) even though
>> it's unevenly supported and targets a single, specific audience. At
>> least, it's workable until a better solution comes along.
>
> Longdesc is obviously not the only option at this point,

A truism.

> or even the best option.

I don't think you have established this.

> Using a normal link on the image doesn't affect the visual design in any
> way

This seems to be key to your argument. And yet it flies in the face of all
that I understand about an explicit visual link on the page. It also
reduces the question of user experience to visual design - which I don't
think you did, I think it has run around in that rut for a while. Visual
design is clearly *part* of user experience, and user experience clearly
matters to many many parts of the web industry (we collectively pay a huge
amount of money for it).

Still, I'd like to understand why you think this claim makes sense.

My thinking process:

You have to make something a linked item. It cannot be something, nor part
of something, that was already a link.
That thing enters into a navigation cycle (which affects the workflow/UX,
although the visual impact can be zero).

In an ideal case, the UX impact is trivial. In many real cases, where the
image is linked to something (like a larger version), this isn't true.

Even in this situation, you haven't established a linkage between the
image and the description - something that most longdesc implementations
(for all that they range from not very good to appalling/non-existent)
already achieve. This may seem trivial, except that it matters in making
the workflow efficient. This has a real impact on accessibility, because
the time taken to do a task is important in reality, and the different
user interaction of screen reader users and screen magnifier users changes
the way to offer equal (or best-case) efficiency. Allowing people to
quickly scan links, headers and so on is somewhat equivalent to providing
a reasonable structure for visual scanning.

> and is a far better solution because it works
> for everyone right now, without requiring browser add-ons, software
> upgrades, user training etc.

*EVERYTHING* requires user training. Including identifying and clicking
links. (Try teaching 80-year-olds to use their first computer).

The audience who *need* description of images because they can't see them
already require extra software or specialist user training on software
that supports their needs. Without this, there is no accessibility for
people with visual impairments of various kinds.

> It's unclear why any publisher would even consider using an
> "accessibility" technique that makes the long description completely
> inaccessible to most users including at least some SR users, when a
> simpler, POUR technique that makes the long description accessible to
> everyone is available.

Possibly, but it is clear that despite poor implementation, the fact that
a real proportion of the audience who *needs* this stuff don't really
understand how it works, and that it is expensive, thoughtful publishers
with years of experience in making stuff accessible for real world use
cases have decided that the expense of using longdesc is justified.

> Whatever happens with HTML5, longdesc is not a
> viable option at the current time: it completely locks out most users.

Actually, that isn't true. For the situation where you are pointing to
something that is already on the page, *most* users are already pretty
well-served. Longdesc enhances that for a handful of people who are
normally locked out. For the situation where you link to something
external, longdesc (especially in current implementations) is not always
the best available solution, although I disagree with you that it is never
so.

So the real question should turn on whether longdesc does more harm than
good. I don't think you've established that it does.

Your argument as I understand it rests on the premise that everybody
should expect to interact in the same ways with content. This goes against
the reality that people who cannot see but can hear interact with their
entire universe differently to (for example) people who can see but cannot
hear, while people who can see and hear to a high level of acuity interact
differently again. (That's before you look at notions of how much people
see and hear, which have further impact sometimes in ways which do not
exist when looking at the simple binary questions).

It also rests on the argument that a normal link provides the
functionality. I don't think so for two reasons - one is that it doesn't
provide the same UX, interfering with the site developer's intentions in
ways that longdesc doesn't, and the other is the issue of making it clear
that such a link is in fact a description (again, something longdesc
already does).

cheers

-- 
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
       je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Tuesday, 3 April 2012 13:50:51 UTC