Guideline 2.1 - "keyboard support" issue summary and proposals
Addressed by current edits or OBE
- does anything that supports MouseKeys address keyboard
Close this issue - Success Criterion 2.1.1 has been updated with a note
that explicitly indicates that MouseKeys does not satisby this
- 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.
- Replace "a sentence" with "text or words"
-Why is "described in a sentence" needed in Level 1 SC?
- Examples needed and clarity needed around Guideline 2.1 SC 1.
- 2.1 L1 SC1 that can be described in a sentence
- 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 .
- Explain "focus-in, focus-out", define "focus" in example 1
'API of the environment' too technical
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
- 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."
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
- keyboard interface
Close this issue. Was an editorial issue with 6/30/2005 draft -
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.
- previous survey about 2.1 before June 2005 Face to Face:
- minutes from June 2005 face to face:
Suggest rejecting and closing
- 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
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
- Divvying up responsibility for keyboard access
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.
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
- Cell phone example comments
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
- cell phone examples have been removed, close the issue
- Add an additional example and close this issue
- prefer 1.0 approach: "device-independence" is more strict
GL 2.1 Guideline should promote device independence
Close issues 986 and 1738. - A note was added to SC 2.1.1, "Note:
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
Suggest leaving open
- 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.
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:
- change the text of the criterion to replace "is
designed to be operable" with "is operable" This would change
the 2.1.2 success criterion FROM, " All functionality
of the content is designed to be operated through a keyboard
TO, "All functionality of the content is operable through a keyboard
interface.". This better matches the intent section of the
meet 2.1.2 document which states, "his is the same as the success
criterion 2.1.1, but no exceptions are allowed: all
content is operable from the keyboard.". Note that this intent
uses "operable" rather than "designed to be operated."
- determine that "is designed to be operated" is an essential part
of the success criterion and update the how to meet document for 2.1.2
to explain the use of that terminology.
- 2.1 L3 SC1 fold into 2.1 L1 SC1
- 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.