W3C logoWeb Accessibility Initiative (WAI) logo

WAI: Strategies, guidelines, and resources to make the Web accessible to people with disabilities

[Draft] Analysis and Change log for "Application Notes"

Page Contents

Latest version


Naming the notes

What should the Application Notes be called? The current working name is "Accessibility Tutorials" or "Tutorials" for short.

Post brain-storm and email discussion

The ideas and thoughts shared by email all had two terms in common, "Accessibility" and "Guides". So if we call them "Practical Accessibility Guides", "Accessibility How To Guides" or Accessibility Quick Start Guides", the title for the Labels page could be:

Each set of pages could then be called a Guide, and the navigation list could be headed up as "All Guides".

EOWG brain-storm 12 April 2013

(x) denotes the section topic, i.e. Tables or Forms:

The final choice should have the following attributes:

Headings in Concept pages

The main content of concept pages such as "Forms concepts" has two headings, "Summary" and "Who benefits". In EOWG folks' view, are these headings appropriate, accurate and in the correct order? In other words, should "Rationale" be used instead of "Who benefits", and is it OK to start with a "Summary" or should this heading be "Overview"?


The term "coding" has been used rather than "markup" to avoid potential misunderstanding. Does EOWG feel that this is a good idea or not, or is there a middle ground?


To provide practical, authoritative guidance on implementing Web Content Accessibility Guidelines (WCAG) 2.0 in different contexts and situations.




The following audiences can be beginners, intermediate, or advanced in web accessibility:

Primary audiences

Other audiences


Primary scenario examples include:

Other scenario examples (from 2011 f2f meeting include:

  1. Martina, web developer
  2. Andy, coder (after he's convinced)
  3. Marc, graphic designer
  4. Xiaoping Zhang, professor
    • Who: Freelancer with good development skills, low accessibility skills.
    • Motivation: Signed contract to develop accessible website. (uh, oh, what have we gotten ourselves into?!?)
    • Need: Immediate information on addressing accessibility requirements.


Develop a library of short, focused tutorials and explantory resources on specific topics. This library contents is organized thematically to speak to tasks of the target audiences, potentially using terms and phrases they could be looking for in different situations (e.g. "fixing a template" or "applying WCAG2 on mobile apps").



The resources will discuss a theme or topic in a narrative approach to explain the related underlying WCAG 2.0 principles and concepts thematically. The resources will explain the applicability of related WCAG 2.0 Success Criteria, and will reference relevant WCAG 2.0 Techniques and sections of Understanding WCAG 2.0 where applicable (see WCAG 2.0 Overview for more information on these WCAG 2.0 resources).

Potential outline for most resources could be:

Resources will also clearly address novice, intermediate, and advanced issues for different audiences.


The resources will be edited by WAI Staff as part of the WAI-ACT Project (IST 287725), and will be developed with review, input, and approval of EOWG (as will all EOWG materials).

Possible Topics

Potentially 30-40 individual "notes" to be developed over the next 2.5-3 years; the exact topics and issues will be decided in coordination with EOWG:




Ideas for Keyboard Access App Notes (WCAG Comment LC-1229):

Comment: Today, there are two levels of "being keyboard operable." One is simply being able to operated without using a mouse, with simple keystrokes such as the tab and the enter keys. The other, higher level is where author uses extensive client-side scripting to provide keyboard shortcuts. (The user interface of the Gail is an example.) In the latter case, many of the keystrokes provided by the author may conflict with keyboard commands provided by the UA (including the assistive technology.) Thus, in this case, it would not make much accessibility improvement especially for those using screen readers and other AT that make extensive use of keyboard. Explanation in the WCAG and the Subdocument should be clearer about this point.
Pending Response: This isn't something that would be handled in the guidelines themselves. This type of topic would be handled in an application notes. We would love to write an Application Note "Enhancing Keyboard Access to Web Content" that would provide guidance on assigning hotkeys, defining logical tab order, defining hotkeys shown on buttons, and defining tab indices for text focus and search functionality. It might also discuss the topic of "number of keystrokes to perform the equivalent of one mouse action" but it won’t be able to define "comparable access" since it would differ so much based on individual abilities to point or create keystrokes. User agent support for access keys is so bad that developers have started looking for server-side solutions that allow users to define access keys (see http://juicystudio.com/article/user-defined-accesskeys.php and http://juicystudio.com/article/user-defined-access-keys-aspversion.php). If you are aware of a good paper or application note on this we would be most interested.