Proposals for Principle 4

At the January 22, 2004 telecon, Gregg and I took an action item to put
together a proposal for the checkpoints under principle 4. This proposal is
an attempt to merge guideline 4.3 from the current draft with guidelines 4.1
and 4.2 and to address the open issues related to these guidelines.

The proposed text for the guideline is attached and includes links to a few
remaining open issues inline.

_______________________

NOTES

In merging 4.3 into the other guidelines, we discussed including a criteria
specifying that only widely available (language from the guideline text from
4.3) were used. However, we went around in circles trying to figure out how
to make it fit and, in the end, decided that we couldn't make it objective
in the end.

Two new examples and one new benefit have been added to Guideline 4.1.

Two of the benefits from 4.2 were removed because they overlapped
significantly with the benefits from 4.3 (which were moved up).

The titles on the examples for 4.2 were expanded and a new example has been
added.

There are a number of outstanding issues with the criteria related to
documenting technologies, graceful transformation/backward compatibility and
support for "required" technologies and testing with AT. As indicated in an
editorial note in our last working draft (Nov. 2003), some of these
criterion may still be too subjective and difficult to test. They also
overlap with authoring process rather than requirements that describe
accessible content. As proposed, these criteria address some of our open
issues and clean up the language from previous drafts, but will likely
require further discussion. 

_____________________

ISSUES

I have included a summary of all of the issues related to the guidelines
under principle 4 below. 

Issues addressed in this proposal (to be closed if this proposal is
accepted):

Note: In WCAG Bugzilla, we are using the status RESOLVED: FIXED to
differentiate issues where a proposal or action has been taken to address
them. Issues will be updated accordingly to include notes and a reference to
this proposal soon.

FIXED: 472 and 500 - These issues are at odds with one another. One suggests
that we should not allow exceptions for backward compatibility, the other
that real-world authoring issues necessitate this type of exception. As
proposed, we continue to require that authors document where they have made
validity exceptions for backward compatibility. This approach maintains an
emphasis on the importance of validity and requires that authors provide
rationale for not validating their content -- leaving room for the realities
of differing browser behaviors, compatibility with AT and the need for
occasional use of deprecated or invalid markup to support variations in how
pages are rendered across browsers. 

FIXED: 572 - The US Access board suggested that this guideline (4.1) should
be a technique rather than an accessibility guideline. However, there are
examples where the use of invalid code can pose accessibility issues. For
example, an author who uses the <TH> element in HTML to bold the text in a
table row or who uses a heading element to increase the size of a word in a
paragraph introduces false information to user agents about the organization
and structure of their content.

FIXED: 708 - Greg Lowney introduced some comments about 4.1 regarding
whether the use of a specification, in reality, leads to accessibility. In
this proposal, the first level 1 success criterion has been updated to
include compatibility with AT as an exception to validation. The level 2
criterion also notes that accessibility conventions should be used "where
appropriate".

FIXED: 481 - The proposed language for this success criterion addresses this
issue by clarifying that the technology in use is what must validate.
Removing the item about deprecated features (which can not be used in order
to validate) will hopefully minimize interpretations where people have
assumed that avoiding deprecated markup applied beyond the technology which
was being validated.

FIXED: 497 - This issue asks whether this guideline applies to non-W3C
technologies such as JavaScript or Active X. This has been addressed by
broadening the scope of 4.1 to emphasize technologies and programming
languages in a general sense rather than specifically emphasizing markup or
referring to "elements" of markup. 

FIXED: 709 - This issue includes a suggestion for an additional benefit to
4.1 from Greg Lowney and has been included in the above proposal.

FIXED: 371, 425 and 444 - These issues relate to the use of "widely
available" from 4.2. Current language in this proposal removes this phrase. 

FIXED: 423 - In this issue, Kynn Bartlett asked, "Is this checkpoint saying
use JavaScript as long as you say you're using JavaScript? Or does it mean
something else?" This comment was made about the June 2003 Public WD, when
declaring technology was a standalone checkpoint. This proposal includes the
concept of listing technologies at level 3 and is, hopefully, more clear
about why it is important.

FIXED: 458 - This issue is a vote to keep 4.2 (declare-technology) in
response to an editorial note in the June 2003 public working draft. These
requirements remain intact in this proposal, though they have been moved
down a level.

FIXED: 459 and 498 - Comments emphasizing the need to keep 4.3. In this
proposal, the success criteria from this guideline have been merged into 4.1
and 4.2, rather than removed as suggested in the Editorial note.

FIXED: 573 - Suggests that "declare tech" be deleted or incorporated
elsewhere. This issue was raised by the US Access board in response to the
June 2003 Public WD. In this proposal, the requirement to declare technology
is a level 3 requirement and is no longer a standalone checkpoint.

FIXED: 713 - Incorporated a suggestion from Greg Lowney to break the level 3
success criterion into two items.

FIXED: 714 - A suggestion from Greg Lowney noted that it might be helpful to
explicitly note the differences between 4.2 examples in their headings has
been incorporated into this proposal.

FIXED: 715 - Included rewording suggestion from Greg Lowney about the use of
metadata in documenting a list of required technologies.

FIXED: 214 - Old issue including some questions about what happens when new
technologies emerge that do not have legacy user agents (ex. SVG). Because
it is not clear what the origins of this issue were, we suggest that we
close given the significant changes that have been made to this section
since the issue was originally raised.

FIXED: 710 - Greg Lowney suggests rephrasing 4.2 due to problems with
"programmatic user interface" and notes some problems with the use of API.
This proposal removes references to APIs in this guideline and adds a
definition for "programmatic user interface component".

FIXED: 711 - Greg Lowney suggested generalizing the success criteria in 4.2
about testing with assistive technologies. This criteria has been removed in
this proposal.

FIXED: 574 - The U.S. Access Board writes: "This checkpoint seems to be a
provision that allows for a text based alternative if the primary page
cannot meet the other guidelines. If this is the correct interpretation then
it should be restated so as to be more easily understood and moved to
guideline 2." Unless the content is very simple, a text-only page should not
conform to all of the guidelines in WCAG 2.

_______________________

Issues not addressed in this proposal:

OPEN: 244 - This issue asks what happens when content is designed so that it
only works on a device for which there is no AT. It was raised initially in
a discussion related to 2.1 (keyboard access) and discussion on it was
postponed for discussion on 4.2

OPEN: 424 - In this issue, Kynn asks whether two implementations is
sufficient, pointing out that there are features that could be supported on
Mozilla and Safari, but not IE, which leaves out a large portion of an
author's potential audience.

OPEN: 713 - This issue calls for further explanation of what constitutes
sufficient documentation of a list of technologies. This issue should be
addressed at the techniques level and is not covered by this proposal.

OPEN: 426 - Issue poses the question of where authoring/development process
should be addressed. In a separate document? In techniques?

OPEN: 463 - This issue asks why a list of required technologies is
necessary. While useful for the reasons cited in benefits, the list would
only be useful if there was a standard way of creating it (ex. in metadata
so that it could be reliably interpreted by search engines and
proxy/transformation tools)

________________________


Closed issues (issues that have been closed in the process of developing
this proposal):

CLOSED: 263 - Issue related to text no longer in the draft. (Removed in the
27 October 2003 working draft)

CLOSED: 457 - Issue related to text no longer in the draft. (Removed in the
27 October 2003 working draft)

CLOSED: 385 - Issue related to text no longer in the draft. (Removed in the
27 October 2003 working draft)

Questions? Comments? Ideas?

-Ben and Gregg

P.S. Many thanks to Yvette and Loretta for their previously-posted issue
summaries and suggestions on guidelines 4.1 and 4.3. Your comments were very
helpful in pulling this proposal together.

--
Ben Caldwell | <caldwell@trace.wisc.edu>
Trace Research and Development Center <http://trace.wisc.edu>