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

On Thu, Feb 2, 2012 at 7:25 PM, Matthew Turvey <mcturvey@gmail.com> wrote:
> On 31 January 2012 23:39, Benjamin Hawkes-Lewis
> <bhawkeslewis@googlemail.com> wrote:
>> On Tue, Jan 31, 2012 at 10:05 AM, Matthew Turvey <mcturvey@gmail.com> wrote:
>>> 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 :)
>>
>> You can have reasonably discoverable secondary actions without
>> relaxing these constraints:
>
> I think opinions may differ on at what point something becomes
> unreasonably discoverable, especially for non-technical users :)
>
>>    - Hint secondary actions on hover, for example with an icon over
>> the image control. iCab provides such hints with @longdesc.
>>
>>    - Expose the secondary action in the context menu. Opera provides
>> this for @longdesc.
>
> I don't think it's easy or intuitive for sighted users to determine
> that a special icon or mouse cursor means they should do something
> like activate a context menu and locate an entry called "long
> description". In my opinion your points about the problems opaque and
> non-intuitive indicators on image maps present to people with partial
> sight or learning disabilities apply here too.

They apply with several orders of magnitude less force. You can learn
these UIs once and apply that knowledge to multiple pages, whereas
mystery meat navigation can only be learned on a page-by-page basis.
Moreover, @longdesc semantics allow custom UI to meet the requirements
of people with partial sight or learning disabilities (for example, by
introducing a default visual encumbrance to the layout for those
users), whereas mystery meat navigation does not:

    http://www.w3.org/TR/WCAG/#content-structure-separation

>>    - Perhaps best of all, give the user an explicit choice of actions
>> when they focus, hover, or activate the image control, for example by
>> popping up a menu with two options "{Link text}" and "Long
>> description". This UI pattern is familiar from mobile interfaces,
>> where (for example) when you sharing a link you can choose which
>> sharing service to use.
>>
>> Such UI patterns could be reused in other cases of multiple links, for
>> example, when @href and @cite conflict. Note that HTML5 says "User
>> agents should allow users to follow such citation links."
>>
>> It's a lot easier for UAs to provide this sort of progressive
>> disclosure based on declarative markup like @longdesc and @cite than
>> on mystery meat image maps.
>
> I think this is more an argument for a generalised solution for
> putting multiple links (or commands) on any element.

[snip]

> another author may think it makes more
> sense to put the image description as the normal link, and a link to
> the raw JPG (or links to several different JPG sizes) on the context
> menu.

The argument that mystery meat navigation is not a viable substitute
for semantics that allow the creation of good multi-link UI in this
particular case is *not* dependent on an argument that multi-link UIs
are a good thing to encourage in general.

It does not automatically follow that if (a) we wish to allow authors
to provide long descriptions as a secondary link to avoid them failing
to provide a long description at all, then (b) we also wish to allow
authors to provide images at alternative sizes or qualities as
secondary links rather than visible links.

--
Benjamin Hawkes-Lewis

Received on Monday, 6 February 2012 22:50:35 UTC