W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2004

Issue summary for Guideline 4.1

From: Ben Caldwell <caldwell@trace.wisc.edu>
Date: Thu, 28 Oct 2004 12:05:29 -0500
Message-Id: <200410281706.i9SH6vqT021998@jalopy.cae.wisc.edu>
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 

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"

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.


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.



#991. Benefits section could be stronger

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
     * 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

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

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

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)

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
         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 

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

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

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

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:51 UTC