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-2585
There are 31 comments (sorted by their types, and the section they are about).
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.
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.
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.
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.
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".
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).
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:
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?
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?
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:
> <a href="xxx.html><img src="xxx.png" alt="WCAG 2.0"></a>
> <a href="xxx.html>WCAG 2.0</a>
<a href="xxx.html><img src="xxx.png" alt="WCAG 2.0"></a>
<a href="xxx.html>About WCAG 2.0</a>
> CASE 3:
> <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>
<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>
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.
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.
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.
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.
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)
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.
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.
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?
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.
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.
PDF3 is clearly applicable to this SC.
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.
Link to new failure, Failure to choose appropriate table row and column headings.
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.
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.
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.
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)
PDF3 and PDF11 do not apply to this SC.
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)
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
Remove it from the list of sufficient techniques and merge it with H42.
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.
Please add an item to "Failures for SC 2.4.3 - Focus Order". Numerous websites cannot be navigated with a keyboard because the designer behind it hides the visual focus with CSS (outline:none). Also, many reset stylesheets contain this CSS rule, and therefore it's usage is widespread.
Add hiding keyboard-focus with CSS (outline:none) to "Failures for SC 2.4.3 - Focus Order".
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.
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.
Add a comment.