- From: Roger Hudson <rhudson@usability.com.au>
- Date: Fri, 28 May 2010 10:37:59 +1000
- To: "'Jennison Mark Asuncion'" <asuncion@alcor.concordia.ca>, <w3c-wai-ig@w3.org>
Hi Jennison, Aren't words wonderful? No matter how precise they might seem they are always open to interpretation. Anyway, I have a slightly different interpretation for a couple of these issues. Headings: I agree that with 1.3.1 (A), Technique H42 requires the use of HTML headings elements, but doesn't explicitly specify that they must be correctly nested. However, I feel that 2.4.10 (AAA) is primarily about the need to have headings for written content regardless of the technology used. Sufficient Technique G141 tells us that, "The objective of this technique is to ensure that sections have headings that identify them." It suggests that with HTML this can be done using heading elements (h1-h6) since this will allow user agents to identify them. I don't feel the main purpose of the SC 2.4.10 relates to the appropriate use of heading elements, rather it is about making sure large slabs of text is broken up into sections that are identified with appropriate headings and sub-headings. For example, say there is a page of text with just two heading, but the content of the page covers many different topics that are not identified with sub-headings. I don't feel this page would comply even if the two headings were correctly nested, since many other headings are missing. I am not sure if there is anywhere in WCAG or in the HTML specs that say you MUST nest heading elements appropriately, however clearly it is a good thing to do. Maybe failure to do could contribute to non-compliance with 4.1.1, but then again maybe not. Links in Context: I am not sure what you suggest is correct. Success Criteria 2.4.4 (A) states, "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." The relevant word in this I believe is 'or'. I think that a link described only by the URI would comply so long as its meaning could be derived from the context (e.g. Techniques G53, H80 etc). Clearly this is not best practice and I am sure Success Criteria 2.4.9 Link Purpose (link alone) (AAA) is preferable. Roger Hudson Web Usability Web: www.usability.com.au Blog: www.dingoaccess.com -----Original Message----- From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org] On Behalf Of Jennison Mark Asuncion Sent: Thursday, 27 May 2010 11:29 AM To: w3c-wai-ig@w3.org Subject: on headings, labels, links, and image maps 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 -- Jennison Mark Asuncion Co-Director, Adaptech Research Network <www.adaptech.org> LinkedIn at <www.linkedin.com/in/jennison>
Received on Friday, 28 May 2010 00:39:37 UTC