- From: Ben Caldwell <caldwell@trace.wisc.edu>
- Date: Thu, 28 Oct 2004 12:05:29 -0500
- To: "'WAI GL \(E-mail\)'" <w3c-wai-gl@w3.org>
At last week's face to face, I took an action item to review issues related to guideline 4.1. A summary and proposed resolution for each open issue follows.
Editorial Issues:
#820. Java API example more appropriate for
technology-supports-access
<http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=820>
Description: This issue suggests moving example 3 from guideline 4.1 to 4.2.
Recommendation: Accept the proposal to move this example.
-----------
#968. Don't use "elements designed for applying stylistic and presentational characteristics"
<http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=968>
Description: This issue suggests that the phrasing suggests using elements like <font> and <b> and suggests replacing the phrase "elements designed for applying stylistic and presentational characteristics" with "elements devoid of semantic meaning."
Recommendation: Revise the example as suggested.
<proposed>
Example 2: presentation elements.
A Web author wishes to focus attention on a series of words on a page for purely artistic reasons. He uses elements devoid of semantic meaning, rather than elements that are designed to convey information about the structure or organization of a page, to enhance the visual presentation and avoids implying unintended meaning about page organization for non-visual or text-only users.
</proposed>
-----------
#991. Benefits section could be stronger
<http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=991>
Description: RNID suggests that the benefits of this checkpoint do not adequately address the advantages of following specifications.
Recommendation: Emphasize these advantages and revise the benefits section as follows (no change to first two bullets, added bullets 3 and 4):
Who Benefits from Guideline 4.1 (Informative)
* This guideline further emphasizes that following specifications
increases the likelihood of accessible content. While other
guidelines refer to individual pieces of content, this guideline
takes a step back to look at the broad picture. It also exists to
help cover future technologies or issues that we did not
anticipate at the time of writing this guideline. Thus, the
benefits of following specifications are primarily that assistive
technologies and user agents can render the content according to
specification.
* Following specifications for markup and other file formats makes
it possible to more easily reformat, repurpose and reuse content,
which is important to users who can only make full use of content
when presented in a particular format.
* Valid use of structural markup enables assistive technologies and
user agents such as screen readers and sign language avatars to
accurately interpret the document.
* Following specifications benefits all users through improved
rendering of content by user agents on a variety of software and
hardware platforms.
-----------
# 1220. Example 3: use link to an example aimed at broader audience
<http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1220>
Description: Sun comments suggest an alternate link for example 3, which currently points to the IBM Guidelines for Writing Accessible Applications Using 100% Pure Java. As an alternative, they suggest linking to the Sun Microsystems Accessibility Program Developer Information page at http://www.sun.com/access/developers/index.html because it includes information targeted at a wider audience.
Recommendation: Accept Sun's suggestion and update the link, which points to a variety of resources in addition to the IBM guidelines.
-------------------------------------------
Issues that need further discussion:
#887. All of Principle 4 is not enforceable or testable except through 20/20 hindsight
<http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=887>
Description: In this issue, the Access Board asserts that it is not possible to predict the future of technology and seems to imply that a risk of attempting to adjust for changes in future technologies has the potential to result in disservice for individuals with disabilities.
Recommendation: Principles themselves are not meant to be testable. Rather, they serve as a title introducing a collection of related guidelines and describe goals that accessible content strives to achieve. Guidelines and success criterion, however, are meant to be testable and guidelines 4.1 and 4.2 are both testable and enforceable steps toward the goal of robust Web content. No change to the guidelines.
--------------
#888. Nonstandard coding is poor design, not a unique
accessibility issue
<http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=888>
Description: This issue (also 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 whether our decisions about baseline at the face to face necessitate making the level 1 criterion more strict (as recommended by James Craig in comment #2):
<alternate proposal 1>
Retain existing level 1 criterion and promote current level 3 criterion to level 1
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]
a. 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),
b. 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 alternate proposal 1>
<alternate 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: This recommendation would necessitate removing the level 3 success criterion in the latest draft, "Technologies are used according to specification without exception. [V]"
<end alternate proposal 2>
<alternate thought>
Combine guidelines 4.1 and 4.2 to cover compatibility with user agents including AT in one guideline?
<end alternate thought>
Principle 4: Content must be compatible with current and future assistive technologies and user agents.
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.
--------------
933. Clarify that we don't mean that everything must be
backwards-compatible
<http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=933>
Description: This issue suggests that 4.1 can be interpreted to mean, "make content backwards-compatible."
Recommendation: Depends on resolution to #888. If we remove exceptions for backward compatibility and compatibility with AT, this would no longer be an issue.
--------------
966. Level 3 SC should be level 2
<http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=966>
Description: Suggests moving the level 3 criterion, "Technologies are used according to specification without exception. [V]" to level 2.
Recommendation: Also depends on #888, where one option is to promote this criterion to level 1.
------------------------------------------
Unresolved Issues:
1161. not all AT can understand Java accessible APIs
<http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1161>
Description: This issue points out that assistive technologies on some countries are less able to understand technologies such as Java accessible APIs.
Recommendation: This relates to baseline discussions and may not be something we can close at this point in time.
--
Ben Caldwell | <caldwell@trace.wisc.edu>
Trace Research and Development Center <http://trace.wisc.edu>
Received on Thursday, 28 October 2004 17:08:37 UTC