This document:Public document·Annotated document·View comments·Search comments·Add a new comment·Send replies to comments·Disposition of Comments·
Nearby:Web Content Accessibility Guidelines Working Group
Other specs in this tool
Web Content Accessibility Guidelines Working Group's Issue tracker
Quick access to LC-2426
There are 45 comments (sorted by their types, and the section they are about).
Is there a reason why Technique H82 is missing from the latest versions or is this an oversight?
Comment (Including rationale for any proposed change):
It should have links to SC 1.2.4 documents as G93 is listed as one of the sufficient techniques on Understanding SC 1.2.4.
Is "WAI(Web Accessibility Initiative)" NOT acceptable to meet SC 3.1.4? This also can be used "to make the expanded form of an abbreviation available by associating the expanded form with its abbreviation". In Japanese, this is usually used to provide its expanded form.
If acceptable, please add the description to G97. If not acceptable, JIS might need to have different criterion from WCAG 2.
Comment (Including rationale for any proposed change):
Procedure #1 reads "Check that a procedure and policy is in place to ensure that text alternatives are delivered in real-time." Does this technique require having the procedure and policy only? Can we meet SC 1.2.9 by only having them? This technique should ensure that the text based alternatives for live audio-only content are provided.
I believe SCR 19 helps one to comply with SC 3.2.2 too.
SCR19: Using an onchange event on a select element without causing a change of context
At present this technique is only linked to SC 3.2.5. But if one reads the description and examples for SC 3.2.2, the need for the suggested linkage will be clear.
Expected Results should be "#3 is true." as well as SM6.
Change it to read "#3 is true."
The behaviour described in F9 - changing context such as opening new windows or submitting the form - also seems to apply to the requirements of SC 3.2.2 "On Input".
The behaviour described: "removing focus from a form element, such as by moving to the next element, causes a change of context" is arguably even more disrupting than the more specific Failure F36: "Failure of Success Criterion 3.2.2 due to automatically submitting a form and presenting new content without prior warning when the last field in the form is given a value" - in the latter, the form might at least have been completed.
Extend applicability of F9 to SC 3.2.2 On Input AND SC 3.2.5 Change of Request
Opening a new window as a result of user text input is clearly an unexpected change of context and would seem to violate not just SC 3.2.5 (Change on Request) but also the A-level SC 3.2.2 (On input)
* Preferably, make F60 applicable also to SC 3.2.2 (On Input)
* Specify that the change in response to text input should be expected / explained before it occurs, include that in the test procedure
* Differentiate between opening a new window proper (i.e., a browser window) and opening a pseudo-window (e.g. a lightbox) which would not necessarily constitute a (disorienting) change of context
Procedure #2 reads "leave the content open for 24 hours". I can live with this, but leaving the content open for 24 hours is not a realistic way. 1 hour or even half an hour would also be fine.
Why "24 hours"?
Had better change it so that the authors can test the content in reality.
It might be useful to clearly indicate the definition of the words "should" and "must" for the purpose of requirements versus recommendations. This would apply to all parts of WCAG 2.0. I mentioning it here on this technique (G141), because this is where I recently had a debate about what "should" means versus what "must" means.
Make it obvious that "should" is recommended while "must" is required. You could use the definitions found at http://www.ietf.org/rfc/rfc2119.txt. You could also consider making the words "must" and "should" hotlink to the definition. Or, not. Just an idea.
I think it is time that G1 along with the "NOTE:" at the end of the description be modified and made more forceful. Presently, it does not give the impression that the "Skip to..." MUST be visible. I would like to see the description reworded to make it more assertive.
Currently, G1 with the note (and the ensuing wording), comes across as a weak technique.
The objective of this technique is to provide a mechanism to bypass blocks of material that are repeated on multiple Web pages by skipping directly to the main content of the Web page. The first interactive item in the Web page is a VISIBLE link to the beginning of the main content. Activating the VISIBLE link sets focus beyond the other content to the main content. This technique is most useful when a Web page has one main content area, rather than a set of content areas that are equally important.
Note: VISIBLE LINKS MUST BE VISIBLE AT ALL TIMES, ESPECIALLY for KEYBOARD USERS. KEYBOARD USERS INCLUDE switch users, those using techniques that generate keyboard strokes slowly, screen magnification software users, screen reader users working with sighted colleagues, keyboard only users and those navigating using voice recognition software.
Update on my earlier post - G1: Adding a link at the top of each page that goes directly to the main content area
I think the verbiage with the word "Must" would be incorrect in my previous post.
Sorry about that...
please note the updated text (changes highlighted in UPPERCASE):
The objective of this technique is to provide a mechanism to bypass REPETITIVE NAVIGATION MENUS AND OTHER PAGE ELEMENTS on multiple Web pages by skipping directly to the main content of the Web page. The first interactive item in the Web page is a VISIBLE link to the beginning of the main content. Activating THIS link sets focus INTO ONE OF THE PAGE ELEMENTS IN THE main content AREA. This technique is most useful when a Web page has one main content area, rather than a set of content areas that are equally important.
Note: Visible links are IMPORTANT for USERS navigating with a keyboard including switch users, those using techniques that generate keyboard strokes slowly, screen magnification software users, screen reader users working with sighted colleagues, keyboard only users and those navigating using voice recognition software.
I have noticed a discrepancy between Technique "G68: Providing a descriptive label that describes the purpose of live audio-only and live video-only content" and the test included at its end.
While the technique proposes the use of descriptive labels which are exposed to sighted users, the test at the end checks for text alternatives for non-text content that would only be exposed if the not-text content cannot be displayed.
I think the currently included test does not apply to the technique as described.
Check whether descriptive label matches / correctly describes live audio-visual content
The first of the conditions may not apply (for example if the for is on one page). The second condition ("Determine if a summary of all data input by the user is provided before the transaction is committed and a method is provided to correct errors if necessary.") must be met in any case to ensure that input is checked and may be corrected. Therefore "Expected Results: Either #1 or #2 is true" seems inadequate.
1. If user data are collected in multiple steps, the user is allowed to return to previous steps to review and change data.
2. Determine if a summary of all data input by the user is provided before the transaction is committed and a method is provided to correct errors if necessary.
Checks #1 and #2 are true.
To remove the conditional (and possibly confusing) 'if'-clause at the beginning of check #1, the single test might need to be turned into two separate tests.
As it stands, the test in technique G166 only checks whether a link to the audio alternative is provided. It does not check the equivalence of the audio alternative. Testing just for the link is not sufficient
Add a second checkpoint #2 for checking whether the audio alternative is adequate.
Both Check #1 and Check #2 must be true.
The text of this technique describes in both examples provided that the styleswitcher should be at the "top of the page". This requirement, however, is neither included in the description nore is it checked in the test section of the technique.
Add a further (fourth) requirement for the technique to be used successfully, preferably in second place:
"2. The link or control on the original page must be placed at the top of the page"
The test as it stands is not particularly useful as it does not specify the viewport size, which will have an effect on scalability and occurrence of clipped text and text overlapping. It also does not specify what it means that "text size can be increased to 200% of the original size" - is the requirement that the text is still legible / not clipped?
If the test is to determine whether enlarged text is still usable / legible (and this is the only meaningful test), the viewport / window size to be used in the test must be specified (WAT and Web developer toolbar allow the setting of the window to 1024 x 768 px, for example), and criteria for compliance must be given (e.g. "the text is still fully legible (i.e. no parts are clipped, boxed do not overlap).
In addition to the comment regarding the test case spec. in G178, it should be noted that for most web pages using several columns, the requirement for a 200% increase of text size will be impossible to meet (the same goes for browser based text-only resizing) and is therefore likely to be ignored. Such ignorance is helped by the interpretation of alternative options to meet Success Criterion 1.4.4 (Resize text), since option 1 (G142) suggests that supporting zoom resizing (which most modern browsers offer out of the box without any effort by the designer) is already sufficient. This appears as a disincentive regarding the provision of text-only resizing and the additional effort of creating fluid layouts that resize gracefully.
The (additional) requirement to allow a more modest text-only resizing (say, 150%) might raise the bar in a meaningful way and not de-incentivise designers in the same way as the current all-to-easy way of meeting success criterion 1.4.4 *without any effort*.
Following the provision of Technique G4: "If keyboard shortcuts are used, they are documented" the test in G187 should include a check whether the function to turn off blinking content is documented (e.g., press the "Escape" key to turn off blinking)
Add a fourth checkpoint and extend the final statement:
4. Check if the browser's stop animation command (usually the Escape key) is described in the immediate context of the blinking content.
Check #3 and #4 are true.
The example of technique G191 makes it clear that the link or mechanism to load a non-blinking version of the page should be at the top of the page:
"A link at the very top of the page reloads the page with the blinking text replaced with text that is styled to be highly visible but does not blink"
Include a check that the mechanism is located at the top of the page - placed elsewhere, it is not helpful. Instead of
"1. Check that there is a mechanism to reload page to turn off blinking."
"1. Check that there is a mechanism at the top of the page to reload page to turn off blinking.
See old exchange on this topic below.
Now I refer to Techniques working draft (latest) of Oct 2010.
H42 refers to proper use of headings for SC 1.3.1 and H69 for use of headings to skip blocks (SC 2.4.1).
But part of the description under H69 which was correctly placed under h42 is now moved to h69... and is completely out of place.
"In some technologies, headings are designed to convey logical hierarchy. Skipping levels in the sequence of headings may create the impression that the structure of the document has not been properly thought through or that specific headings have been chosen for their visual rendering rather than their meaning. Authors are encouraged to nest headings hierarchically. When headings are nested hierarchically, the most important information is given the highest logical level, and subsections are given subsequent logical levels.(i.e., h2 is a subsection of h1). ..."
Again this Web page is about HTML techniques so why does this description start with "In some technologies"? Does it apply to HTML / XHTML or not?
And the note for example #2 of H42 refers to skipping blocks of content.
"Note: It is important to note that the example code below is intended to show how headings can be used to bypass blocks of information. It is not intended to prescribe what level of heading should be used for a particular section of the web page."
So why is this note and example under H42?
Completely out of place again.
The technique is one and the same: proper use of headings. And it serves two purposes and SCs. So merge the techniques into one instead of running around in circles. I had suggested this in 2009.
There are several techniques that refer to multiple SC. So I fail to understand your resistance for this one.
Web Accessibility Specialist
--- On Mon, 12/1/08, Loretta Guarino Reid <firstname.lastname@example.org> wrote:
From: Loretta Guarino Reid <email@example.com>
Subject: Re: HTML Headings technique: duplicated
To: "Sailesh Panchang" <firstname.lastname@example.org>
Date: Monday, December 1, 2008, 5:58 PM
On Fri, Nov 14, 2008 at 1:23 PM, Sailesh Panchang <email@example.com> wrote:
H42: Using h1-h6 to identify headings
relates to SC 1.3.1
H69: Providing heading elements at the beginning of each section of content
relates to SC 2.4.1
Comment: Both descriptions are essentially the same. I suggest they be merged into a single technique and reference both SC
Response from the Working Group
H42 should describe the use of heading mark-up to label headings semantically, but also contained a good deal of discussion about how to use headings. We have moved the discussion and examples of ways to use headings to organize content from H42 to H69. See http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-TECHS/H42.html and http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-TECHS/H69.html .
Add a comment.