This Wiki page is edited by participants of the WCAG Working Group. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information. Much of the content of this wiki is being migrated to the WCAG wiki at W3C.

From WCAGWiki

2005-10-25 from Loretta

Wendy, David, and I met this morning, to try to sort out the relationship between GL 1.3 and 2.4, since that emerged as an issue last week. Included in the discussion is implications for text documents.

I'm including John, Michael, and Yvette on this email because we though you were the original group that tried to address the relationship between 1.3 and 2.4, and we wanted to make sure that we accurately reflected your thoughts, and that we don't retread too much ground that has already been covered. If we left anyone off the list, could you please let me know, and/or forward this message to them, too.

Please pardon the use of "require" language. This is still a thought exercise.

One thing that we noticed during this morning's discussion is that WCAG1 only requires table mark-up at L1. All other structural mark-up requirements are at L2. So requiring more extensive structure at L1 is raising the bar.

Do these options cover the range of interpretations that were emerging at the Face 2 face? How do they line up with the original intentions of the 1.3/2.4 rationalization? Can we rule any of these out (not testable, too weak, etc.)? Is there any consensus on what we should propose for this draft?

Option 1

• GL 1.3 L1 SC1 is interpreted to mean that any structure that can be expressed in a technology is expressed in a way that is programmatically determined
• GL 2.4 only addresses explicit navigation elements (i.e. links) and the use of structure for navigation is assumed to be addressed by GL 1.3 L1

Implications

• Nearly impossible to meet this with text documents, unless they are just a sequence of paragraphs, since there is no way to programmatically determine headers, lists, etc.
• Strong requirements on the way that HTML is used; headers must be marked as headers, paragraphs as paragraphs, etc.

Option 2

• GL 1.3, L1, SC 1 requires that structure be programmatically determined when information is lost in the linearization of the content.
• GL 1.3, L2 adds a success criterion that requires all structure that can be expressed in the content
• GL 2.4, L1 only addresses explicit navigation elements

Implications

• "Well behaved" text documents could be accessible, e.g., no tables or nested lists, but lists, headings, etc. are ok
• Any HTML mark-up for paragraphs, lists, etc., that exposes information in the right order is acceptable at L1, even if those structure elements aren't identified as such
• Using structure for navigation is an L2 capability that is provided by the GL 1.3 SC
• Layout tables can satisfy L1

Option 3

• GL 1.3, L1, SC 1 requires that structure be programmatically determined when information is lost in the linearization of the content.
• GL 1.3, L2 adds a success criterion that requires all structure that can be expressed in the content
• GL 2.4, L1 addresses explicit navigation elements and navigation via structure

Implications

• "Well behaved" text documents could be accessible, e.g., no tables, but lists, headings, etc. are ok
• Any HTML mark-up for paragraphs, lists, etc., that exposes information in the right order meets GL 1.3 L1, even if those structure elements aren't identified as such
• Using structure for navigation is an L1 capability so navigation may require some structural markup that is not otherwise required at GL 1.3 L1, e.g, grouping of navigation links, or headers in long documents

Option 4

• GL 1.3, L1, SC 1 requires that structure be programmatically determined when it is visually obvious in the default rendering.
• GL 1.3, L2 adds a success criterion that requires all structure that can be expressed in the content
• GL 2.4, L1 only addresses explicit navigation elements

Implications

• Well behaved text documents can probably pass at Level 1. Tighter interpretation on what is permitted in HTML. Makes the "visual" representation the master representation; is there a well defined default representation? Is this testable? What are the implications for something like VoiceXML?
• Navigation supported to "visually obvious" structural elements at L1

Option 5

• GL 1.3 L2 requires that any structure that can be expressed in a technology is expressed in a way that is programmatically determined
• GL 2.4 only addresses explicit navigation elements (i.e. links) and the use of structure for navigation is assumed to be addressed by GL 1.3 L2

Implications

• This is weaker than WCAG1, since table mark-up isn't required at L1
• No obstacles for text documents
• Probably need an L1 SC that requires that linearized document makes sense

2005-10-26 from Andi

Good job guys. This is a difficult subject and you have come up with more options than I could have imagined.

I prefer option 2.

I might be able to live with option 3 depending on the actual SC that we propose and the definition of "navigation by structure". Navigation by structure depends entirely on the user agent. Is there anything in UAAG that defines which structures the user agent must support for navigation? If not, then virtally any HTML structural element could be exploited by user agents for navigation. This then, in effect, is the same as what we have now with gl 1.3 requiring ALL structures to be programmatically determinable.

I think option 4 gets us into trouble with VoiceXML because of the "visually obvious" wording.

I don't like option 5. It's hard to argue that text data tables are accessible using even the most lenient logic.

2005-10-26 from Michael

Hi - in my interpretation it's mainly option 1 with a little of option 5.

1.3 only requires structure supported by the technology at Level 1. So if you're using headers or paragraphs, and your technology supports it, the headers and paragraphs should be semantically / programatically identified. It's basically saying provide structure where used by the content and supported by the technology. At Level 2 it adds additional requirements and says "these things (like tables and headers) must be structurally identified". Because not all technologies support structural features for all the things we might call out as important at Level 2, it might not be possible to conform at Level 2 in all technologies. For instance, plain text documents could conform if they are pretty simple, but if they have tables, they could not conform at Level 2 because there is no way to provide the structural markup.

Guideline 2.4 is about navigation and is completely agnostic to the semantic structure covered in 1.3. People get confused about it because headers in HTML are commonly used to allow a user to move among sections of a page. But the markup for headers is not a navigational feature, it's a structural feature, saying "this is a header". The user agent chooses to take advantage of that to provide navigation, but there is no expectation in WCAG that it do so. Under guideline 2.4, we might ask that it be possible to navigate among sections of a page. Using headers in HTML might be a technique if supported by user agents, but another valid (if less graceful) technique would be to provide links and bookmarks to each of the sections.

It's important to me that we not mistake header and table structure for a navigational feature. Identifying these features aids in understanding. The structure allows you to find out "this is a header" or "this is a table cell with header information from cell(s) x". Being able to use that information to navigate around is useful but not the reason we require that the semantic structure be marked up.

Interaction between 1.3 and 4.2, from Loretta

Michael, are we opening ourselves up to the following scenario:

• Author creates an HTML page that doesn't mark up headers, lists, paragraphs, etc. according to semantics, but linearizes properly. This fails GL 1.3
• Author converts the HTML page to text. Since text doesn't support markup of headers, lists, etc., no structure is required
• Author provides a link to the text version at the beginning of the HTML page, satisying GL 4.2 1 SC1 to provide an accessible alternative

David MacDonald's comments

I asked a member of the 1999 WCAG 1.0 Guidelines committee about whether unstructured text documents are accessible.

This was his response to me:

"When we were creating the WCAG 1.0 Guidelines, what we really were talking about when we mentioned text documents was "structured text documents". Basic HTML text with headings etc. And it [unstructured text] somehow got out there and it made. We meant to say structured text documents. We did not expressly say that but I think that is what we all meant in the back of our minds. When the world interpreted our words to mean plain unstructured text we perhaps should have gone back and clarified. The whole reason for html in (about) 1994 was to provide structure to scientific docs. This was Tim’s vision, fully navigable, indexable, headings, distinguishable etc... Plain text was never intended to be flopped back and forth on the internet. Unstructured text is only accessible in comparison with bit map pictures of text."

This person's view is in line with my thinking about it. I do not think that plain unstructured text documents should pass our guidelines, and therefore I do not see any reason to scope text out, or to make special provisions for a format that was never really intended to be included in the 1.0. Let's take this opportunity to clarify the 1.0 rather than perpetuate the misunderstanding.

Michael's responses to Loretta's questions

Here's my take on the questions Loretta posed above.

Structure not identified in HTML but page linearizes properly.

I would say that this fails the structural requirements of Guideline 1.3 Level 1, but passes 1.3 L3 SC1 (formerly in Guideline 2.4). It's great that it passes that Level 3 issue but we still need it to pass Level 1.

HTML converted to text so no structure required.

One of the reasons for this discussion is a concern that text documents will be excluded from WCAG conformance, and an implied belief that they should not be. My proposal that structure must be provided when supported by the technology is a compromise that allows text documents to pass at Level 1, but still requires HTML and other documents to provide structure in order to pass at Level 1. This is the only way I can see that we can have structure at Level 1 and have text documents pass.

The other approach is to say structure must be provided at level 1 and know that this means it is not possible to meet WCAG for text documents. I am comfortable with that myself, but get the sense a lot of people are not. There are other technologies that we know can't meet WCAG fully, and under Guideline 4.2 we provide ways to deal with that.

One problem with a blanket requirement for structure at Level 1 is that we get closer to needing to say what kinds of structure (headers, tables, lists, etc.). The compromise approach, of only requiring structure supported by the technology, creates a self-limiting list of features (defined by the technology in use) so we don't have to spell them out. For a blanket requirement we may need to spell them out; Andi took a stab at suggesting some in her comments for issue 795. I think, though, that if we think a particular structural feature merits calling out, there is a rationale under another guideline, and so it should just be there. This is one of the reasons we're having confusion with 2.4. The navigational intent of 2.4 benefits from structure. But anywhere a success criterion includes the term "programmatically determined" we really mean structure, so it's all over the place.

Author provides a link to a text version, under Guideline 4.2, to avoid requirement to provide structure.

In my opinion, this does not fall under Guideline 4.2. You should only be "allowed" to provide an alternate version if your technology does not support WCAG requirements. Since HTML provides structure, you would be required to provide it, not use 4.2 as a way out of it. Possibly we need to adjust the wording of 4.2 L1 SC1 to make this clear, something like:

If content does notit is not possible for content to meet all level 1 success criteria in your technology, then an alternate version is available from the same URI that does meet all level 1 success criteria.

Navigational features

This is more of a 2.4 question: I think the proposals on the table remove structure from the requirements and techniques for 2.4. So what are navigational features? Is there anything but a link that is a navigational feature? How could any technology fail this guideline? And if links are the only navigational feature, can we simplify the wording of the success criterion?

Navigational features

Here's what I see as navigation features:

• links
• in HTML, <link> elements when used to refer to TOC, next page, etc.
• form submit buttons that take you to new pages
• search forms
• groups of links, e.g., what we commonly understand as navigation bars

I don't think the others in the original 2.4 group necessarily agreed with me on that last point. But if a technology came along that defined a <navbar> element it clearly would be a navigation feature. I hope such a technology comes along and would like to anticipate it in the guideline but not defining that out. They disagreed with me that a group of links, which are already navigation features, should be considered a navigation feature in its own right. I prefer to leave it undefined at the SC level and speak to the issue in guide docs.

So I see "navigation feature" somewhat broadly. It's clear that some but not all of those features line up with things we would expect to be structurally identified, which is why I want separation from 1.3.

Response to Michael

I also don't think that grouping links in a nav bar is any different that using headings to group sections of the document. But as you note, this is a future issue.

But my real question is what is the accessibility requirement that those navigational features be programmatically determined? What is it about them that needs to be programmatically determined? For instance, does AT need some way to distinguish between a form submit button that takes you to new pages vs one that just submits the data and leaves you on the current page? Does the AT need to know that a form is a search form?

I really have lost track of the purpose of this success criteria.

Programatically determined and Role

I think under 2.4 L1 SC1 what we want be programatically determined is the fact that something is a navigation feature. In HTML, links are easily distinguishable as navigation features (it might be a violation to use them for non-navigation purposes like triggering script, which takes us into DHTML roadmap land). A major violation of this SC I can think of in HTML would be to use <span onclick="location.href="newpage.html">"link" text</span> - I've actually seen this with enough frequency to want a SC against it. I can come up with other examples.

It gets stickier when we talk about things like search forms. Is a search form "more" navigational than a regular form, and should that be programatically determined? Is a search form "more" or "less" of a navigation feature than a link? To some extent we're getting into 4.2 L1 SC3 territory here about requiring that the role of objects be programatically determined. Possibly we just need to rely on that SC for what we intended with 2.4 L1 SC1, but that would cause the requirement to go down to Level 2 - which I think is the reason it was created in 2.4 to begin with, to have it at Level 1 for navigation.

David

I think we need to require authors to expose all structure...In HTML that would include, Headings, Paragraphs, lists, etc....

According to Chuck Letourneau that is the whole purpose Tim invented the web, to give structure to "scientific text documents." I think if we leave this stuff out of level one we are doing a disservice to people with disabilities and the web in general."

I do not think that plain unstructured text documents should pass our guidelines. That was never Tim's intent of the web...to flop text around...it was to be marked up with headings etc...

As far as 2.4 goes, I see the overhang between 1.3 and 2.4 and even 3.x. Headings can be used for three purposes. To Navigate (blind people list headings and jump around) And to help understanding (for people with cognitive disabilities. But we don't have it in the understandable section.(3.x) And to make content perceivable. (1.3)

Right now all the heading techniques are *not* linked to 1.3, they are linked to 2.4. I don't care if we put them at 1.3L1 or 2.4L1 but I think they should be at a level one somewhere.

David's response on grouped links

I’m with Michael about leaving wiggle room in 2.4 for groups of links. There seems to be elements in the new work done by the XHTML 2.0 crowd that indicates there will be a grouped link element and I wouldn’t want to see that shot in the foot by the WCAG.

Loretta's response to David on grouped links

I have to say that I still don’t understand what 2.4 is requiring, or why it is at level 1. Your comment about grouped links leaves me more confused, not less.

More comments from David on intent of 2.4

I think 2.4 L1 is about the ability of AT to track down links (and perhaps groups of links), I think the ability to make links from page to page is the single most important distinction between the web and gopher. And what caused it to take off in popularity.

The comment about grouped links comes from Michael’s earlier comments:

Here are the quote from the discussion forum:

<michael>

Here's what I see as navigation features:

links in HTML, <link> elements when used to refer to TOC, next page, etc. form submit buttons that take you to new pages search forms groups of links, e.g., what we commonly understand as navigation bars I don't think the others in the original 2.4 group necessarily agreed with me on that last point. But if a technology came along that defined a <navbar> element it clearly would be a navigation feature. I hope such a technology comes along and would like to anticipate it in the guideline but not defining that out. They disagreed with me that a group of links, which are already navigation features, should be considered a navigation feature in its own right. I prefer to leave it undefined at the SC level and speak to the issue in guide docs.

So I see "navigation feature" somewhat broadly. It's clear that some but not all of those features line up with things we would expect to be structurally identified, which is why I want separation from 1.3.

</michael>

I think the grouped links thing also comes from WCAG 1.0. It is true that they are at level 3 but I am suggesting they can go in this 2.4 L1, because at CSUN last year I went to a talk on XHTML 2.0, And also the roadmap talk, it seemed to be suggesting that XHTML was going to have a special element for navigation menus. And perhaps the DHTML roadmap will also benefit from a NAV element. I am simply saying that in an age when the web is getting more and more complex, sites are getting bigger and bigger, that perhaps we want to leave room for groups of related Navigation features.

Provide navigation bars to highlight and give access to the navigation mechanism. [Priority 3]

Techniques for checkpoint 13.5

13.6 Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group. [Priority 3]

Response from Loretta on intent of GL 2.4

So it sounds like you are saying that this SC is about being about to recognize the role “link” reliably? If that is what it is, there ought to be more straightforward ways to say it, or to characterize it. And I have to say that it doesn’t really seem like a critical accessibility issue, that needs to be covered at level 1. Particularly since, as Michael pointed out, we already require it in GL 4.2. It may be that someone who is more convinced of the value of this SC should work on the Guide Doc.

I continue to see no difference between grouping links and grouping other content for the purposes of navigation. I think navbar, should it be defined, is covered by whatever we do with GL 1.3.

Andi's comments on navigation features

I agree with Loretta. If the technology supports <link> or <group of link> elements, then these are structure that must be programmatically determinable per GL 1.3. So what is GL 2.4 L1 SC 1 trying to prevent people from doing?

Andi's response to David's comments on including all structure

> I think if we leave this stuff out of level one we are doing a disservice to people with disabilities and the web in general.

This sounds like another form of the GL 4.1 debate to me. People feel strongly about this if they think that all documents on the Web should validate to standards (aka HTML). I don't want to do a disservice to people with disabilities but I don't think it's our job to promote things that are good for the Web but for which we can't articulate a strong accessibilitiy benefit.

I would rather people spend their resources writing good alt text, captioning their multimedia content, keeping their alternative versions current, etc. We should ask ourselves, what is the barrier that is created, if people don't do this? If we make content developers mark all headings, paragraphs and lists at level 1, it will be another example of a requirement that causes them to fail to comply with the standard yet people with disabilities will still be able to use the site. This then causes developers to question the value of all of our requirements.

I know that providing heading elements on a page is extremely useful to blind users but the lack of heading elements does not create a barrier to accessibility in all cases. On short Web pages without a huge number of links, lack of heading elements is probably not that big a deal. The usefulness of headings increases in proportion to the amount of content you have on a page. But if heading elements are only required at Level 2, we can still make them advisory at Level 1 and explain the rationale.