List of comments on “Understanding WCAG 2.0” (dated 3 January 2012)

There are 31 comments (sorted by their types, and the section they are about).

1-20 21-31

question comments

Comment LC-2607: Headings: Commenter: Steve Miller <steve.miller1@defence.gov.au> (archived message); Context: Info and Relationships: Understanding Success Criterion 1.3.1; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Could someone please advise whether a page containing two <h1> tags is WCAG2 compliant?

Technically to follow the principles of semantic markup and a hierarchical structure, a <H1> tag should not be the child of another <H1> tag.

Also and probably more important (the subject of many robust discussions) - can site navigation elements be marked up as headings? This seems to fail WCAG2 compliance as the navigation heading technically does not belong to (is a child of) the Content heading. Although useful having a list of navigation elements available through the headings, if a user is not familiar with the site then they are unlikely to differentiate content from navigation, or at least find it very confusing.; Related issues: (space separated ids); WG Notes:; Resolution: WCAG does not require strict hierarchy in headings. Techniques H69 "Providing heading elements at the beginning of each section of content" and G141 "Organizing a page using headings" encourage the use of headings in a hierarchical manner, but WCAG 2.0 does not require it. Using two <h1> headings would not violate any of the success criteria, so WCAG conformance would not prohibit it. Success Criterion 1.3.1 requires that if headings are used, they be marked up as headings. It does not require that headings be used at all, or that they be used in any particular way. If the author used heading level to emphasize the importance of a topic, for instance, but did not create sections hierarchically, the content can still meet WCAG, since equivalent information is exposed to everyone. RE Navigation and Headers We are presuming that you mean that somebody marked up a header as a link. Is this correct? If assistive technologies such as screen readers do NOT announce the link along with the header then this would be a failure of 1.3.1 since information that was presented visually was not also readable and presented by AT. If assistive technologies such as screen readers DO announce it as both a header and a link then, although it may not be the best design, it would not fail WCAG 2.0. For example a header might be used to provide a link to a longer version of the paragraph under the header. While it might be a better design to provide a link at the end of the paragraph using the header as a link would not violate WCAG 2.0. Current screen readers support this style of markup. The content is interpreted both as a heading and a link.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2717: WCAG 2.0 - 2.4.1 Bypass Blocks: Commenter: Kristjan Kure <kristjanile@gmail.com> (archived message); Context: Bypass Blocks: Understanding Success Criterion 2.4.1; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Sufficient Techniques for 2.4.1 - Bypass Blocks states the following:

2. Grouping blocks of repeated material in a way that can be skipped, using one of the following techniques:

Year 2012

http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H50

Year 2008

http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H50.html

It's very unclear why 2.4.1 now only suggests using map element to group links. Does that mean web developers should start using only map element for main navigation?

Its not clear when and why to use map element (instead of ul for example). Should ul and ol used only when its more like a list and not a navigation item?; Related issues: (space separated ids); WG Notes: Reopened for further discussion. See https://www.w3.org/2002/09/wbs/35422/20121025misc/results#x2717 ==proposed response for 25 Oct 2012 @@Add H48: Using ol, ul and dl for lists or groups of links to sufficient techniques for SC 2.4.1 Thank you for drawing our attention to this error. In response to earlier comments, we consolidated the use of lists in a single technique, H48 Using ol, ul and dl for lists or groups of links. However, we neglected to update Understanding 2.4.1 to include this as one of the sufficient techniques. We will correct this in the next update.; Resolution: Thank you for your comment. The working group moved the ol/ul/dl aspects of H50 to H48 in order to have a single, consolidated list technique. For H50 this leaves only the example with the map element, and upon further investigation have decided to @@remove H50 entirely as there is not sufficient support for skipping over the map element to justify continuing this technique.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2748: If "skip to main" link is not the very first link/focusable item on a page, should I call a WCAG 2.0 violation?: Commenter: Glenda Sims <glenda.sims@deque.com> (archived message); Context: Bypass Blocks: Understanding Success Criterion 2.4.1; Status:
assigned to; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
We are working hard at Deque to make sure that our tools (FireEyes and WorldSpace) accurately interpret the WCAG 2.0 standard. A current debate on our team is the requirement for the location of the "skip to main" link for meeting 2.4.1 ByPass Blocks.

The normative part of WCAG 2.0 states:

2.4.1 Bypass Blocks: A mechanism<http://www.w3.org/TR/WCAG20/#mechanismdef> is available to bypass blocks of content that are repeated on multiple Web pages<http://www.w3.org/TR/WCAG20/#webpagedef>. (Level A)

In the informative "Sufficient Techniques" listed for 2.4.1, there is a technique listed:
G1: Adding a link at the top of each page that goes directly to the main content area<http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/G1>

In the procedure to test G1, the first step states:

1) Check that a link is the first focusable control on the Web page.

At this point...we are a long, long way from the "normative" part of the WCAG 2.0.

So, the clarification I seek is this? Should automated accessibility testing tools throw a WCAG 2.0 A violation on 2.4.1 if the "skip to main" link is anything other than the absolute first focusable item on the page?

My humble (personal opinion) is...the normative portion of WCAG 2.0 does not indicate that it must be the first link. So, I've never demanded that the "skip to main" link be the absolute first item on the page. However, WorldSpace and FireEyes are currently throwing an WCAG 2.0 2.4.1 violation if the "skip to main" link is not the very first focusable item on a page.

Can you tell me the proper interpretation so I can make sure our software is supporting the true intent of WCAG 2.0 2.4.1.; Related issues: (space separated ids); WG Notes:; Resolution: You are correct that failure to use one of the WCAG 2.0 Sufficient Techniques is not necessarily a failure of the success criterion. G1 and G124 are written to position the links as the first links on the page because the working group feels that is best practice, and to be encouraged. However, as long as there is some mechanism to skip blocks of repeated material, the success criterion has been met. The Understanding WCAG 2.0 document tries to make it clear in multiple places that the sufficient techniques documented by the WCAG WG are not the only techniques that might be sufficient to satisfy a success criterion. We have revised the language in the latest draft to try to make this even clearer.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2749: 2.4.1 Bypass Blocks - is it only required to meet one of the sufficient techniques?: Commenter: Glenda Sims <glenda.sims@deque.com> (archived message); Context: Bypass Blocks: Understanding Success Criterion 2.4.1; Status:
assigned to; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
I need clarification on 2.4.1 Bypass Blocks. Can you tell me if my interpretation is correct:

I think it is possible to pass WCAG 2.0 SC 2.4.1 by doing ONE of the following:

Creating links to skip blocks of repeated materials.
OR
Grouping blocks of repeated material in a way that can be skipped.

In other words, I think you can pick a single technique from either of these options and pass 2.4.1.

For example:

If Site "A" met "G1: Adding a link at the top of each page that goes directly to the main content area" , it would pass 2.4.1 (even if Site A did not employ anything that address "grouping blocks of repeated material in a way that can be skipped".

OR

If Site "B" met "H69: Providing heading elements at the beginning of each section of content", it would pass 2.4.1 (even if Site B did not employe anything that addresses "creating links to skip blocks of repeated materials".

I know this is a very narrow interpretation of WCAG 2.0 SC 2.4.1, and with all my heart I recommend it is a best practice to employ both headings and skip links, but the question at hand is...do I "fail" a site on WCAG 2.0 SC 2.4.1 if it doesn't have sufficient techniques for both "creating links to skip blocks of repeated materials" and "grouping blocks of repeated material in a way that can be skipped"?

Thanks in advance for your insight (as you might guess, the Deque Accessibility Experts are not in agreement in how to interpret this).; Related issues: (space separated ids); WG Notes:; Resolution: It is only necessary to meet SC 2.4.1 using one of the sufficient techniques listed in Understanding SC 2.4.1, that is, it is sufficient either to create a link to skip blocks of repeated materials or to group blocks of repeated material in a way that can be skipped. It is not necessary to do both. In fact you can also meet the success criterion without using either technique, if you find another way of meeting the success criterion. These are just two approaches that would be sufficient. But you are correct, either one by itself would be sufficient. We have added the following text to the paragraph preceding the list of sufficient techniques to make this clearer: "However, it is not necessary to use these particular techniques. Any techniques, whether published by the WCAG group or not, can be sufficient if a) they satisfy the Success Criterion and b) all of the WCAG 2.0 conformance requirements have been met."; (Please make sure the resolution is adapted for public consumption)

Comment LC-2608: Why is Focus Visible Level AA: Commenter: Gijs Veyfeyken <gijs@anysurfer.be> (archived message); Context: Focus Visible: Understanding Success Criterion 2.4.3; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
One more question about that. "Focus order" is a level A criteria. Hiding the visual outline is a failure of "Focus visible", which is a level AA criteria.
To be able to see the tab or "focus order level A" (for example sighted keyboard users), one much comply with "focus visible level AA".
If focus order cannot be achieved without focus visible, why are the not in the same level?; Related issues: (space separated ids); WG Notes:; Resolution: There are assistive technologies that can highlight the focus or add another highly visible focus indicator. Common user agents can also do this. For example in Firefox, setting the preferences browser.display.focus_ring_on_anything => true browser.display.focus_ring_width => 5 will allow override any page specified focus suppression and show a highly visible focus indicator on any focusable element. It should also be possible to do the same with a user stylesheet using !important. As a result Focus Visible is not at Level A. But assistive technology cannot add order if it is not there, so Focus Order is at Level A.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2603: Link text identical?: Commenter: Makoto Ueki <makoto.ueki@gmail.com> (archived message); Context: Consistent Identification: Understanding Success Criterion 3.2.2; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
I really appreciate all your help.

I'd like to ask you an additional question.

Should the link text be the same to meet SC 3.2.4 if they are the
links for the same resource?
Please see the CASE 1-2 and 3-2 below. Do they meet SC 3.2.4?

> CASE 1:
> <p>
> <a href="xxx.html><img src="xxx.png" alt="WCAG 2.0"></a>
> <a href="xxx.html>WCAG 2.0</a>
> </p>

CASE 1-2:
<p>
<a href="xxx.html><img src="xxx.png" alt="WCAG 2.0"></a>
<a href="xxx.html>About WCAG 2.0</a>
</p>

> CASE 3:
> <p>
> <a href="xxx.html><img src="xxx01.png" alt="WCAG 2.0"></a>
> <a href="xxx.html><img src="xxx02.png" alt="WCAG 2.0"></a>
> </p>

CASE 3-2:
<p>
<a href="xxx.html><img src="xxx01.png" alt="WCAG 2.0"></a>
<a href="xxx.html><img src="xxx02.png" alt="About WCAG 2.0"></a>
</p>; Related issues: (space separated ids); WG Notes:; Resolution: Proposed Response: They should be consistent but do not HAVE to be identical. In this case we would recommend that you make them identical so it was clear to the user that if they had visited one - that clicking on the second link with the exact same text would take them to the place they had already been. If they are slightly different, it might imply that what is at the other end is also slightly different. We are adding the following example to Understanding SC 3.2.4 to clarify: [Done] Example 5.5: Icon and adjacent link to same destination An icon with alt text and a link are next to each other and go to the same location. The best practice would be to group them into one link as per H2. However if they are visually positioned one above the other but separated in the source, this may not be possible. To meet the Success Criterion, the link text for these two links need only be consistent, not identical. But best practice is to have identical text so that when users encounter the second one, it is clear that it goes to the same place as the first.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2783: The text for the SC's intent is not worded right; the benefits are incomplete /mis-represented: Commenter: Sailesh Panchang (archived message); Context: Labels or Instructions: Understanding Success Criterion 3.3.2; Status:
assigned to; Type:; Comment:
As the Web page author if I placed 2 edit boxes for last and first name respectively (without any labels or instructions), will a sighted non-disabled user know what these controls are for and not make mistakes?
Simply put, the primary objective of the SC is to require labels or instructions that clearly convey what input data is expected in a form control.
In other words the purpose of the control should be clearly indicated.
By the very definition of the term label in WCAG2,
- the label is supposed to identify the component, the form control in this case.
- the label is supposed to be available to all users.
The intent skirts this altogether.
Then there are passwords that are valid without number or special character or upper case letter ... for different websites.
So anyone can make mistakes if the expected data format is not specified when it is out of the ordinary - nothing to do with "users with cognitive, language and learning disabilities".
Likewise, if required fields are not indicated, any user's form submission may fail.
Labels for form controls are not placed primarily to prevent users from making mistakes but to identify the control in the first place.
There are other SC that deal with error identification and recovery.
A significant benefit of explicit label association that helps some users click on a label to move focus into the field or check a checkbox / radio button is not mentioned at all.

Proposed Change:
Proposed wording:
The intent of this success criterion is to have content authors place instructions or labels that identify the controls in a form so that users know what input data is expected.
Instructions or labels may also specify data formats for fields especially if they are out of the customary formats or if there are specific rules for correct input.
Content authors may also choose to make such instructions available to users only when the individual control has focus especially when instructions are long and verbose.
It is customary to place labels to the left of (or above) text boxes. Labels for radio buttons / checkboxes are often to the right of the control.
There are specific benefits of using labels:
i. When label elements are associated with input elements:
- the label is spoken by screen readers when the field receives focus.
- users with impaired motor control are helped by a larger clickable area for the control, since clicking on the label or the control will activate the control.
ii. Field labels located in close proximity to the associated field assist users of screen magnifiers because the field and label are more likely to be visible within the magnified area of the page.
iii. Specifying data formats for fields where appropriate and identifying required fields increases the likelihood of successful first-time form submission.; Related issues: (space separated ids); WG Notes:; Resolution:; (Please make sure the resolution is adapted for public consumption)

general comment comments

Comment LC-2722: Sufficient Techniques for 1.1.1 - Non-text Content: Commenter: Kristjan Kure <kristjanile@gmail.com> (archived message); Context: Non-text Content: Understanding Success Criterion 1.1.1; Status:
assigned to Michael Cooper; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
I have checked HTML,CSS, Client-side, Server-side techniques and failures, all levels, Sufficient Techniques and Failures, Advisory Technique.

Techniques for 1.1.1 – Non-text Content

Techniques for short and long alternatives are really confusing and need regrouping and making clearer.

Please regroup/rewrite (Situation A, Situation B, Short text alternative techniques for use in sufficient techniques above, Long text alternative techniques for use in sufficient techniques above) so they are easy to learn/understand and reading order make sense.; Related issues: (space separated ids); WG Notes: See also https://www.w3.org/2006/02/lc-comments-tracker/35422/NOTE-UNDERSTANDING-WCAG20-20120103/2733; Resolution: The Sufficient Techniques section of Understanding SC 1.1.1 is extremely complicated and hard to follow. We have revised it to make it easier to understand. @@http://www.w3.org/WAI/GL/wiki/Restructuring_Understanding_1.1.1; (Please make sure the resolution is adapted for public consumption)

substantive comments

Comment LC-2585: Known failures should include setting main page container overflow to hidden preventing scrollbars: Commenter: Jon Avila <jon.avila@ssbbartgroup.com> (archived message); Context: in (Understanding Success Criterion 1.4.4); Status:
assigned to Adam Solomon; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
I've found a number of pages that set the main page container to overflow: hidden thus preventing horizontal scrollbars from appearing when resizing the page. Skittles.com is an example.

Add a new failure stating any technique that prevents scrollbars from appearing when the page is resized that also causes the text/content from being cut off would fail this success criteria.

Proposed Change:
Known failure: setting the overflow style to hidden on containing elements preventing scrollbars to appears when the page is zoomed up to 200% in the user agent.; Related issues: (space separated ids); WG Notes: (adam)Is this a failure? One can get to the hidden portion with arrow keys instead of scrollbars. Example 2 in the technique also does not fail with zoom. This is an example of F69. We are looking at F69 to see if it needs to be more specific. Detlev: Can't see the issue on skittles.com, has mainly images and little text (some tweets) that seems to scale OK, whether zoom or text-only. We should look (ask for?) for more real world cases where this causes problems. My suspicion is problems may arise when scaling text only (with containers not specified in em) not in page zoom, so along the lines of the current WG interim stance towards F69 this may not be a failure - but this needs testing. 24 May 2012: Leave open until we determine what we are doing with F69. 27 September 2012: Previous response draft - Thank you for your comment. We are currently revising F69 to include up-to-date examples, and we will try to include an example of an overflow:hidden failure similar to the one you encountered. We do not feel a separate failure is appropriate.; Resolution: Thank you for your comment. Failure F69, "Failure of Success Criterion 1.4.4 when resizing visually rendered text up to 200 percent causes the text, image or controls to be clipped, truncated or obscured", calls this out as one of the practices that causes this failure, and Example 2 demonstrates the failure. We do not feel a separate failure is appropriate.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2630: Quick Reference and Sufficient Techniques: Commenter: Kerstin Probiesch <k.probiesch@googlemail.com> (archived message); Context: Document as a whole; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
NOTE: THIS IS A COMMENT ABOUT THE QUICK REFERENCE.

I feel that there are ongoing misunderstandings about the character of the sufficient techniques. As long as one will read the techniques document from the beginning it should be clear enough. But we cannot "force" people to read the document in whole. If it is not possible to change the wording of "how to meet" one solution might be: adding a note before every single block of techniques.

Proposed Change:
Adding a note for every block of techniques. Example:

Sufficient Techniques for 1.1.1 - Non-text Content

The "sufficient techniques" listed below are considered sufficient to meet the success criteria; however, it is not necessary to use these particular techniques.

Sufficient Techniques for 1.2.1 - Audio-only and Video-only (Prerecorded

The "sufficient techniques" listed below are considered sufficient to meet the success criteria; however, it is not necessary to use these particular techniques.

(Even if the document will not look very "nice" after including these notes, it will hopefully improve a better understanding of the character of the techniques); Related issues: (space separated ids); WG Notes: maybe rather than duplicating some text repeatedly which provides incomplete explanation of techniques, for each SC in quickref provide links after SC content and immediately preceding start of specific techniques listings referring to other resources on techniques (for example, "about the techniques" section in "Introduction" of "How to Meet". That way, if the reader is in the Guidelines and goes directly to the listed techniques for a specific SC they can still get the benefit of the introduction to the "how to meet" document which explains about the use of techniques. They don't necessarily have to read the "how to meet" quickref from the beginning to get the benefit of this knowledge. PS - I think there is still a misperception that the sufficient techniques listed have to be used, and anything the WG can do to combat this misperception might be good. It may be too late, but is it possible to use another term for "sufficient", like "WCAG-documented" or something? Also, it doesn't say "considered sufficient" BY WHOM..; Resolution: The Working Group agrees with your comment and suggestion. But we went further and also put a comment on each item in the Understanding WCAG 2.0 document [DONE] The following text will replace the text before each grouping of techniques in the "Understanding WCAG 2.0" document: "Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, it is not necessary to use these particular techniques. Any techniques used only satisfy the Success Criterion if all of the WCAG 2.0 conformance requirements have been met." [DONE] And the following link will be inserted before each grouping of techniques in the "How to Meet" document. <a href="#about-techs">Note: Other techniques may also be sufficient if they meet the success criterion.</a> which links to the section which says About the Techniques Note that all techniques are informative - you don't have to follow them. The "sufficient techniques" listed below are considered sufficient to meet the success criteria; however, it is not necessary to use these particular techniques. Anyone can submit new techniques at any time. If techniques are used other than those listed by the Working Group, then some other method for establishing the technique's ability to meet the success criteria would be needed. In addition to the 'sufficient techniques', there are also advisory techniques that go beyond WCAG 2.0's requirements. Authors are encouraged to apply all techniques that they are able to, including the advisory techniques, in order to best address the needs of the widest possible range of users. Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas. Authors are encouraged to seek relevant advice about current best practice to ensure that Web content is accessible, as far as possible, to this community.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2629: title attributes on images - SC 1.1: Commenter: Glen Wallis <glen.wallis@gmail.com> (archived message); Context: Non-text Content: Understanding Success Criterion 1.1.1; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
I recently tested a site that contains a lot of images. None of the images has an alt attribute but they all have a title attribute. I tested with two versions of Jaws and the latest version of NVDA and the title attribute was read in all three cases. Does the title attribute have enough support to be considered a sufficient technique?; Related issues: (space separated ids); WG Notes: (kathy)Proposed response on June 6, 2012: The title attribute is not considered to be a sufficient technique on an image. The title attributes purpose is to provide advisory information about the element for which it is set. This should be used to provide additional information that is not essential. The title attribute is read by JAWS and NVDA because the alt-text is not present and the tools are providing the best information available. This cannot be relied upon to work on all cases with all assistive technology. SF note: the title attribute is used as the accessible name of last resort on all elements. it wired up that way for all browsers that support API mapping (except chrome which has recently had a regression in this regard - bug filed waiting on fix). But this does not mean it should be a sufficient technique. I successfully argued for title not being conforming on an image (without alt) in HTML5 (refer to: http://www.w3.org/html/wg/wiki/ChangeProposals/notitlev2) June 6 teleconference: Why is the use of title with no alt not meeting 1.1.1? Note * http://www.w3.org/WAI/GL/2011/WD-WCAG20-TECHS-20110310/F65.html Failure of Success Criterion 1.1.1 due to omitting the alt attribute on img elements, area elements, and input elements of type "image" * http://www.w3.org/WAI/GL/2011/WD-WCAG20-TECHS-20110310/H67.html H67: Using null alt text and no title attribute on img elements for images that AT should ignore But the ARIA spec lists title as the last alternative when computing the accessible name. Taking this topic to CG for wider discussion.; Resolution: The title attribute is not considered a sufficient technique to provide an alternative for an image. The title attribute's purpose is to provide advisory information about the element for which it is set. This should be used to provide additional information that is not essential. The title attribute is read by JAWS and NVDA because the alt-text is not present and the tools are providing the best information available. This cannot be relied upon to work on all cases with all assistive technology.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2614: Missing Technique already in-hand: Commenter: Duff Johnson <djohnson@commonlook.com> (archived message); Context: Info and Relationships: Understanding Success Criterion 1.3.1; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
PDF3 is clearly applicable to this SC.

Proposed Change:
Add PDF3.; Related issues: (space separated ids); WG Notes:; Resolution: Response to commenter: We do not understand why you believe PDF3 is applicable to SC 1.3.1, which is focused on the semantics of elements in the content. SC 1.3.2 addresses the reading order requirement for text and other data, and SC 2.4.3 addresses the tab order requirement. While reading order is a relationship conveyed through presentation, we think it would be confusing to add all the SC 1.3.2 sufficient techniques to SC 1.3.1, which is already a long and complex success criterion. Since SC 1.3.1, 1.3.2, and 2.4.3 are all at Level A, conformance requires that all be satisfied.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2586: Failure to choose appropriate table row and column headings: Commenter: Charles Belov <charles.belov@sfmta.com> (archived message); Context: Info and Relationships: Understanding Success Criterion 1.3.1 (Understanding Success Criterion 1.3.1); Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
It is not enough that table rows and columns have headings. A heading must actually be appropriate to the row or column it appears in and allow distinguishing between that row or column and adjacent rows or columns.

Proposed Change:
Link to new failure, Failure to choose appropriate table row and column headings.

Description

This document describes a failure caused by use of table column- or row-heading content that insuffiently describes or fails to distinguish the column or row.

Examples:

1. Three consecutive rows have a row header (same row, first column) containing the same content. Either the wrong topic was chosen for column 1, or column 1 and another column need to be combined into a single column to produce a unique heading.

2. Column 1 contains a rowspan attribute and this table does not have scope, id and headers attributes to identify additional headings.

3. Row 1 contains a colspan attribute and this table does not have scope, id and headers attributes to identify additional headings.; Related issues: (space separated ids); WG Notes: Blocked until failures are written and accepted. Accept with edits. New Failure Failure to properly make structure programmatically determinable by not reflecting row and column headers appropriately with markup. Examples: 1. markup shows rows or columns to be the same when row or columns visibly labeled are differently. 2. failure to reflect headers for complex tables in markup.; Resolution: Response to commenter: We have added several new failures related to insufficient use of table mark-up to reflect the structure of a table. However, if the table markup has been used correctly, there is not a success criterion that requires that headings be appropriate, nor is is clear how to evaluate what it means to be appropriate. The closest such success criteria would be SC 2.4.6: Headings and labels describe topic or purpose.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2621: The permissible uses of heading levels and F43: Commenter: Duff Johnson <djohnson@commonlook.com>; Context: Info and Relationships: Understanding Success Criterion 1.3.1; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
I am trying to reconcile the fact of F43 with a common (but by not means general) impression that SC 1.3.1 does not require logical hierarchy in headings.

Success Criterion 1.3.1 requires that if headings are in the content that relationships are conveyed programmatically.

Now, illogical heading hierarchy does not, as has often been claimed, leave â€œequivalent informationâ€ available to everyone.

This claim rests on the incorrect assumption that every user will find a given structural anomaly disconcerting (or not) to a similar degree. This is obviously not the case as WAI is, I know, aware. Page-position alone can provide information that effectively removes an "important" but non-structural "structure" element from the sighted user's perception of the content's organization.

Instead, the reality is that users who depend on heading structure for navigation receive a substantially less effective navigation facility when the structure model is abused for presentational purposes.

The whole point of 1.3.1 is to eliminate practices that reliably botch the conveyance of â€œinformation, structure and relationshipsâ€ to the user by way of normatively requiring â€œprogrammatic determinabilityâ€. Elegant! I applaud F43. It embodies 1.3.1 precisely because it fails the misuse of structure elements.

Now, there is â€“ of course â€“ a big variable in impact based on the nature of the content. This issue matters a lot less on short (typical web-page) content with few headings. On longer or highly structured content it is entirely fair to state that misuse of section headings for emphasis or styling kills the utility of headings as a reliable means of navigation for those who depend on structure to operate their AT.

When it doubt the reading of the normative text should err towards the side of accessibility rather than its opposite.

Iâ€™m not suggesting that headings must be used â€“ thatâ€™s absurd. I am suggesting that IF headings are used to structure content (ie, to serve the â€œsection headingâ€ role), then they must make sense to pass 1.3.1.

In any event, we are attempting to implement F43. It seems clear that F43 suggests that we fail content with illogical heading levels unless some other â€œprogrammatically determinableâ€ means is provided to discern the â€œrealâ€ headings from the other â€œusesâ€ of <H#> tags. Whatever that could be.

I have discussed this precise question with at least two-dozen experts in ICT accessibility over the past four months and have received almost the same number of opinions. â˜¹

In the use-cases of MY great interest â€“ longer and structured documents â€“ the significant majority of experts I consulted preferred to consider valid heading structure as normatively required, even if they were not sure whether or not WCAG 2.0 required it.

Proposed Change:
I think the Committee should rectify the (apparent) delta between F43 and the otherwise-stated view that â€œWCAG does not require strict hierarchy in headingsâ€, including as 'represented' in H42, example 2.

Further, I think the Committee should consider that very significant use-cases exist in which 1.3.1 becomes substantially meaningless if it is NOT understood to require logically structured headings.

I believe it's a lot easier to write Techniques for 1.3.1 if one takes this view, and far easier to implement as well. More to the point, the quality and accessibility of content will improve at every level.; Related issues: (space separated ids); WG Notes: F43 clearly describes the abuse of structural elements such as heading mark-up. The question rests on the definition of 'illogical heading hierarchy". I think it is safe to say that a structure that would use h3 as main heading level and use h2 for subheadings would fail SC 1.3.1 the mark-up then clearly misrepresents the document structure. Things are different for hierarchical heading structures that *skip* levels of headings *where this is justifed by the marked-up content*. To remain with the "Fruits and vegetables" example in H42, the main h2 sections (Fruit, Vegetables) as well as the individual h3 sections (Apple, Orange, Broccoli, etc) may have a subsection with "Further links". It would make perfect sense to mark up all these sections with h4, not mainly for visual stylistic reasons (all h4 headings would be rendered the same size) but also for the sake of consistency when navigating the document with a screen reader. This means that for the main sections (Fruit, Vegetables), h3 would be skipped. Traversing the headings listing of a screen reader on level h4 would consequently read "Further links on Fruit", "Further links on Apples", "Further links on Oranges", and so on. There are also well established a11y practices in HTML design that choose a particular (low) heading level such as h6 for (hidden) section headings. Other practices will use h1 for (hidden) section headings ("navigation", "content") and start content headings on h2 or below. Given the diversity of established a11y practices, it makes little sense to be too prescriptive (such as ruling out the skipping of heading levels) regardless of the domain context. A conformance test however can check for *abuse* of structural mark-up (this is what F43 is about) and verify if heading mark-up correctly reflects the hierarchy given in content. This last check is currently not explicitly backed up by techniques and Failures (just implicit in example 1 of H42) so there may be a case for a new Failure "Incorrectly applying heading mark up" which shows an illogical use of headings, i.e. by using heading a mark-up in a way that is clearly not in line with to the document hierarchy. But again, such a Failure should not go as far as ruling out the skipping of heading levels for the aforementioned reasons.; Resolution: Response to commenter: There is a difference between not using headings according to hierarchy, and having what is visually presented differ from what is programmatically presented. There is no requirement that headers be used in a strictly hierarchical manner. So if header levels are skipped (visually and in markup) there is not a failure. But if header A appears visually to be the parent of header B, but B is a higher level header than A in markup, then what is presented in markup clearly is not the same information as what is presented (visually) to everyone else. Whatever the logic of the presentation is for sighted people, that same logic needs to be evident programmatically. F43 clearly describes the use (abuse) of structural elements (such as headings) to format things that are not headings, and are not visually representing heading on the page. The failure is not about logical nesting, but about using heading markup (or other semantic markup) to achieve a visual effect for something that is not the thing markup was intended for. (e.g. using header to bold text that is not a header. RE Skipping levels: Things are different for hierarchical heading structures that *skip* levels of headings *where this is justified by the marked-up content*. To remain with the "Fruits and vegetables" example in H42, the main h2 sections (Fruit, Vegetables) as well as the individual h3 sections (Apple, Orange, Broccoli, etc) may have a subsection with "Further links". It would make perfect sense to mark up all these sections with h4, not mainly for visual stylistic reasons (all h4 headings would be rendered the same size) but also for the sake of consistency when navigating the document with a screen reader. This means that for the main sections (Fruit, Vegetables), h3 would be skipped. Traversing the headings listing of a screen reader on level h4 would consequently read "Further links on Fruit", "Further links on Apples", "Further links on Oranges", and so on. There are also well established a11y practices in HTML design that choose a particular (low) heading level such as h6 for (hidden) section headings. Other practices will use h1 for (hidden) section headings ("navigation", "content") and start content headings on h2 or below. Given the diversity of established a11y practices, it makes little sense to be too prescriptive (such as ruling out the skipping of heading levels) regardless of the domain context.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2633: resize text verssus zoom: Commenter: Steve Miller <steve.miller1@defence.gov.au> (archived message); Context: Resize text: Understanding Success Criterion 1.4.2; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
When auditing sites for compliance I come across many pages where the text does not resize (when this option is selected) but if zoomed to 200% it does. The critera talk about resizing the text, but also about zooming the page. Does it need to do both, one of, or one in preference of the other.

Proposed Change:
Clarify what fails i.e if the text cannot be resized then it is a fail - or if the text resizes when zoomed it passes (dependant on presentational issues); Related issues: (space separated ids); WG Notes:; Resolution: We understand that the test needs work. Please see the note that is already in the current version: Note: The Working Group has discovered many misunderstandings about how to test this failure. We are planning to revise this failure in a future update. Until then, if the content passes the success criterion using any of the listed sufficient techniques, then it does not meet this failure. So any of the sufficient techniques listed would alone be sufficient to satisfy SC 1.4.4 (Resize text). In your example, if the browser-supplied page zoom works for resizing text to 200% without clipping, truncation or obscuring, the success criterion would be met.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2615: Techniques do not apply (2.1.1): Commenter: Duff Johnson <djohnson@commonlook.com> (archived message); Context: Keyboard: Understanding Success Criterion 2.1.1; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
PDF3 and PDF11 do not apply to this SC.

Proposed Change:
Remove PDF3 and PDF11 from the list of applicable Techniques.

[Note: Comment updated in http://lists.w3.org/Archives/Public/public-comments-wcag20/2012May/0007.html); Related issues: (space separated ids); WG Notes: http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H91 is similar in that it; Resolution: DONE Change the title of PDF11 to "PDF11: Providing links and link text using the Link annotation and the /Link structure element in PDF documents" DONE Remove SC 2.1.1 and 2.1.3 from PDF3 Response to commenter: Thank you, we have removed PDF 3 as a sufficient technique from SC 2.1.1 and 2.1.3. We have retained PDF11 because it demonstrates how to make text links keyboard accessible by associating them properly with Link Annotations. We have changed the title of PDF11 to make it clearer that providing the Link Annotation is part of the technique.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2747: H69 should not be sufficient for SC 2.4.1: Commenter: Sailesh Panchang <spanchang02@yahoo.com> (archived message); Context: Bypass Blocks: Understanding Success Criterion 2.4.1; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Technique G1 documents needs of keyboard only users with respect to skipping repetitive block of content.
It also recommends a skip link should become visible on tab focus.
Given this, how is H69 a sufficient technique by itself? It does not help keyboard only users in most browsers.
Some websites refuse to provide skip links if they have implemented headings or even aria-landmarks.
I suggest H69 should not be listed as a sufficient technique for SC 2.4.1 but as an advisory technique.; Related issues: (space separated ids); WG Notes: For related discussion, see the thread starting at http://lists.w3.org/Archives/Public/public-comments-wcag20/2012May/0016.html. The response is at http://lists.w3.org/Archives/Public/public-comments-wcag20/2012Sep/0009.html; Resolution: This topic was also raised in http://lists.w3.org/Archives/Public/public-comments-wcag20/2012May/0016.html. The Working Group response, at http://lists.w3.org/Archives/Public/public-comments-wcag20/2012Sep/0009.html, is: The User Agent Notes for H69 discuss the native support for navigating by headings that is provided in Opera, and notes that for other browsers, plugins may be needed. With all of our success criteria the assumption is that people needing special user agents (including AT or special plug-ins) will get and be using that type user agent (eg screen reader, or plug-in that allows keyboard navigation of properly marked up content, etc) . We have added a note to this effect to H69 that reads: NOTE: All of our techniques assume that people needing special user agents (including AT or special plug-ins) will get and be using that type user agent (eg screen reader, or plug-in that allows keyboard navigation of properly marked up content, etc).; (Please make sure the resolution is adapted for public consumption)

Comment LC-2624: H69 is not a sufficient technique for SC 2.4.1: Commenter: Devarshi Pant <devarshipant@gmail.com> (archived message); Context: Bypass Blocks: Understanding Success Criterion 2.4.1; Status:
assigned to James Nurthen; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
H69 by itself will not be able to satisfy the accessibility needs of
sighted keyboard only users and hence is not sufficient for SC 2.4.1
(bypass blocks).
Proposed Change:
Remove it from the list of sufficient techniques and merge it with H42.; Related issues: (space separated ids); WG Notes: Response sent to commenter: The User Agent Notes for H69 discuss the native support for navigating by headings that is provided in Opera, and notes that for other browsers, plugins may be needed. With all of our success criteria the assumption is that people needing special user agents (including AT or special plug-ins) will get and be using that type user agent (eg screen reader, or plug-in that allows keyboard navigation of properly marked up content, etc) . @@@ We have added a note to this effect to H69 that reads: NOTE: All of our techniques assume that people needing special user agents (including AT or special plug-ins) will get and be using that type user agent (eg screen reader, or plug-in that allows keyboard navigation of properly marked up content, etc). ========================================== Response from commenter: Ok, that is a plausible explanation, but at the same time it is a global statement as well. It should, in my view, be also available in: 1. http://www.w3.org/TR/WCAG-TECHS/intro.html 2. http://www.w3.org/TR/WCAG/; Resolution: The User Agent Notes for H69 discuss the native support for navigating by headings that is provided in Opera, and notes that for at least some other free browsers, plugins are available. With all of our success criteria the assumption is that people needing special user agents (including AT or special plug-ins) will get and be using that type user agent (eg screen reader, or plug-in that allows keyboard navigation of properly marked up content, etc) . [DONE] We have added a note to this effect to H69 that reads: NOTE: All of our techniques assume that people needing special user agents (including AT or special plug-ins) will get and be using that type user agent (eg screen reader, or plug-in that allows keyboard navigation of properly marked up content, etc). ---------------- Additional proposal: [DONE] Add the Note to the end of the Sufficient and Advisory Techniques section of http://www.w3.org/TR/WCAG-TECHS/intro.html; (Please make sure the resolution is adapted for public consumption)

Comment LC-2616: Why is "navigation" confused with "input": Commenter: Duff Johnson <djohnson@commonlook.com>; Context: Focus Order: Understanding Success Criterion 2.4.3; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
I understand that it's called "focus order", but this SC refers to Ã¢â‚¬Å“navigationÃ¢â‚¬Â, as does the Guideline. I get how tabbing between links / fields might seem like "navigation", but that seems very HTML/Flash-specific and it's not even fair to those formats (frankly) either, since that's hardly the only (or primary) means of "navigation" in HTML, at least.

SC 2.4.3 is the _only_ Level A criterion that mentions "navigation", and yet judging by the Techniques (HTML and PDF) it's understood to be only applicable to content that includes focusable (read "input") elements. I don't understand this at all, and I did not find the "Understanding" text enlightening. Indeed, that text is suggestive in appearing to support (in part) my understanding of SC 2.4.3 that the SC's intent is more general than the traditional elements than "receive focus".

Since the SC appears to pertain to navigation, and if "focus" reasonably also includes structure elements, I would expect PDF9 to apply to this SC.

Proposed Change:
Add PDF9 to this SC. Also, I suggest considering that "navigation" goes beyond input elements - that's certainly the case in PDF, for example, and I would suspect, in other formats as well.; Related issues: (space separated ids); WG Notes: David adds: WCAG does not require nested hierarchical headings. There is a lot of debate at the PDF standards working group right now to require hierarchical headings, and I've recieved calls about this.; Resolution: Response to commenter: All SC in Guideline 2.4 are about navigation, even if this term only appears explicitly in SC 2.4.3. The focus in SC 2.4.3 is on the *navigation sequence* and focusable elements (e.g., when filling out a form), especially when accessing content using a keyboard, and misunderstandings that can arise if the order of focusable elements (the navigation sequence) is not meaningful. PDF9 is concerned with marking up headings so that the resulting mark-up hierarchy reflects the content hierarchy. This is an aid to navigation - but does not help ensuring that focusable elements are scanned in the right order.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2744: Proposed a failure of 2.4.3 focus order when dynamically inserting content: Commenter: David MacDonald <davidmacdonald100@yahoo.com> (archived message); Context: Focus Order: Understanding Success Criterion 2.4.3; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-order.html

I have long felt that inserting dynamic content behind the control that is inserting the content, messes up screen reader users. If the inserted information has any focus-able content then I suggest it is a failure if 2.4.3 because the person is at a certain point of moving through the page, and important information that they want to focus on is behind them in the focus order.

Proposed Change:
I can create a technique

failure of 2.4.3 due to dynamic insertion of focus-able content before the control that inserts it.; Related issues: (space separated ids); WG Notes:; Resolution: This is covered by our change of context provisions. If there is a change behind the person that is due to just navigating, then it is a failure of 3.2.1 or 3.2.2 if it is due to input. But once a person activates a control, a link, etc, any change of context is allowed. Changing the context behind the present point of focus is not good -- but it is not a failure of the page because the page becomes a 'new context' or a new page if you will. Activating the control can also cause page content to appear or disappear. This provision only says the the content is in a logical order. IF the person activates a control and changes the context - the (new/revised) content may still be in a logical order and meet the success criterion (2.4.3). We do note that having content inserted above the current focus point without notifying the user of it, and its location can be a problem for users who cannot see this. We don't currently have an SC however that forbids this. An advisory technique describing solutions to this, such as ARIA Live Regions, would be helpful. We have added this to our Post WCAG 2.0 wiki as well. (Dropping the focus partway down the page on page entry would also have similar problems and not be good but is not a violation of 2.4.3 either.); (Please make sure the resolution is adapted for public consumption)

1-20 21-31

Add a comment.