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
- 5 May 1999: WCAG 1.0
Checkpoint 3.2 "Create documents that validate to published formal grammars" Priority 2.
- Early 1999:WAI Quicktips
"Check your work. Validate. Use tools, checklist, and guidelines at http://www.w3.org/TR/WCAG"
- 25 January 2001: First WCAG 2.0 Working Draft
"markup conforms to the validity tests of the language (whether it be conforming to a schema, DTD, or other tests described in the specification)." No priorities.
- 14 June 2005: Guideline 4.1 Level 2 SC1 proposal:
"Except where the author has documented that a specification was violated for user agent compatibility (including compatibility with assistive technology), the 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), and
- used technology features as defined in the specification."
- 14 June 2005, cont: Action to investigate L1 SC to address "well-formedness" in HTML/SGML, Flash, PDF
- 15 June 2005 (ongoing): Spirited discussion
(WCAG WG mailing list, Juicy Studio, bestkungfu, WaSP Buzz, etc.).
- 30 June 2005: updated Working Draft of WCAG 2.0.
All success criteria for Guideline 4.1 replaced with an ednote.
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.
- AT manufactures have said that valid code is easier to work with
and breaks their code less.
- WCAG1 P1 checkpoints pass, but some assistive technologies (Jaws screen
reader) don't work properly.
- Broken code disproportionately effects assistive technology users more
so than mainstream browsers. The change in process to routinely
produce valid code is expensive, but will benefit PWDs more than the
mainstream.
- 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.
- Invalid code elements will cause failure when you test with text/html
browser and with application/xhtml+xml.
- Validity errors can (and sometimes
do) result in accessibility barriers
- Invalid documents are not testable, so it cannot be guaranteed that
the final rendering will be accurate for AT
- How can elements be programmatically determined if you can't be sure
that the content is valid?
- It is doubtful, and not testable, that other guidelines catch all
validity errors that could result in an accessibility barrier
- The four principles on which WCAG 2.0 is based require valid code to
be testable
- Invalidly addressing an issue could cause other issues
- 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
- 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.
- The institutionalization of validity will inevitably result in mainstream
authoring tools improving their tools.
- Validity is a stable target - if authors follow validity guidelines,
OS / browser / plug-in / AT will all improve
- Requiring validity defines a stable goal that vendors and developers
can work toward
- Validity has been a requirement in WCAG 1.0, and no one knows of a
case where someone has been prosecuted for invalid content
- 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.
- It was on the quicktips for WCAG 1.0. Do we want to remove?
- Mandatory accessibility is inevitably delegated to unmotivated institutions. Validity, more than any other criteria that impacts accessibility, is robustly resistant to casual implementation.
- 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.
- 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.
- 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.
- 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.
- 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
- Needed so that pages will work across browsers.
- The W3C and therefore this Working Group should support and encourage
use of standards properly.
- Disrespectful of other specifications, including w3C specifications
- The W3C has been remarkably supportive to accessibility with regard to
their other standards. This is the chance for WAI to give something
back.
- Validity meets the level 1 requirements for invisibility, testability and
practicality.
- 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
- Validity is not required for accesssibility. An accessible website can
still contain invalid code
- Not all aspects of validity affect accessibility
- Some enhance accessibility
- Some are neutral
- Some limit accessibility
- 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.
- Conformance is much more than validity. Why stop at validity if it is important
to support the standards?
- Requiring Validity can reduce accessibility options
- Additional markup may
be necessary to overcome problems that the specification authors
were not aware
of, and
so
is not
part of the
specification,
but could
improve accessibility
- Certain functions intended to increase direct accessibility with
AT, including code designed by AT vendors themselves, are invalid,
and there are no signs their use will recede in the foreseeable future.
- There are specific techniques that enhance accessibility but break
validity (example: use of tabindex in the DHTML Roadmap violates
the HTML spec but
makes many additional elements capable of receiving focus)
- In some documented cases, attempting to hack invalid code so that it
passes validation causes the code to be less accessible to AT.
- A level 1 validation requirement may prevent innovation of new technologies
that use new attributes not included in current specifications.
- Validity issues that relate to accessibilty should be required by other
success criteria
- If a validation error is important for accessibility, it should already
be covered by another guideline. i.e., if a table validation error
messes up the
readability of the data, it violates principle 3 and also guideline
1.3.
- There are other level 1 success criteria that safeguard against
accessibility barriers that could be introduced with invalid markup
- Is this just an HTML specific issue? XML user agents are required
to stop parsing if content is not well-formed.
- Validators do not exist for most non-markup
technologies.
- Standards cannot require other unnamed standards for conformance.
- 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).
- 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.
- 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.
- 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.
- 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.
- 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).
- 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.
- It is not appropriate to require parts of another standard that are not required by the standard itself.
- 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.
- 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:
-
Validity at Level 1
Suggestion 2:
- Level 1 SC: "Delivery units can be parsed unambiguously."
Suggestion 3:
- Validity at Level 1 with exceptions.
Suggestion 4:
- 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:
- Perhaps validity could be placed in a 'how to validate' section
somewhere.
Suggestion 6:
- Validity at level 2
- With techniques that address validity
in the techniques for appropriate success criteria
Suggestion 7:
- Constrained version of validity at level 1 (e.g. only some parts or only
well-formedness)
- Validity a requirement at level 3
Suggestion 8:
- Validity not explicitly required in any success criterion
- The foreword in
the document explains the importance of validity,
- Validity addressed in the techniques for success criteria as it is
required.
Suggestion 9:
- Well-formedness at L1
- Follow specifications at L3
- Validity not specifically mentioned in guidelines.
Suggestion 10:
- Any one of the above suggestions where validity is included, but exceptions
for backward compatibility or compatibility with AT are made.