W3C home > Mailing lists > Public > public-html@w3.org > January 2012

Re: Using an image map for long described image links [Was: Revert Request]

From: Matthew Turvey <mcturvey@gmail.com>
Date: Tue, 31 Jan 2012 10:05:30 +0000
Message-ID: <CAFp5+Aq5+AYqWepD3qeDxnn7iKixvRV01JFhFd_tYo0miquuZQ@mail.gmail.com>
To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Cc: John Foliot <john@foliot.ca>, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Laura Carlson <laura.lee.carlson@gmail.com>, Sam Ruby <rubys@intertwingly.net>, Paul Cotton <Paul.Cotton@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, HTML WG <public-html@w3.org>
On 30 January 2012 21:40, Benjamin Hawkes-Lewis
<bhawkeslewis@googlemail.com> wrote:
> On Sun, Jan 29, 2012 at 6:15 PM, Matthew Turvey <mcturvey@gmail.com> wrote:
>> On 28 January 2012 04:57, John Foliot <john@foliot.ca> wrote:
> [snip]
>>>  * Browsers must address the discoverability problem for all users.
>>>  * Browsers must natively support the user-choice of consuming or not
>>> consuming the longer textual description.
>>>  * Browsers must preserve the HTML richness of the longer textual
>>> description content.
>> This simple solution meets all the requirements:
>> <a href=foo><img src=pic alt="*the purpose of the link*"></a>
> Okay, I can see some web designers might use that pattern but …
>> If users need to be able to determine programmatically that the link
>> is a long description of the image, or authors want to put two links
>> on one image:
>> <a href=foo rel=longdesc><img src=pic alt="*a programmatically
>> determinable long description link*"></a>
>> <img src=pic alt="*text alternative*" usemap=#map>
>> <map name=map>
>> <area shape=rect coords=0,0,100,50 href=foo rel=longdesc alt="*a
>> programmatically determinable long description link*">
>> <area shape=rect coords=0,50,100,100 href=bar alt="*on an image that
>> is already a link*">
>> </map>
>> This universal design approach works for everyone, right now, and
>> doesn’t require changes to accessibility APIs, software upgrades,
>> browser add-ons, user training, author training, or employing the
>> services of an accessibility specialist. Unlike longdesc (and ARIA)
>> this technique currently works in all screen readers, including
>> VoiceOver, Orca and NVDA, as well as all other AT, including screen
>> magnifiers, and all browsers.
> Screenreaders aside, how does this design work for:
>    1. Sighted keyboard users who cannot trivially determine which
> part of the image leads to what.
>    2. Sighted mouse users who will be confused by (say) a photo that
> leads either to a text description or to a larger version (e.g. a big
> raw JPG) depending on where they click.
> (Tooltips aren't a good workaround for these defects, as UAs don't
> show them on focus and users don't wait for them or read them.)
> The usability of this pattern can only degrade further when you throw
> partial sight (making it hard to use the tooltips), motor impairments
> (making it hard to focus the mouse), or learning disabilities (making
> it hard to understand opaque interfaces) into the mix.
> If the design will not afford distinct, visible, on-page controls, the
> discoverability problems raised by distinguishing between a primary
> action (getting a bigger image) and a secondary action (getting
> information about the image) are likely easier to mitigate through
> better UA interfaces than the usability headaches created by authors
> arbitrarily carving up photos, charts, and diagrams into mystery meat
> navigation:
>    http://en.wikipedia.org/wiki/Mystery_meat_navigation
> --
> Benjamin Hawkes-Lewis

Removing the HTML-A11Y-TF's "no visual encumbrance" and "no default
indicator" constraints would certainly improve perceivability for
sighted users, and the range of authoring options available :)

Received on Tuesday, 31 January 2012 10:06:06 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:19 UTC