[4.1] Overview and summary of guideline 4.1

Summary of guideline 4.1 


Introduction

This document is meant to review guideline 4.1 and discuss the open issues
with this guideline. This summary is the result of an action item from the
December 11, 2003 teleconference where it was decided to assign the WCAG 2
guidelines to different people who can summarize the issues in order to get
more discussion about the guidelines. 
 
Guideline 4.1 reads: "Technologies are used according to specification" [1].
There is one level 1 succes criterion which can be summarized as "use markup
according to specification". The level 1 success criterion allows deviation
of that for the purpose of backward compatibility. To pass level 2,
deviations to accommodate for backward compatibility are NOT allowed. There
are no other succes criteria. 
 
The content of this document is devided into different topics. First, the
outstanding issues will be discussed. The open issues in Bugzilla will be
presented here, followed by a summary of the issues underlying these bug
reports. Next, possible solutions will be discussed, both previously
suggested solutions and new solutions. This is followed by an overview of
the dependencies between guideline 4.1 and other guidelines in WCAG 2. Next,
the underlying assumptions of the author will be discussed in brief.
Finally, a rationale is given why this guideline is important for WCAG 2.

Outstanding issues


Issues in Bugzilla 


Issue 263: Min level SC has no examples. Confusing? [2]

Description of the issue:
This issue refers to a previous version of the draft, where a minimum level
(level 1) requirement read "accessibility features and API's are used when
available." 
In the Feb 27, 2003 telecon it was decided to leave this success criterion
in even though we did not have any examples for it. The question raised in
this issue is whether this is confusing or not.

Issue 457: Remove items 2 and 3 [3]

This issue refers to the June 24, 2003 public working draft [4]. Sherman
Meeds comments that items 2 and 3 are not only superfluous but ambigious and
should be taken out. Item 2 reads "for Application Programming Interfaces
(API's), programming standards for the language are followed.", item 3 reads
"accessibility features and API's are used when available." 

Issue 472: Validity should always be required [5]

In the public comments mailing list, Tina Holmboe expresses her concern that
WCAG 2 is formulated too weakly. This comment refers to the June 24, 2003
public working draft [4]. 
 
She is afraid that the provision for backward compatibility gives carte
blanche for site developers to ditch the standards as long as they tell
users what they're up to. 
 
She suggests the following rewrite:
"All code, whether structure (such as HTML), presentational (css), logical
(script), or otherwise should follow a formal, published, standard. If
possible, the code should pass validity tests for that same standard. [a
note should be added that this isn't strictly possible for scripts, but
should ALWAYS be done otherwise]"

Issue 481: Clear definition of language used [6]

Referring to the public working draft of June 24, 2003 [4], Olivier Thereaux
makes the following remark:
"The language used, itself, must be clearly defined (with appropriate MIME
headers, doctype declaration, etc)."

Issue 497: non W3C techs and until user agents [7]

In a public comment on the public working draft of June 24, 2003 [4], Greg
Gay wonders whether 4.1 includes non-W3C technologies as well. He writes:
"Does this include nonW3C technologies: Javascript, Active X, Flash,... used
according to specification? Can developers use these  technologies if they
are designed with accessibility features. How would an evaluator determine
if Javascript or perhaps Flash has been used to  specification? Whose
specification for Javascript. I also would imagine Javascript can be used to
specification, but be innaccessible. In combination with the "device
independence" guideline, this might work"

Issue 500: Concession for necessary violations and workarounds [8]

In addition to the previous issue, Greg Gay emphasizes that in real world
situations, developers need to be able to use workarounds that violate
guidelines, 
provided they are necessary and they are documented in an accessibility
statement. He gives some examples (use of target-attribute to spawn new
windows, lack of support for font size in EM in Netscape 4) to illustrate
this necessity.

Issue 572: "use tech according to spec" is good technique, not accessibility
issue [9]

The US Access Board feels that this guideline seems to address good
authoring techniques and is not an accessibility issue.

Summary of issues


Is validity an accessibility issue?

The need to use technologies according to specification is a broader issue
than most of the guidelines in WCAG. In issue 572 as well as on the
mailinglist, people have wondered whether this guideline should be in WCAG
because they feel it's not about accessibility. Others have argued that
valid markup increases the chances of correct rendering of the content which
directly benefits accessibility.

Validition versus necessary violations

There seem to be two camps in the whole validation discussion. One camp says
you should always require valid code, since only then can user agents know
how to render the content. Issue 472 is a comment from this side. The other
camp says that violations of the specifications are sometimes necessary to
achieve the desired result. Issue 572 is a result of this viewpoint.

Do we include the use of API's in this guideline? 

The former versions of the WCAG 2 included two requirements for API's: "for
Application Programming Interfaces (API's), programming standards for the
language are followed.", and "accessibility features and API's are used when
available." Issue 263 finds the last one confusing since we don't give any
examples. Issue 457 suggests to remove both the items.

Applicability to non-W3C technologies

Guideline 4.1 only says to use technologies according to specification, but
not every technology has a well-defined specification. Many proprietary
standards exist, or technologies exist for which several companies use
different specifications. Do we allow the use of proprietary technologies?
How can you determine whether a proprietary technology has been used
according to specification? Why are there no success criteria dealing with
non-markup content?

Transitional standards allowed?

A certain level of backward compatibility is built in the transitional
variants of the HTML specification. It is not clear whether 4.1 means you
can only use the strict HTML specification or if the transitional variants
are allowed as well. In a thread on the mailinglist last week, Don McCunn
clearly thinks 4.1 means you can only use strict HTML whereas Yvette Hoitink
thinks transitional is allowed since this is following the (transitional)
specification. [10].

Proposed solutions


Previously proposed solutions


Remove requirements 2 and 3 

According to the change history of WCAG 2 [11], two of the requirements that
existed in previous drafts have been removed in the October 27, 2003 working
draft. These are:

*	for Application Programming Interfaces (API's), programming
standards for the language are followed 

*	accessibility features and API's are used when available

This means issue 263 is no longer an issue (there can be no confusion over a
deleted section) and issue 457 is resolved. The second requirement is now
covered by guideline 4.2, under level 2 success criteria. 

Move "deprecated features are avoided" into best practices

In July 2003, Gregg Vanderheiden suggested to move "deprecated features are
avoided" out of the success criteria into the best practices. [12]. Moving
this requirement to level 3 allows for the use of transitional versions of
the HTML standards.

New proposed solutions


Improve description of benefits of the guideline

With an improved descriptions of the benefits, it should be possible to make
it clear that following this guideline helps the accessibility of web
content, and that this guideline is an accessibility issue.
 
The current version of 4.1 includes a description of the benefit of 4.1
which says that it the benefits of following specifications are primarily
that assistive technologies and user agents can render the content according
to spec. This is not the only reason. If the author does not follow markup
specifications, it is left up to the user agent to interpret this
pseudo-markup. Since authors usually only test their content in a few
frequently used user agents, there is no way to predict how other user
agents (such as speech synthesizers or text browsers) will interpret this
data. 
Following specifications also means author cannot use newly invented tags
that are supported in some user agents but are not part of the specification
(for example the scrollbar colors in Internet Explorer, Marquee). This means
writing valid code is a step towards making the web content available across
different user agents. 

Add example with backward compatibility

Since backward compatibility questions keep popping up, it would be wise to
include an example of how and when to allow for backward compatibility. 

Clarify if transitional specifications are allowed or not

W3C already made provisions for backward compatibility in the HTML standards
by creating the transitional versions of HTML 4 and XHTML 1. The requirement
"depricated features are avoided" is interpreted by somepeople as "Only use
strict HTML" for HTML documents. Other people, including myself do not think
that this is the case, because WCAG would not require a higher level of
validity than the HTML specifications. If the markup follows HTML
specifications, whether it's HTML 4.01 transitional or XHTML 1.0 strict, you
pass. 
Because of the controversy of this point, it should be made clear whether
using transitional HTML is allowed, for instance by including an example
that uses transitional HTML.

Re-include requirement to follow specifications for non-markup content

The guideline says that all technologies must be used according to
specification, but in the checkpoints we only talk about markup. This makes
the success criteria for 4.1 much narrower than the guideline itself. The
eliminated requirements about API did address non-markup content.
 
What shall we require about non-markup content such as Java applets,
Javascripts etc.? Since no open standards exist for these technologies, it
would be hard to make this a level 1 requirement, but we might include a
level 2 or 3 requirement to follow specifications or guidelines for
non-markup content, if they exist for the chosen technology. This is similar
to the removed requirement "for Application Programming Interfaces (API's),
programming standards for the language are followed". Re-including this
requirement answers issue 497 because we then explicitely include other
technologies.

Dependencies between guidelines


Accessibility features

The requirement to use accessibility features if present has some relation
with all the guidelines of the 'Operable' principle. If an author does not
use the accessibility features, the content may become less operable. 
 
For accessibility features, there is some overlap with guideline 4.2.
Guideline 4.1 requires the use of accessibility features of the markup
language, whereas guideline 4.2 requires the use of accessible programmatic
interfaces.

Avoid unexpected behavior

When following the specifications, you reduce the chance of the occurrence
of unexpected behavior. This helps to meet guideline 2.5 ("Methods are
provided to minimize error and provide graceful recovery") and guideline 3.4
("Layout and behavior of content is consistent or predictable, but not
identical.") as well.  

Using structural elements for presentation

Using structural elements for presentation is not allowed by guideline 4.1
because that's not using the elements according to specification. This is
also covered to some extent by guideline 1.3: 'Information, functionality,
and structure are separable from presentation." 

Assumptions

I have assumed that the working group values validity, but recognizes
sometimes greater accessibility can only be achieved if the specifications
are broken. The reason I assumed this is because of provision for backward
compatibility in the formulation of the level 1 success criterion.
 
I have assumed that the main aim of this guideline is to use valid markup,
and that it doesn't matter which 'flavor' of the specification you choose,
as long as you document which and follow it strictly. In HTML terms, this
means I think writing a page in valid transitional HTML would satisfy the
checkpoints for guideline 4.1, even with "deprecated features are avoided"
as a level 1 success criterion. I do think this should be clarified. 
 
Also, I have assumed that guideline 4.1 was originally intended for all web
content, not just markup. If that's the case we should revisit some past
issues since the current success criteria deal with markup only. 

Rationale

This guideline benefits accessibility in different ways:

*	Valid markup increases the chances of correct rendering of the
content 

*	It forbids the abuse of structural elements for presentational
purposes and vice versa, which can be very confusing 

*	It stimulates the use of accessibility features of the markup
language


Author

This summary was written by Yvette Hoitink, January 2004 
Contact: y.p.hoitink@heritas.nl 

Notes

[1]. Unless stated otherwise, texts of guidelines and checkpoints are taken
from the latest internal draft of the WCAG 2, version November 17, 2003,
available at http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20031117.html
[2]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=263a
[3]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=457
[4]. http://www.w3.org/TR/2003/WD-WCAG20-20030624/
[5]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=472
[6]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=481
[7]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=497
[8]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=500
[9]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=572
[10]. http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JanMar/0019.html
[11]. http://www.w3.org/WAI/GL/WCAG20/change-history.html
[12]. http://lists.w3.org/Archives/Public/w3c-wai-gl/2003JulSep/0056.html