Guideline 2.1 - "keyboard support"  issue summary and proposals

Addressed by current edits or OBE

#681 - does anything that supports MouseKeys address keyboard operation?

Close this issue - Success Criterion 2.1.1 has been updated with a note that explicitly indicates that MouseKeys does not satisby this criterion.  

#875 - Comment that, "Not everyone can use a keyboard, maybe the concept of redundancy needs to be placed here."

Close this issue - Success criteria 2.1.1 and 2.1.2 have been updated to use the term "keyboard interface" rather than just "keyboard". The term "keyboard interface" has been defined in the WCAG glossary. 

#876 - Replace "a sentence" with "text or words"

#940 -Why is "described in a sentence" needed in Level 1 SC?

#1090 - Examples needed and clarity needed around Guideline 2.1 SC 1.

#1619 - 2.1 L1 SC1 that can be described in a sentence

#1739 - GL 2.1 L1 - questions restriction "described in a sentence"

Close  issues 876, 940, 1090, 1619, 1739 - SC 2.1.1 has been rewritten so that "a sentence" is no longer used.  The new wording includes,  "except where the task requires analog, time-dependent input" which is what was trying to be captured with the original, "described in a sentence" wording.  All of these issues raised concern about the wording of the success criterion.  I believe that the new wording addresses all of the issues.  The examples have also been updated .

#1042 - Explain "focus-in, focus-out", define "focus" in example 1

#1379. 'API of the environment' too technical

#1380. Ambiguous wording of GL 2.1, example 2

Close issues 1042, 1379, 1380 - the examples for SC 2.1.1 have been rewritten and  no longer contain the terminology referred to in these issues.

#1210 - 2.1: what is the difference between level 1 and level 3 SC?

Close this issue: The  2.1.1 and 2.1.2 Success criteria have been rewritten since this issue was opened. Also, the "How to Meet" document for 2.1.2 states that, "no exceptions are allowed: all content is operable from the keyboard."

#1211. 2.1: why isn't a keypad considered a keyboard?

Close this issue:  The 2.1.1 and 2.1.2 success criteria have been updated to include "keyboard interface" which should cover this issue. 

#1620 - keyboard interface

Close this issue. Was an editorial issue with 6/30/2005 draft - GL doc had what is now 2.1.2 at L2 but General Techs had it as L3.  >From what I can see by looking at previous versions, this SC has always been at level 3 in WCAG 2.0.  General Techniques document will no longer be used in its current format. 

#874-  Suggested rewording for Principle 2

Close this issue:  The GL text has been updated since this issue was opened.  I believe new GL text addresses the issue raised that the original text was too generic and obvious. See background info for URLs with more information. 

Background info:



Suggest rejecting and closing


#1700 - Usability issues in keyboard access

Raises issue that tab order is not easy to determine and that user agents do not often highlight the item with focus in a very noticible manner.  Wants those issues  covered in 2.1 success criteria. 
Propose closing since the issue of making focus visible is a UA issue.  Lack of tab positions is already  covered by  this SC - author must use the proper elements and attributes to  ensure keyboard access.
Alternative:  Could include advisory techniques for marking the item with focus using CSS and onfocus/onblur handlers but I'm not sure that belongs with this GL. 

Suggest closing with proposed changes

#561 - Divvying up responsibility for keyboard access

#1015. If the browser doesn't support tabbing, what is the author to do?

Update the intent section to discuss author responsibility and user agent responsibility, then close issues 561 and 1015.
Proposed additional paragraph to intent section of how to meet document:
The author is responsible for adhering to the keyboard interface of the targeted user agents.   In order to meet UAAG, a user agent must meet Priority 1 checkpoint 1.1: Full keyboard access. (http://www.w3.org/TR/2002/REC-UAAG10-20021217/guidelines.html#tech-device-independent-ui). Thus, most user agents should have keyboard access mechanisms available for the Web content author to use and the author should follow those conventions.  As long as the author has followed the conventions of the technology, this success criterion is met.  It is the responsibility of the user agent to correctly implement the keyboard interface.  The author is encouraged to work with user agents and technologies that provide complete keyboard interface support.   In addition, authors should be aware of WCAG 2.0 success criteria 4.2.2, keyboard requirments for technologies outside of the selected baseline.  

#799 - Cell phone example comments

2 alternatives:
Proposed Example: A cell phone application delivered via the internet must be operable via the cell phone keypad and not require an external keyboard device attached to the phone.  (If accepted, the examples will need to be renumbered so this new example comes before the exception examples).

#986 - prefer 1.0 approach: "device-independence" is more strict

1738. GL 2.1 Guideline should promote device independence

Close issues 986 and 1738.  - A note was added to SC 2.1.1, "Note: This does not preclude and should not discourage the support of other input methods (such as a mouse) in addition to keyboard operation."  Although I am not sure that addresses the author's concerns completed. We have discussed this SC a fair amount and I think the group believes that keyboard interface support covers the most important issues.  See http://www.w3.org/WAI/GL/WCAG20/wcag20-punchlist.html and http://www.w3.org/2002/09/wbs/35422/keyboardop20050607/results.


Suggest leaving open

#941 - Format notes in Level 1 SC as a list

This is a minor formatting issue.  Leave open for now until final format of document is determined.

#1378. Difference between 'operable' and 'is designed to be operated'

Good point - the wording of the 2.1 SC are different but the How to Meet documents are the same.   Suggest keeping open while we evaluate the following possibilities:

#1621 - 2.1 L3 SC1 fold into 2.1 L1 SC1

#1740 - GL 2.1 L3 SC 1 should be Level 2

Suggest discussing the level within the  Working group.  I believe this  has been discussed and the group agreed to leave 2.1.2 at level 3 since this is a high bar for some technologies.    Unfortunately I can't find these dicussions in the minutes so may need to reopen the issue.