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

Matthew Turvey wrote:
> 
> I've already explained why I think a normal link on the image meets
> these requirements:
> 
> http://lists.w3.org/Archives/Public/public-html/2012Jan/0184.html
> 

...and you have been repeatedly refuted on this simplistic claim.  

However, let's make this real:  On January 17th, 2011 Google celebrated the
50th Anniversary of John F. Kennedy's inaugural speech with one of their
famous Google Doodles (seen here at the Internet Archive "WayBackMachine"
http://web.archive.org/web/20110120204039/http://www.google.com/) 

On that day, clicking on the Doodle would take you to the following URL:
http://www.google.com/search?q=John+F.+Kennedy+inaugural+address (please
feel free to examine the source code at the above URL to verify this claim).

Google also used the following code to actually insert the image into their
home page:

	<img alt="50th Anniversary of JFK&#39;s Inaugural Address"
title="50th Anniversary of JFK&#39;s Inaugural Address" border=0 height=190
src="...">

Because the link that surrounded the image took you to the search page
related to JFK's speech, the alt text was, for the most part correct.  

Sadly however, Google apparently doesn't think enough of the time, cost and
effort they put into those famous doodles to bother sharing them with
non-sighted users. If they did, they could have provided a long description
similar to the following:

	<p>Today's Google Doodle continues on the tradition of providing
alternatives to the traditional G O O G L E logo on the home page. The
letter G is an ASCII rendition of the G made from numerous words taken from
<a
href="http://www.americanrhetoric.com/speeches/jfkinaugural.htm"><abbr>JFK</
abbr>'s Inaugural Speech</a>, arranged to form the actual letter. Some of
the key blue words in this letter are ask, what, nation, citizens, greater,
light, deeds and devotion, all in random order. The first O is composed of a
similar set of words in red, with key words including you, can, do, globe,
effort, progress, now and fruitful. The second O again follows this pattern,
with orange key words including hope, anew, for, peace, help and truly. </p>

	<p>The traditional lower case G is here a blue likeness of
<abbr>JFK</abbr> himself. At first it, it appears to be a charcoal or pencil
sketch, but on closer inspection you notice that it too is in fact an ASCII
artwork, again using key words taken from <abbr>JFK</abbr>'s speech. Few
actual words are discernible however. The final 2 letters, a green L and red
E are again created using key words: the L containing your, unite, renew,
pledge, deeds, and the E containing country, who, tap, sides, both for and
your.</p>


If this prose was put on a separate web page (JFK_doodle.html) how would you
link it to the doodle? 

1) You can't just simply make a "normal link" as you suggest, as the linking
function is already reserved for the search result page. This is not some
"made-up" use case, this is a real world, actual demonstration of the need,
on arguably one of the most visited web pages on the internet.

2) You couldn't just park it off screen somewhere, or 'hide' if with
@hidden, and then link to it with aria-describedby because:
  
	a) You would lose both the hyperlink to the actual speech, as well
as the semantic markup of <abbr>, as both would be flattened to string text.

	b) If somehow you could overcome the flattening-to-string-text
problem, to activate the hyperlink you must put tab-focus on the link - how
do you focus on something that is hidden? And what of sighted users,
(perhaps using a tool such as ZoomText Magnifier/Reader, which is both a
screen reader and screen magnifier -
http://www.aisquared.com/zoomtext/more/zoomtext_magnifier_reader/) who would
hit the tab key and not see a visible tab focus (failing WCAG 2.4.7 Focus
Visible: Any keyboard operable user interface has a mode of operation where
the keyboard focus indicator is visible. (Level AA)) - what exactly should
the magnifier magnify?

	c) The aria-describedby attribute (as well as its companion
aria-labelledby and aria-label attributes) are read as the Accessible Label
in the Accessibility API's - those APIs do not recognize the fact that this
is additional and supplemental information that should be served to the user
on demand - they instead supply their labeling/describing text as part of
the regular speech flow. The net effect is, even if I were to remove the
hyperlink and <abbr> markup, the screen reader would announce the following:

	"Link: 50th Anniversary of JFK's Inaugural Address[1] Today's Google
doodle continues on the tradition of providing alternatives to the
traditional G O O G L E logo on the home page.  The letter G is an ASCII
rendition of the G made from numerous words taken from JFK's Inaugural
Speech, arranged to form the actual letter. Some of the key blue words in
this letter are ask, what, nation, citizens, greater, light, deeds and
devotion, all in random order. The first O is composed of a similar set of
words in red, with key words including you, can, do, globe, effort,
progress, now and fruitful. The second O again follows this pattern, with
orange key words including hope, anew, for, peace, help and truly. The
traditional lower case G is here a blue likeness of JFK himself. At first
it, it appears to be a charcoal or pencil sketch, but on closer inspection
you notice that it too is in fact an ASCII artwork, again using key words
taken from  JFK's speech. Few actual words are discernible however. The
final 2 letters, a green L and red E are again created using key words: the
L containing your, unite, renew, pledge, deeds, and the E containing
country, who, tap, sides, both for and your."

[1 Note, because there is no period at the end of the ALT text, it would
result in a run-on sentence in the screen reader]

Go ahead, read that out loud to yourself and then ask if that even remotely
seems to be an appropriate user-experience. Every time.

The problem with your suggestion also has the additional problem: No user,
sighted or otherwise, would know prior to clicking on the image, where the
link would be taking them to, and few users would be expecting a textual
description of an image they just saw and clicked on.

As shown, there are also real-world use cases where doing what you suggest
as the appropriate solution simply will not work.


> 
> I think the poor quality of the longdesc-specific examples in the wild
> confirms my own real world experience that this technique is never
> needed.

We can no longer give any credence to this line of argument, as multiple
actors in the HTML5 evolution have stated that HTML5 is not just a capturing
of the real internet as it is today (which includes BTW limited but real and
appropriate use of @longdesc), but that it should also be a road-map to what
the web should be:

On 2012-01-06 Anne van Kesteren stated: "A standard sets a goal."
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13531#c8 

On 20-01-30 Jonas Sicking wrote: "... so far this has not happened.  So
let's instead write the specification that will create the most accessible
web once implemented..."
http://lists.w3.org/Archives/Public/public-html/2012Jan/0199.html



> 
> For the record, "d"-links never worked either, for obvious reasons:
> 
> http://lists.w3.org/Archives/Public/w3c-wai-ig/1998AprJun/0096.html 

Correct, and both Kynn and Geoff acknowledge the problem of forced visual
encumbrances on the web page in the email you reference, a requirement that
you seem very confused about, even when you point to a 14 year old
conversation that covered that very problem nearly a decade and a half ago.
This is why many of us are still trying to remind people of the  problem of
"forcing" a visual indication on the web-page.

JF

Received on Thursday, 2 February 2012 04:45:53 UTC