Guideline 4.1 (use-spec) Issue Summary

Description:

This issue (from the U.S. Access Board) asserts that code that violates specifications, while it sometimes has an effect on access is fundamentally a question of poor design rather than accessibility. Another comment on this issue (from James Craig) asserts that violations of specifications should not be encouraged or condoned (even for backward compatibility).

Recommendation:

1. Emphasize the importance of the relationship between standards compliance and compatibility with user agents including assistive technologies. (see rationale below)
2. Discuss the pros and cons of making our recommendations about the use of valid code more strict might be.

There are a number of other open issues associated with this guideline that are dependent on this one and we have received split feedback about whether exceptions to the requirement to use of valid code should be made. I've included some proposals below that may address some of the concerns that have been raised, but could use some additional feedback about what direction to head on this as there are compelling arguments to be made on both sides of the issue.

<proposal 1>
Retain existing level 1 criterion and promote current level 3 criterion to level 2. (See issue #966)

Level 1 Success Criteria for Guideline 4.1

1. Except where the site has documented that a specification was violated for backward compatibility or compatibility with assistive technology, the technology has: [I]
   1. passed validity tests for the version of the technology in use (whether it be conforming to a schema, Document Type Definition (DTD), or other tests described in the specification),
   2. structural elements and attributes are used as defined in the specification.

Level 2 Success Criteria for Guideline 4.1

1. Technologies are used according to specification without exception. [V]

Level 3 Success Criteria for Guideline 4.1

1. No level 3 success criteria for this guideline.

<end proposal 1>

< proposal 2 >

Remove level 1 exceptions that allow spec violations for backward compatibility and compatibility with AT.

Level 1 Success Criteria for Guideline 4.1

1. Content has passed validity tests for the version of the technology in use (whether it be conforming to a schema, Document Type Definition (DTD), or other tests described in the specification).
2. Elements and attributes are used as defined in the specification for the technology in use.

Note: Adopting this proposal would necessitate removing the level 3 success criterion in the latest draft, "Technologies are used according to specification without exception. [V]", leaving only 2 criterion at level 1 for this guideline.

<end proposal 2 >

< proposal 3 >

Remove level 1 exceptions that allow spec violations for backward compatibility only. (See Issue #933)

Level 1 Success Criteria for Guideline 4.1

1. Except where the site has documented that a specification was violated for compatibility with assistive technology, the technology has: [I]
   1. passed validity tests for the version of the technology in use (whether it be conforming to a schema, Document Type Definition (DTD), or other tests described in the specification),
   2. structural elements and attributes are used as defined in the specification.

<end proposal 3 >

Proposed Rationale: The working group believes that conformance with specifications and the use of valid code is an essential part of compatibility with assistive technology. This approach means not requiring web authors to acquire detailed knowledge about all assistive technologies (and their quirks) but rather, to build to standards and have user agents including AT rely on the correct use of standards (author's responsibility) to render content. While we agree that the use of nonstandard code is also poor design, inconsistent coding practices and use of specifications in non-standard ways creates a situation where user agents and assistive technologies are unable to reliably interpret and present content to users.

Issues:

• Overlap with 1.3: Joe's recent proposals for guideline 1.3 emphasize the use of Web standards. We should consider how these guidelnes work together and relate to one another. In many cases, it seems that a number of common specification violations would be covered under guideline 1.3 (ex. using <div> and <span> instead of headings, lists, etc.). What specification violations are we concerned about that would not be addressed under 1.3?
• What are the advantages and disadvantages of taking a stronger position on the need for valid code? In some cases, specification violations will have little or no impact on accessibility. In others, there may be legitimate reasons for an author to violate specs in order to ensure compatibility with AT or older browsers. Some examples:
  • Becky's concerns over restrictions of GL 4.1 SC1 included an example of a specification violation (using tabindex on <div> elements) that is supported by browsers and has benefits for accessibility.
  • <embed> vs. <object>
  • There are portions of all specifications that are largely ignored by both user agents and AT. (ex. Inline structural elements to identify citations, code fragments, deleted text, etc.)
  • Others?
• How do repair techniques fit in? Can we, for example, leave exceptions for backward compatibility and compatibility with AT out of the guidelines and cover them solely through the creation of repair techniques that are identified as sufficient for meeting a given SC?

Description:

This guideline can be interpreted, "make content backwards-compatible." We need to clarify.

Reccomendation:

This partially depends on resolution to #888. If we remove exceptions for backward compatibility and compatibility with AT, this would no longer be an issue. Is the reference to "backward compatibility" needed at all? Now that we have the concept of baseline, perhaps this should be reworded to only address compatibility with AT (see proposal 3, issue #888 above)?

Description:

Suggests moving the level 3 criterion, "Technologies are used according to specification without exception. [V]" to level 2.

Recommendation:

Also depends on Issue #888, where one option is to promote this criterion to level 2. (proposal 1, isue #888 above)

Description:

This issue suggest that WCAG 2.0 should explicitly discourage the use of a layout tables and expresses concerns that leaving recommendations about layout tables to techniques will cause confusion for authors.

Recommendation:

Propose that we close this issue. Since the use of tables for layout is not an issue applicable to all technologies, the guidelines themselves can not directly address them. The working group does intend to address this issue in the informative materials that will accompany the guidelines (guide docs and techniques). General Techniques for guideline 1.3, Identifying data tables, and in section 8 of the HTML Techniques, Tables for Layout, both address the question of tables for layout. As written, these techniques recommend against the use of tables for layout, but do not prohibit their use in terms of conformance to the guidelines.

Description:

Does WCAG 2.0 cope with the fact that capabilities of assistive technologies in various countries are different?

(1) Guideline 4.1 Example 3"Java accessible APIs."
But not all AT have an ability to treat these functions.

Recommendation:

Propose that our discussions around baseline address this issue in that an author's choice to rely on the use of an API for which there are no assistive technologies that can access the content would be considered an inappropriate baseline.

Description:

Should breaking a specification be allowed? Will this not mean the web site will work with one particular user agent or type of assistive technology and not with others. Is this not against the idea of accessibility?

Recommendation:

Also depends on Issue #888, where one option is to remove the exceptions for backward compatibility and compatibility with AT. (propsal 2, issue #888 above)

Description:

Who Benefits from Guideline 4.1
The (unsolved) problem is that current technologies do not respect the specifications. So as long as they don't, content authors will need work-arounds from time to time.

Recommendation:

Propose that this issue is covered by baseline as well as by the concept of repair techniques. Not sure either of these concepts have been expressed clearly enough in a draft at this point in time to close the issue, so suggest leaving this open for now.

Description:

The baseline impact analysis suggested that this criterion needs work to address implied until user agents concerns.

Recommendation:

Also relates to 888 and 933.