W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2010

validating understanding of techniques for 1.1.1 & 2.4.4

From: Jennison Mark Asuncion <asuncion@alcor.concordia.ca>
Date: Wed, 14 Jul 2010 10:00:30 -0400
Message-ID: <1b50d5f5be01b83af0e3e7df323a35d9.squirrel@webmail.concordia.ca>
To: w3c-wai-ig@w3.org
Hello,

Thanks for help previously given understanding some of the WCAG
guidelines. I have three additional questions that have come up, two are
validations of understandings, and one is more a query on WCAG's approach.

1.1.1	Non-text Content:
All non-text content that is presented to the user has a text alternative
that serves the equivalent purpose, except for the situations listed
below…
from the link text alone or from the link text together with its
programmatically determined link context, except where the purpose of the
link would be ambiguous to users in general.
Technique H24: Providing text alternatives for the area elements of image
maps states:
“Therefore, when using image maps, successful implementation of this
technique would require either:
Ensuring the area element alt attribute value is displayed in response to
attaining focus (including keyboard focus), and that this applies both to
situations where images are loaded and not loaded. OR
A redundant mechanism serving the same purpose as the area elements is
present in the Web Page.”
Question 1: This technique implies that for client-side image maps to be
fully accessible, the “alt” of each area must also be keyboard accessible.
Is this interpretation correct? Has anyone been able to implement this
technique in this manner?
Question 2: Is there a reason why WCAG is singling out client-side image
maps and hyperlinks using “title” and not on image hyperlinks or other
Non-text Content that may not show alternatives when using the keyboard?

2.4.4 Link Purpose (In Context):
The purpose of each link can be determined from the link text alone or
from the link text together with its programmatically determined link
context, except where the purpose of the link would be ambiguous to users
in general.
Technique H33: Supplementing link text with the title attribute states:
“Implementing this technique with the title attribute is only sufficient
if the title attribute is accessibility supported. The content of the
title attribute needs to be available to all keyboard users (not only
those with text-to-speech software) for this attribute to be accessibility
supported.”
Question 3: This technique implies that for links using the “title”
attribute to be fully accessible, the “title” of each link must also be
keyboard accessible. Is this interpretation correct? Has anyone
successfully implemented this technique in this manner?

Any help on the above three questions is, as always, appreciated.

Jennison


-- 
Jennison Mark Asuncion
Co-Director, Adaptech Research Network <www.adaptech.org>
LinkedIn at <www.linkedin.com/in/jennison>
Received on Wednesday, 14 July 2010 14:01:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:14:34 GMT