Standards, Validity and Conformance

Introduction

The WCAG Working Group supports Validity Testing by Authors. In fact it supports more than Validity – it supports conformance with standards wherever possible. Conformance helps with interoperability at all levels. And since one major component of accessibility is interoperability with assistive technology, conformance can have major impact on accessibility.

For this reason, aspects of validity and conformance are built in throughout the WCAG guidelines. Many of the guidelines deal with interoperability and use standards conformance as a means for sufficient fulfillment of success criteria.

The WCAG Working Group is currently debating whether it should include validity testing for any technologies used by an author as a required success criterion for WCAG.

This document is intended to provide some background on the topic as well as the current list of Pros, Cons and Alternatives.

Background and History

Since June

Today (week of 7 November, 2005)

Need to make decision on how this topic will be handled in the next draft which is overdue and must get out before next publishing moratorium in late November.

Notes

About Custom DTDs - W3C QA Group

The proper use of the shared semantics of a standard markup language empowers me as a web author, and since I know that validation is one practical way of getting close to that goal, therefore I validate my web documents.

It is important to remain conscious, however, that validity alone is not a guarantee of compliance, and even further from being a guarantee of quality.

...Nothing in a DTD, for instance, can enforce that the content of the lang attribute must be a language code from RFC1766"

Common validity errors:

As part of the work the following list of validity errors that relate to accessibility was compiled by Wendy Chisholm.

Reasons cited for requiring validity at level 1 (or 2)

The following points have been gleaned from past discussions and posts to the mailing list and are summarized here for convenience.

  1. AT manufactures have said that valid code is easier to work with and breaks their code less.
  2. Lack of Validity forces AT Vendors to build on top of existing user agents because it would be too much work for them to build their own user agents that could handle all the invalid code out there.
  3. Invalid code elements will cause failure when you test with text/html browser and with application/xhtml+xml.
  4. Validity errors can (and sometimes do) result in accessibility barriers
  5. Invalid documents are not testable, so it cannot be guaranteed that the final rendering will be accurate for AT
  6. How can elements be programmatically determined if you can't be sure that the content is valid?
  7. It is doubtful, and not testable, that other guidelines catch all validity errors that could result in an accessibility barrier
  8. The four principles on which WCAG 2.0 is based require valid code to be testable
  9. Invalidly addressing an issue could cause other issues
  10. There is a deep fundamental flaw with a set of standards that proposes to use a baseline concept, but fully rejects embracing basic syntax checking available with the core technologies
  11. Promoting robust and stable long-term standards, even in the face of known issues - which we have every reason to believe will be temporary - is being practical.
  12. The institutionalization of validity will inevitably result in mainstream authoring tools improving their tools.
  13. Validity has been a requirement in WCAG 1.0, and no one knows of a case where someone has been prosecuted for invalid content
  14. Validity offers a solid base on which to build accessibility, and encourages accessibility to be considered from the ground up, and helps safeguard against errors creeping in at a later stage if there is an effort to ensure validity through the project lifecycle.
  15. It was on the quicktips for WCAG 1.0. Do we want to remove?
  16. Mandatory accessibility is inevitably delegated to unmotivated institutions.  Validity, more than any other criteria that impacts accessibility, is robustly resistant to casual implementation.
  17. With regard to validity, the difference between a Level 1 and 2 success criteria comes down to parsing the difference between "minimum" and "enhanced". Well-formedness is minimum, strict validity is enhanced. But the former concept doesn't exist in the HTML specification, so in order to get what is required, validity must fill in.
  18. Valid code is much easier to evaluate against accessibility standards and much easier for AT developers to work with.  These two niche markets will have dramatic benefits to widespread validity, which in turn cascades to PWDs.
  19. The authors and testers of accessible content have too many variables to contend with: OS / browser / plug-in / AT - including multiple versions and platforms for each.  Eliminating one variable (tolerance for tag soup) has huge positive ramifications for these two groups.
  20. The categorization of validity as a Level 2 success criteria is more harmful than not including it at all, therefore it should be at Level 1.
  21. The Return On Investment for validity as Level 1 will far exceed the short term costs (in time and money).

Some reasons were given that appear to not be accessibility specific but may be. So they are included here

  1. Needed so that pages will work across browsers.
  2. The W3C and therefore this Working Group should support and encourage use of standards properly.
  3. Disrespectful of other specifications, including w3C specifications
  4. The W3C has been remarkably supportive to accessibility with regard to their other standards.  This is the chance for WAI to give something back.
  5. Validity meets the level 1 requirements for invisibility, testability and practicality.
  6. The evidence of the last ten years is that if validity is not mandated it will not become widespread, even if it makes the Web a better place for everyone (not just PWDs) and has a good demonstrated ROI.  There is no reason to expect a better opportunity to promote validity for another ten years.

Reasons cited against requiring validity

  1. Validity is not required for accesssibility. An accessible website can still contain invalid code
  2. Not all aspects of validity affect accessibility
  3. The aspect most cited by AT Manufacturers as being good about using valid markup is that it parses unambiguously. This is a subset of validity which is a subset of conformance to a spec.
  4. Conformance is much more than validity. Why stop at validity if it is important to support the standards?
  5. Requiring Validity can reduce accessibility options
  6. A level 1 validation requirement may prevent innovation of new technologies that use new attributes not included in current specifications.
  7. Validity issues that relate to accessibilty should be required by other success criteria
  8. Is this just an HTML specific issue? XML user agents are required to stop parsing if content is not well-formed.
  9. Validators do not exist for most non-markup technologies.
  10. Standards cannot require other unnamed standards for conformance.
  11. The production of valid HTML is not a common skill set among everyday developers, outside of a small group of skilled practicioners. It may be too difficult to achieve for many (most?) authors because of the tools that generate markup do not necessarily generate valid markup and they are not expert enough to understand validator error messages nor able to fix them using the tools they have. (Most cannot write raw html).
  12. It may never be possible to make some content valid, because the flaw is created by a tool or process that cannot be changed by the responsible party.
  13. A minimum requirement of validity would consign a large proportion of accessibility repair work to tasks that may not, in the end, actually improve things for users. It would also introduce a potentially enormous amount of time and expense to repair larger legacy sites, for an benefit that is hard to quantify, and therefore hard to justify.
  14. Our guidelines, and the charge to our working group by W3C are limited to accessibility issues. We cannot require things that are not required for accessibility.
  15. WAI and the WCAG WG produce recommendations for increasing accessibility to PWDs and are not, and must not be seen as, crusaders for or enforcers of other W3C specifications.
  16. Requiring Validity at Level 1 triggers requirements that would prevent companies from even having internal goals of WCAG 2.0 conformance (even if they made no external claims) (ala ISO 9000 certification).
  17. If the people who wrote the specification did not intend for it to be mandated, mandating it violates the assumptions made by both the people who created it and those that reviewed and approved it.
  18. It is not appropriate to require parts of another standard that are not required by the standard itself.
  19. If it can be established that all aspects of validity are important to accessibility, then this SC should be at level 1. If only some aspects of it can be directly linked to accessibility, then only those aspects should be in the guidelines and the others should not be at level 1 or level 2, both of which may be required in different contexts.
  20. Validity becomes well-formedness if you can declare a DTD to have anything you want to use in it. Restricting DTDs to only be certain DTDs makes guidelines technology specific.

Alternatives

The following is a summary of alternatives from recent discussion/postings.

Suggestion 1:

  1. Validity at Level 1

Suggestion 2:

  1. Level 1 SC: "Delivery units can be parsed unambiguously."

Suggestion 3:

  1. Validity at Level 1 with exceptions.

Suggestion 4:

  1. Small modification from earlier working draft, keeping validity at Level 1 SC: Except where the delivery unit [not site] has documented that a specification was violated for backward compatibility or compatibility with assistive technology.

Suggestion 5:

  1. Perhaps validity could be placed in a 'how to validate' section somewhere.

Suggestion 6:

  1. Validity at level 2
  2. With techniques that address validity in the techniques for appropriate success criteria

Suggestion 7:

  1. Constrained version of validity at level 1 (e.g. only some parts or only well-formedness)
  2. Validity a requirement at level 3

Suggestion 8:

  1. Validity not explicitly required in any success criterion
  2. The foreword in the document explains the importance of validity,
  3. Validity addressed in the techniques for success criteria as it is required.

Suggestion 9:

  1. Well-formedness at L1
  2. Follow specifications at L3
  3. Validity not specifically mentioned in guidelines.

Suggestion 10:

  1. Any one of the above suggestions where validity is included, but exceptions for backward compatibility or compatibility with AT are made.