Re: on headings, labels, links, and image maps

Hi

1) Headings - yes you are correct, level A requires coded headings so
that blind users can get an overview of teh page and jump to sections of
interest by listing the headings. Level AA requires these headings to be
nested correctly (ie form a logical semantic structure)

2) Links using URI, Yes again you are correct, the URI does not tell a
normal user what will happen if he or she selects the link. Surrounding
text is not useful as people using assistive software (esp screen
readers) list the links separately (ie out of context). The link text
must be absolutely clear by itself as to what will happen if selected.

3) Ah - the title attribute!! This attribute should only be used when
all other attempts at making the link intelligible by itself fail, in
which case it is relevant/helpful to all users, not just screen reader
users. Therefore it must be universally accessible. The problem has
arisen because some designers thought they were being clever by adding
the attribute to their links in the belief that this then meant they
could write rubbish link text. Trouble is that screen reader users get a
bit annoyed if every link read out has two messages (link text and title
text). I sometimes use Jaws 10 at work and have turned off the facility
to read the title attribute because I find it so annoying.

4) Label positioning,  There are two separate problems being solved
here. The location of the descriptive text for the input field needs to
be visually close to the input field because people with some vision
using a magnifying application (eg Zoom text) need to be able to see
this text (field label) as well as the actual input field. This is thus
a visual thing - whereas the second point (explicit association) is a
code thing. Now that most assistive software understands the <label
for="xx"> element it is possible to place the code for the label
anywhere in the document. Where this comes into play particularly is if
you want to place the field label above or below the input field. You
might have two or three input fields across the page. In the old days
the only way to do this was to use a table for layout with each field
label and input field in the same cell. Now you can have it coded anyway
you want so long as each field label is tied correctly to the relevant
input element, even 
fieldlabel1, fieldlabel2 fieldlabel3 </br>input1, input 2, input3
So in answer to your question visual proximity is required but not code
proximity (so long as the <label> element is used correctly. 

5) Image maps. Textual interpretation for the map area is essential.
This can be as a title that works for keyboard and mouse users so that
when the map area is focused (by whatever means) a suitable text (link
text) is displayed. If this is not possible then provide a separate list
beside the map.


Best wishes
Richard
On Wed, 2010-05-26 at 21:29 -0400, Jennison Mark Asuncion wrote:
> Hello,
> 
> A colleague has been reviewing Understanding WCAG 2.0 and Techniques for
> WCAG 2.0 and has the following questions on: headings, links, labels, and
> image maps. Rather than sending  the questions individually, I am sharing
> all five below and would be grateful for your collective wisdom on any/all
> of these. Each question does have an associated reference as indicated.
> 
> 
> Headings
> reference: Understanding WCAG 2.0
> WCAG 2.0-1.3.1 [Info and Relationships] and WCAG 2.0-2.4.10 [Section
> Headings] both map to WCAG 1.0-3.5 [Use header elements to convey document
> structure and use them according to specification]
> 1) I'm having difficulty distinguishing at what level of compliance
> applying headings in a hierarchal order is required.  Is my interpretation
> correct that WCAG 2.0-1.3.1 at Level A requires only applying headings
> using markup within the HTML code to convey the structure and WCAG 2.4.10
> at Level AAA requires that headings are properly nested?
> 
> Links
> reference: Understanding WCAG 2.0
> WCAG 2.4.4 [Link Purpose (In Context)]
> 2) Am I correctly interpreting that a link that is described by the URI
> itself does not comply with this checkpoint, even if the sentence or
> paragraph beforehand provides the description as to the purpose of the URI
> hyperlink?
> 
> reference: Techniques for WCAG 2.0
> reference: WCAG 2.0-H33 [Supplementing link text with the title attribute]
> 3) Text under the "User Agent and Assistive Technology Support Notes"
> states the following"
> "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."
> 
> Does this mean that the "title" attribute is only considered a WCAG 2.0
> Level A compliance item for providing link purpose if the "title"
> attribute is also made available to keyboard only users?  Or is this
> simply an informative side note?
> 
> Labels
> reference: Understanding WCAG 2.0
> WCAG 2.0-3.3.2 [Labels or Instructions]
> 4) The text under the "Specific BenefitsÂ…" section states the following:
> "Field labels located in close proximity to the associated field assist
> users of screen magnifiers because the field and label are more likely to
> visible within the magnified area of the page."
> 
> However the Comparison of WCAG 1.0 Checkpoints to WCAG 2.0 document notes
> that the WCAG 1.0-10.2 [Until user agents support explicit associations
> between labels and form controls, for all form controls with implicitly
> associated labels, ensure that the label is properly positioned] is no
> longer a requirement since:
> "User agents now support explicit associations of labels with form
> controls, so the "until user agents" clause has been satisfied. This is
> therefore no longer a requirement under WCAG 2.0.".
> 
> I'm having difficulty understanding whether positioning field labels in
> close proximity to the field controls is a WCAG 2.0 requirement for Level
> A compliance or not?
> 
> Image Maps
> reference: Techniques for WCAG 2.0
> WCAG 2.0-H24 [Providing text alternatives for the area elements of image
> maps]
> 5) Text under the "User Agent and Assistive Technology Support Notes"
> states the following:
> "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.
> "
> Does this mean that the image maps are considered a WCAG 2.0 Level A
> compliance item only if they display the alternative for each area upon
> receiving keyboard focus or providing redundant set of visible links for
> keyboard users?  I'm confused because I don't understand why this is only
> a requirement for image maps when it's not required for short alternatives
> for images or why it is recommended to use "hidden" text for links that
> are also not available to keyboard users?  Or is this note specific to
> server-side image maps requiring a keyboard equivalent (in comparison to
> client-side image maps which are natively keyboard accessible by default)?
> 
> Jennison
> 
>

Received on Thursday, 27 May 2010 18:21:16 UTC