Edit comment LC-2501 for Accessibility Guidelines Working Group

Quick access to LC-2429 LC-2453 LC-2454 LC-2455 LC-2461 LC-2462 LC-2463 LC-2468 LC-2470 LC-2472 LC-2473 LC-2474 LC-2477 LC-2478 LC-2479 LC-2480 LC-2495 LC-2497 LC-2498 LC-2499 LC-2501

Comment LC-2501

Comment Shortname:

Commenter: Sheena McCullagh <sheena.mccullagh@blueyonder.co.uk>

Message-id:

Section of the document concerned:

[Free text description]Document as a wholeIntroduction to Understanding WCAG 2.0 Understanding the Four Principles of Accessibility Layers of Guidance The Guidelines Success Criteria Sufficient and Advisory Techniques Text Alternatives: Understanding Guideline 1.1 Intent of Guideline 1.1 Non-text Content: Understanding SC 1.1.1 Time-based Media: Understanding Guideline 1.2 Audio-only and Video-only (Prerecorded): Understanding SC 1.2.1 Captions (Prerecorded): Understanding SC 1.2.2 Audio Description or Media Alternative (Prerecorded): Understanding SC 1.2.3 Captions (Live): Understanding SC 1.2.4 Audio Description (Prerecorded): Understanding SC 1.2.5 Sign Language (Prerecorded): Understanding SC 1.2.6 Extended Audio Description (Prerecorded): Understanding SC 1.2.7 Media Alternative (Prerecorded): Understanding SC 1.2.8 Audio-only (Live): Understanding SC 1.2.9 Adaptable: Understanding Guideline 1.3 Info and Relationships: Understanding SC 1.3.1 Meaningful Sequence: Understanding SC 1.3.2 Sensory Characteristics: Understanding SC 1.3.3 Distinguishable: Understanding Guideline 1.4 Use of Color: Understanding SC 1.4.1 Audio Control: Understanding SC 1.4.2 Contrast (Minimum): Understanding SC 1.4.3 Resize text: Understanding SC 1.4.4 Images of Text: Understanding SC 1.4.5 Contrast (Enhanced): Understanding SC 1.4.6 Low or No Background Audio: Understanding SC 1.4.7 Visual Presentation: Understanding SC 1.4.8 Images of Text (No Exception): Understanding SC 1.4.9 Keyboard Accessible: Understanding Guideline 2.1 No Keyboard Trap: Understanding SC 2.1.2 Keyboard (No Exception): Understanding SC 2.1.3 Enough Time: Understanding Guideline 2.2 Timing Adjustable: Understanding SC 2.2.1 Pause, Stop, Hide: Understanding SC 2.2.2 No Timing: Understanding SC 2.2.3 Interruptions: Understanding SC 2.2.4 Re-authenticating: Understanding SC 2.2.5 Seizures: Understanding Guideline 2.3 Three Flashes or Below Threshold: Understanding SC 2.3.1 Three Flashes: Understanding SC 2.3.2 Navigable: Understanding Guideline 2.4 Bypass Blocks: Understanding SC 2.4.1 Page Titled: Understanding SC 2.4.2 Focus Order: Understanding SC 2.4.3 Link Purpose (In Context): Understanding SC 2.4.4 Multiple Ways: Understanding SC 2.4.5 Headings and Labels: Understanding SC 2.4.6 Focus Visible: Understanding SC 2.4.7 Location: Understanding SC 2.4.8 Link Purpose (Link Only): Understanding SC 2.4.9 Section Headings: Understanding SC 2.4.10 Readable: Understanding Guideline 3.1 Language of Page: Understanding SC 3.1.1 Language of Parts: Understanding SC 3.1.2 Unusual Words: Understanding SC 3.1.3 Abbreviations: Understanding SC 3.1.4 Reading Level: Understanding SC 3.1.5 Pronunciation: Understanding SC 3.1.6 Predictable: Understanding Guideline 3.2 On Focus: Understanding SC 3.2.1 On Input: Understanding SC 3.2.2 Consistent Navigation: Understanding SC 3.2.3 Consistent Identification: Understanding SC 3.2.4 Change on Request: Understanding SC 3.2.5 Input Assistance: Understanding Guideline 3.3 Error Identification: Understanding SC 3.3.1 Labels or Instructions: Understanding SC 3.3.2 Error Suggestion: Understanding SC 3.3.3 Error Prevention (Legal, Financial, Data): Understanding SC 3.3.4 Help: Understanding SC 3.3.5 Error Prevention (All): Understanding SC 3.3.6 Compatible: Understanding Guideline 4.1 Parsing: Understanding SC 4.1.1 Name, Role, Value: Understanding SC 4.1.2 Understanding Conformance Understanding Conformance Requirements Understanding Requirement 1 Understanding Requirement 2 Understanding Requirement 3 Understanding Requirement 4 Understanding Requirement 5 Understanding Conformance Claims Understanding Levels of Conformance Understanding Accessibility Support Understanding "Programmatically Determined" Understanding Conforming Alternate Versions Understanding "Web Page" Understanding "Text Alternatives" Appendix A How to refer to WCAG 2.0 from other documents Appendix B Documenting Accessibility Support for Uses of a Web Technology Appendix C Understanding Metadata Appendix D References
or

Refinement of the section concerned:

Status:

open proposal pending resolved_yes resolved_no resolved_partial other assigned to Nobody Abma, Jake Abou-Zahra, Shadi Allan, Jim Auclair, Christopher Avila, Jonathan Babinszki, Tom Bailey, Bruce Bernard, Renaldo Bernier, Alex Blake, Matthew Boudreau, Denis Brewer, Judy Butler, Shari Campbell, Alastair Carlson, Laura Chakravarthula, Srinivasu Cirrincione, Pietro Conway, Vivienne Cooper, Michael Crutchfield, Elizabeth Deltour, Romain Dick, Wayne Ding, Chaohai Dirks, Kim Dixit, Shwetank Draffan, E.A. Duggin, Alistair Eggert, Eric Elledge, Michael Faulkner, Steve Ferraz, Reinaldo Fiers, Wilco Fischer, Detlev Foliot, John Garrish, Matt Garrison, Alistair Gower, Michael Guarino Reid, Loretta Hakkinen, Markku Haritos-Shea, Katie Henry, Shawn Hoffmann, Thomas Horton, Sarah Isager, Kasper Jensen, Tobias Christian Johansson, Stefan Johlic, Marc Johnson, Rick Jones, Crystal Joys Andersen, Wilhelm Kapoor, Shilpi Keim, Oliver Kirkpatrick, Andrew Kirkwood, John Kiss, Jason Kraft, Maureen Ku, JaEun Kurapati, Sujasree Lauke, Patrick Lauriat, Shawn Lee, Steve Lemon, Gez Li, Alex Li, Kepeng Li, Liangcheng Loiselle, Chris Lowney, Greg Lui, Edwina Lund, Adam Ma, Jia MacDonald, David Mace, Amanda Manser, Erich Martin, Debra McCormack, Scott McMeeking, Chris McSorley, Jan Milliken, Neil Montgomery, Rachael Mueller, Mary Jo nicole, windmann Niemann, Gundula Nurthen, James O Connor, Joshue Oh, Jeong-Hun Panchang, Sailesh Pandhi, Charu Pasi, Aparna Patch, Kimberly Philipp, Melanie Pluke, Mike Pouncey, Ian Repsher, Stephen Rochford, John Runyan, Marla Savva, Andreas Sawczyn, Steve Schnabel, Stefan Seeman-Kestenbaum, Lisa Sims, Glenda Singh, Avneesh Skotkjerra, Stein Erik Sloan, David Smith, Alan Smith, Jim Solomon, Adam Spellman, Jeanne F Strobbe, Christophe Suprock, Greg Swallow, David Thompson, Kenneth Thyme, Anne Ueki, Makoto Vaishnav, Jatin Vanderheiden, Gregg Venkata, Manoj Wahlbin, Kathleen Wang, Can WANG, WEI White, Jason Zelmanowicz, Erica Zerner, Adam Zhang, Mengni

Type: substantive editorial typo question general comment undefined

Resolution status:

Response drafted Resolution implemented Reply sent to commenter

Response status:

No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):

Comment:

I had originally read this that 1 and 2 were exactly that an 'and', then someone I know who does accessibility testing for a living, pointed out to me that I was wrong. They are not 'and', ie you can do one or the other. However I see a problem with that:

Skip links are of main benefit to sighted users who navigate via the keyboard and are of only very limited benefit to screen reader users. However H69 (heading elements) is only of use to screen readers and provides no help whatsoever for sighted users navigating via the keyboard. (I don't know enough about map, frame and scripting to comment on those, but as they have been grouped with H69, I suspect that they too are of little or no benefit to sighted people who navigate with the keyboard.)

Nonetheless, if someone writes a web page to H69, they would be deemed to have passed SC 2.4.1, even though they have not provided any method for sighted keyboard users to bypass blocks of content that are repeated on multiple pages. The most number of hits of the tab key that I counted before getting to the main page content on one web site was 69 each time I went onto a new page.

Proposed Change:
Please make it 'and' so that both sighted keyboard users and screen reader users are helped. At the moment it's perfectly possible to help only one of those groups and not help the other and still pass this SC.

Response from WG:
http://lists.w3.org/Archives/Public/public-comments-wcag20/2011Mar/0015.html

It is only necessary to implement one of the listed sufficient techniques for this, or any other, success criterion. Authors may choose to implement more than one technique to improve usability, of course.

Skip links may not be the preferred mechanism for screen reader users, but links work for them, so skip links will permit them to skip over the repeated content.

The User Agent Notes for H69 discuss the native support for navigating by headings that is provided in Opera, and notes that for other browsers, plugins may be needed. Authors who rely on H69 must ensure that it is accessibility supported for their users.

Response from commenter:
http://lists.w3.org/Archives/Public/public-comments-wcag20/2011Mar/0021.html

You've completely missed my point. If H69 etc is used to pass this criterion you are only helping screen reader users.

What about those of us who navigate with the keyboard but are sighted, ie do not use assistive technology of any sort? Correct heading structure is of no benefit what-so-ever to us.

If you don't want an AND, perhaps 2.4.1 should be split into two requirements so that the first requirement is to provide a method for keyboard users to bypass blocks and the second requirement is to provide a method for AT users to bypass blocks. As we both know there is a precedent for splitting a single SC into various requirements - 1.4.8.

Comment from Sailesh Panchang:
http://lists.w3.org/Archives/Public/public-comments-wcag20/2011Mar/0059.html

Sheena and I are not talking usability here but accessibility. And WCAG2 addresses needs of a wider spectrum of PWDs than just screen reader users. Sighted keyboard users are an important constituency for SC 2.4.1.
Yes headings work with screen readers and Opera but skip nav works for a wider set of users as stated earlier. For the limited purpose of SC 2.4.1, the skip-nav technique is a sufficient technique. H69 is not. It enhances "usability".
Use of headings may be required to satisfy SC 1.3.1 (see H42) and as an auxiliary benefit will help navigation too. By requiring H42 for SC 1.3.1 and the skip-nav technique for SC 2.4.1, the techniques will address the needs of a larger set of PWD and the WCAG 2 will do more for accessibility. Not less.
As H69 has user-agent limitations I had suggested do away with H69 as h42 is present some 2-3 years ago. I reiterate that.
Finally, one does not go around adding heading tags simply to help keyboard navigation but to mark up section headings to expose structure. But websites can be required to add one skip nav link as has been the practice since S508 became law.
There are many many U.S. fed gov websites that do not implement headings because it was not needed by S508 but do have skip nav link.
Not sure many are aware of a plugin to make keyboard navigation work with headings for browsers like IE and FF. Maybe a links should be given as a resource for H69 if it is retained. H69 may be an advisory technique ..

[1] http://lists.w3.org/Archives/Public/public-comments-wcag20/2011Mar/0011.html

Related issues: (space separated ids)

WG Notes: jon G: Browser vendors want to make their browsers as lean as possible, and push "optional" functionality into plugins. Issue considered when we added this technique. UA support isn't any worse. https://addons.mozilla.org/en-US/firefox/addon/accessibility-evaluation-toolb/ Will Walker work? https://addons.mozilla.org/en-US/firefox/addon/headingsmap/ --- Removed HeadingsMap <https://addons.mozilla.org/en-US/firefox/addon/headingsmap/>

Resolution: The author of web content needs to be sure that the technique used to meet a success criterion is supported by the user agents available to his users. We add User Agent notes to advise authors of limitations in user agents support for a technique, and we have done so with H69. Because there are environments in which there is sufficient user agent support, we continue to list it as a sufficient technique for SC 2.4.1. We notice that the trend among browsers is to provide minimal functionality in the browsers themselves, but to support plugin and extension mechanisms for adding functionality that isn't needed by all users. This lets users customize the browser to their own needs. Support for keyboard navigation via header appears to be one of the functions that will usually be found in such extensions. We are adding to the Resources for H69 to list some of the plugins currently available for providing keyboard navigation via headers: [DONE] Add to Resources: For Firefox, the following plugins provide header navigation via the keyboard: Accessibility Evaluation Toolbar <https://addons.mozilla.org/en-US/firefox/addon/accessibility-evaluation-toolb/> Heading Navigation Greasemonkey User Script <http://juicystudio.com/article/heading-navigation-greasemonkey-user-script.php> [DONE] Also add to Resources: Heading navigation in web browsers <http://www.456bereastreet.com/archive/201003/heading_navigation_in_web_browsers> [DONE] Add to end of User Agent Notes: "See the Resources section for references to some of these plugins."

(Please make sure the resolution is adapted for public consumption)