Document by Yvette Hoitink and Roberto Scano
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20050601
This is the list of the issues for Guideline 2.1 issue list. There are no pending issues, but there are 27 open issues.
There are 27 open issues.
Issue #561 URI | WCAG Bugzilla Issue #561
The U.S. Access Board writes:
We agree that a webpage should be navigable by keyboard commands. However, there is always the issue of how much keyboard access is the responsibility of the webpage designer versus the capability of the specific browser being used by the person accessing the page.
Issues addressed in summary proposal available posted to:
http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JanMar/0158.html
If there are user agents that support the technologies you are using and that meet principle 4, and the user agents+content meet guidelines, then author should not do anything further. However, this idea needs more work. Clear that if UA does it, author doesn't have to.
isn't that "until user agents" said differently? reminiscent of baseline discussions and mapping to UAAG 1.0 conformance profile" from minutes from 8 January: http://www.w3.org/WAI/GL/2004/01/08-minutes.html#Guideline.
I think that the actual wording of Level 1 and Level 3 SC but the problem still in the baseline: how can we guarantee a full keyboard accessibility: giving all responsability to the web developer about the creation of the content that should be device-independent or asking to the assistive technologies creators to implement conform tools? It's the author's responsibility to make sure the content isn't designed to operate with a mouse only. It's the user agent's responsibility to provide keyboard operability for all the device independent functionality such as following links etc.
Issue #681 URI | WCAG Bugzilla Issue #681
Two issues from Greg Lowney about a require of rewording for example 2 title and about the java applets conformance.
30. Principle 2 "All functionality is operable at a minimum through a keyboard or a keyboard interface" and "Example 2: examples of Web content that would and would not be operable from a keyboard or keyboard interface"
30.a. [HIGH PRIORITY] I just want to make sure that I'm clear on this: according to my interpretation of this guideline and its checkpoints, it seems that ALL Java applets would comply with this guideline because they can be run on platforms that support the MouseKeys feature. That is, the guidelines do not seem to require that the product to be easily used with a keyboard, or in fact to take any steps that would accommodate keyboard users. Is this your intention?
Can you provide any other examples of things that would fail to meet this criterion? (I noticed that an earlier draft of this document noted that the editors were going to try to create some tests that would require more than just MouseKeys to pass.).
First issue need clarification in our text for the examples.
We need to discuss about the second point: Greg Lowney position is right, due that Java Applets will comply to this guideline thanks to MouseKeys feature (where supported).
We need to reformulate the SC so that it is clear that mousekeys do not count as a keyboard interface. Mousekeys require a visual feedback to work which blind users don't have.
Issue #799 URI | WCAG Bugzilla Issue #799
(Andi Snow-Weaver): example 2, second unnumbered list item - the Web content should be operable via the keys on the cell phone keypad, regardless of whether or not the cell phone supports the attachment of an optional keyboard.
A better example here might be a PDA device that is usually operated via a stylus but has an optional keyboard that can be attached. The Web content should be operable using the attached keyboard. In this example and all of the others listed under Example 2, it is ambiguous what the content author's responsibility is here. For example, a Palm Pilot supports an attached keyboard but I think the Palm OS only supports data entry via the keyboard, not navigation. If the Palm OS and browser don't support navigation via the optional keyboard, it is impossible for the content author to provide this function. These examples should either be clarified as to the content author's responsibility or removed altogether.
I suggest to put a note after the examples regarding that said something about the author responsibility: if an author generates web content with respect of keyboard access, the page conforms even if the device used by the user doesn’t have keyboard support or keyboard emulation (this means that is not Section 508 conform: what are the hardware that don’t conform to section 508 today?).
Issue #826 URI | WCAG Bugzilla Issue #826
Ask to modify “who Benefits from Guideline 2.1 (Informative)”
Suggested Addition: Keyboard operation also benefits advanced users as they can access information more quickly then regular navigation usually facilitates.
I agree with the suggestion due that keyboard shortcuts and navigation is always used also by skilled users. However, we decided to only list benefits to people with disabilities to make the guidelines more credible. Usability benefits for regular users do not belong in the accessibility guidelines. We propose to explain this to the original poster and close this issue.
Issue #858 URI | WCAG Bugzilla Issue #858
AbI-Project (Aktionsbuendnis für barrierefreie Informationstechnik) wrote:
(30) 2.1.1.1: Access keys (keyboard shortcuts) could be automatically assigned by the user agent, to avoid platform-specific conflicts. Is this right?
Access keys (keyboard shortcuts) could be automatically assigned by the user agent, to avoid platform-specific conflicts?
Accesskey cannot be automatically assigned by the user agent, due that the UA should know all the keyboard mapping keys for all the active applications. There is still an issue about accesskey.
UAAG 1.0 does not require such functionality from user agents. All UAAG 1.0 says (at level 2) is that the user should be able to override the keyboard configuration and should be allowed to configure a single key binding. Because automatic assignment of accesskeys is not covered in UAAG, we cannot rely on it. I propose to explain this to the ABI and close this issue.
NEW | WCAG Bugzilla Issue #874
US Access Board comments:
Principle 2: Interface elements in the content must be operable.
Comment: This is incomplete. Even though the paragraphs that follow explains how to accomplish this principle, the principle, as stated, sounds like stating the obvious. Why would someone develop elements that were not operable. There needs to be some phrase added that more clearly states the
goal of this principle.
US Access Board propose an example of rewording: "Principle 2: Operation of interface elements in the content must not be dependent on a single input device."
The proposed formulation suggests that you should always support more than 1 interface, which isn't necessary. Just having a keyboard interface is enough.
NEW | WCAG Bugzilla Issue #875
US Access Board comments for Guideline 2.1: “Make all functionality operable via a keyboard or a keyboard interface”.
Not everyone can use a keyboard, maybe the concept of redundancy needs to be placed here.
Agree with access board: we refer to keyboard for screen reader and for some assistive technologies. The fact that other devices may be supported as well has been explained in a note. We propose to close this issue.
NEW | WCAG Bugzilla Issue #876
The US Access Board, Harvey and Catherine Brys about some rewording proposal for Level 1 Success Criteria for Guideline 2.1 especially for “functionality of the content, where the functionality or its outcome can be described in a sentence, ...”
US Access Board: This is parallel to the 508 1194.21(a) requirement. We would suggest replacing the words, "a sentence" with "text or words. The description of the functionality or outcome does not have to be a complete sentence.
Harvey: In "where the content or its outcome can be described in a sentence," I have no idea what "described in a sentence" means here!
Catherine Brys: "where the functionality or its outcome can be described in a sentence". Is this qualifier quite accurate and to the point? What is meant with the functionality of the content? Whether or not the functionality can be described in one sentence will depend on the writing skill of the content author - is this testable? Different people will definitively come up with different options on whether content meets this guideline. Is the one-line limit useful?
'Can be described in a sentence' was meant as a meassure of the complexity of the functionality. We would only require keyboard operability for simple functionality at level 1, and for all functionality at level 3. Replacing this with 'text or words' wouldn't work because that doesn't say anything about the complexity anymore.
However, since so many people have problems with this concept, and because complexity of functionality cannot be defined in a testable manner, we propose to drop the entire notion and just require keyboard operability at level 1.
NEW | WCAG Bugzilla Issue #877
Clarification asked for Level 2 Success Criteria for Guideline 2.1 (“Wherever a choice between input device event handlers is available and supported, the more abstract event is used.”) by US Access Board, James Craig and Catherine Brys.
All asked clarification and examples about “more abstract”.
This SC sounds more like a technique than a success criterion. We need to reformulate it focusing on device independence and add an example.
NEW | WCAG Bugzilla Issue #878
US Access Board asked clarification about Keyboard – Keyboard interface for Level 3 Success Criteria for Guideline 2.1 (“All of the functionality of the content is operable via a keyboard or keyboard interface.”).
If the functionality is available through a keyboard interface, by definition isn't it available via a keyboard?
We can act in two different mode:
To make it clear that we want keyboard operability not only for users that depend on a keyboard but only for a variety of users that depend on a keyboard interface to use other assistive technologies, we propose to go with the second option and only refer to 'keyboard interface' instead of 'keyboard or keyboard interface'.
Issue #940 URI | WCAG Bugzilla Issue #940
A rewording proposal from James Craig for Level 1 Success Criteria for Guideline 2.1 (“All of the functionality of the content, where the functionality or its outcome can be described in a sentence, is operable through a keyboard or keyboard interface.”).
Propose to change this sentence with: “All of the functionality of the content is operable through a keyboard or keyboard interface.”
Fully agree and support it. This means deleting the lvl 3 SC because that's redundant.
Issue #941 URI | WCAG Bugzilla Issue #941
A James Craig mark-up suggestion for level 1 success criteria notes.
The list of three "notes" should be an ordered list (lower alpha) to remain consistent with rest of document.
Editorial note. Should be fixed.
Issue #942 URI | WCAG Bugzilla Issue #942
A James Craig note for redundant text for Example 2, first bullet: If it's written to be operable from a computer keyboard, it conforms (because it is operable from the keyboard.).
The parenthesized portion is redundant and should be removed.
Proposal
Agree with Craig. New text should be: “If it's written to be operable from a computer keyboard, it conforms.”
Issue #986 URI | WCAG Bugzilla Issue #986
RNID said that Guideline 2.1 appears to introduce an element of device-dependence by specifying that a keyboard or keyboard interface must be used. In general, WCAG version 2.0 appears more specific about input modes and, as a result, less strict in this area than WCAG version 1.0, which stipulated that the content provider should “design for device-independence”.
A more general wording, requiring that alternative input modes be supported, would be appropriate here.
At level 1, providing keyboard operability is enough. At level 2, we want to require designing for device independence. For 2.1 we suggest “Where possible for the chosen technology, use device-independent event handlers.”.
Issue #1015 URI | WCAG Bugzilla Issue #1015
Andy Budd writes regarding Guideline 2.1 and about browser / web designer responsibility. Andy said that the checkpoint is subjective.
For instance, if a web browser doesn't support tabbing between links or form elements, it's beyond the site developers ability to do anything about it.
Site developer should implement the keyboard navigation: if a browser doesn’t support tabbing between links or form elements, the browser is not usable by assistive technologies so is a UA issue, not a WCAG Issue. Perhaps we could expand the definition of functionality to make sure we require keyboard operability only for functionality that is provided by the author, not user agent functionality such as tabbing through links.
Issue #1040 URI | WCAG Bugzilla Issue #1040
Harvey writes about voice command for Level 3 criterion.
Why omit the alternative voice command?
Voice command can be a good alternative input method. We could either put it at level 3 or in the guide for 2.1. We propose to put it at level 3 to see how people feel about that.
Issue #1041 URI | WCAG Bugzilla Issue #1041
Harvey ask to add some text for “Who Benefits from Guideline 2.1 (Informative) “ for second point in the list: “Individuals with severe physical disabilities can use speech input (which simulates keystrokes) to both enter data and operate the interface elements on the page.”
In "who benefits" add the phrase "or commands" to "(which simulates keystrokes or commands) to both enter data and operate the interface elements on the page"
Agree, this helps also other devices like vocal input.
Issue #1042 URI | WCAG Bugzilla Issue #1042
Harvey ask to clarify some words in example 1: operation with multiple input devices. “The content relies only on focus-in, focus-out, and activation events; these are defined in the API of the environment for which the content is written, and are intended to be operable by a variety of input devices, including pointing devices, keyboards and speech input systems.”
In Example 1, explain "focus-in, focus-out" and add "focus" to the Glossary.
Agree. We have some definition of “focus” in the WAI program:
§W3C WAI Authoring Tools Accessibility Guidelines 1.0: The focus designates the active element (e.g., link, form control, element with associated scripts, etc.) in a view that will react when the user next interacts with the document.
§W3C WAI User Agent Accessibility Guidelines 1.0: Content focus designates an active element in a document. User interface focus designates a control of the user interface that will respond to user input (e.g., a radio button, text box, menu, etc.). At all times, only one content focus or one user interface focus is active, called the current focus.
Issue #1043 URI | WCAG Bugzilla Issue #1043
Harvey writes in reaction to the Level 3 criterion, "All functionality of the content is designed to be operated through a keyboard or keyboard interface."
Another alternative for functionality is voice command, which need not be a keyboard equivalent.
This is a duplicate of issue 1040.
Issue #1090 URI | WCAG Bugzilla Issue #1090
Two issues about needed clarification for SC Level 1 - this is confusing as worded. Some interpreted this as not allowing for device specific content for a device that does not have a keyboard. For example, a one-way communication system that pushes messages to users but does not require interaction.
Suggest rewording as "When the content provides interactive functionality, all of the functionality is operable through a keyboard or keyboard interface where the functionality or its outcome can be described in a sentence."
See also issue 940 (“All of the functionality of the content is operable through a keyboard or keyboard interface.”). We could mix these two proposal: “When the content provides interactive functionality, all of the functionality of the content is operable through a keyboard or keyboard interface.”. However, that makes the text a lot harder to understand. Alternative would be to add 'interactive' as an adjective: "All of the interactive functionality of the content is operable through a keyboard or keyboard interface.
Issue #1210 URI | WCAG Bugzilla Issue #1210
It's not clear what the difference is between the Level 1 and Level 3 Success Criteria 1.
§SC Level 1 and 3 - need to provide an example that demonstrates the difference between these two
§Does Example 1 demonstrate how Level 3 criteria is met and Example 2 demonstrate how Level 3 criteria is met?
§It would be very helpful if every Example in each Guideline identified which Success Criteria it was meeting.
We propose to delete the 'can be expressed in a sentence' part of the level 1 success criterion which makes the level 3 criterion obsolete and we can close this issue.
Issue #1211 URI | WCAG Bugzilla Issue #1211
Regards Example 2 and keypad that isn’t considered as a keyboard but a keypad is a type of keyboard; you can use the keypad on a cell phone, for example, to type messages to your friends using the keypad. A Blackberry, among other products, even provides its own mini keyboard.
A definition of keyboard should be add to make clear what is and isn't considered to be a keyboard.
This proposal is also inside the issue. There is a definition of keyboard from webopedia: www.webopedia.com/TERM/k/keyboard.html.
Issue #1227 URI | WCAG Bugzilla Issue #1227
Action items from October 2004 face to face to complete issue summaries for various categories of open issues related to WCAG 2.0
Todo
Todo
Issue #1340 URI | WCAG Bugzilla Issue #1340
John Moore question about Level 2 Success Criteria for Guideline 2.1 (“1. Wherever a choice between input device event handlers is available and supported, the more abstract event is used. [I]”).
Need clarification: unable to determine the meaning of "abstract event" in this context.
Duplicate of issue 877. Should be merged.
Issue #1378 URI | WCAG Bugzilla Issue #1378
Catherine Brys comment about Level 1 Success Criteria for Guideline 2.1 and Level 3 Success Criteria for Guideline 2.1.
What is the difference between 'is operable' and 'is designed to be operated'? In theory, there can be a difference between whether keyboard use was considered during the design or not but what matters is the end result - not the intentions of the designer. Also, considering keyboard use at the design stage does not mean that the resulting solution is usable at all.
In our proposal we delete the level 3 SC which gets rid of this confusing difference in formulation.
Issue #1379 URI | WCAG Bugzilla Issue #1379
Catherine Brys writes regarding Guideline 2.1, Example 1 (“The content relies only on focus-in, focus-out, and activation events; these are defined in the API of the environment for which the content is written, and are intended to be operable by a variety of input devices, including pointing devices, keyboards and speech input systems.”).
She thinks that 'API of the environment' is too technical a term.
Add a definition of API and of environment (see ATAG and UAAG 1.0 glossary)
Issue #1380 URI | WCAG Bugzilla Issue #1380
Catherine Brys writes regarding Guideline 2.1, Example 2
'If it's written' > what does 'it' refer to?
It refers to “examples of Web content”: should we clarify?