Conformance of IBM Websphere Homepage Builder 6.0 for Windows
to W3C's Authoring Tool Accessibility Guidelines 1.0

TOOL: IBM Websphere Homepage Builder 6.0 for Windows (60 days trial)
DATE: October 2001; updated May 2002
EVALUATOR: Carlos A. Velasco
ATAG DRAFT EVALUATED AGAINST: Authoring Tool Accessibility Guidelines 1.0

Disclaimer

This conformance evaluation is for informative purposes, only. It is not meant as a definitive review of the product. The evaluation does not represent any endorsement by the W3C, the Authoring Tools Working Group (AUWG), or any of its members. The evaluation should not to be used to try to rate or compare product accessibility. The review does not necessarily reflect a consensus of the AUWG. Comments on the review can be sent to the AUWG mailing list.

This is a preliminary review of the product. IBM has not commented on this evaluation yet. Only report format and editorial comments have been received from the developer.

Introduction

This report evaluates IBM Websphere Homepage Builder 6.0 for Windows (60 days trial) according to Authoring Tool Accessibility Guidelines 1.0. It reproduces our findings in regard to the degree of support of ATAG 1.0 checkpoints. An interesting feature of this version is the introduction of an Accessibility checker.

Priority 1 checkpoints

Checkpoints Conformance
Checkpoint 1.1
Ensure that the author can produce accessible content in the markup language(s) supported by the tool. [Priority 1] (Techniques for 1.1) 		[yes, comment #1]
Checkpoint 1.2
Ensure that the tool preserves all accessibility information during authoring, transformations, and conversions. [Priority 1] (Techniques for 1.2) 		[n/a, comment #2]
Checkpoint 2.2
Ensure that the tool automatically generates valid markup. [Priority 1] (Techniques for 2.2) 		[no, comment #3]
Checkpoint 3.4
Do not automatically generate equivalent alternatives. Do not reuse previously authored alternatives without author confirmation, except when the function is known with certainty. [Priority 1] (Techniques for 3.4) 		[yes]
Checkpoint 6.1
Document all features that promote the production of accessible content. [Priority 1] (Techniques for 6.1) 		[no, comment #4]
Checkpoint 7.2
Allow the author to change the presentation within editing views without affecting the document markup. [Priority 1] (Techniques for 7.2) 		[yes]
Checkpoint 7.3
Allow the author to edit all properties of each element and object in an accessible fashion. [Priority 1] (Techniques for 7.3) 		[yes, comment #1]
Checkpoint 7.4
Ensure that the editing view allows navigation via the structure of the document in an accessible fashion. [Priority 1] (Techniques for 7.4) 		[yes, comment #1]

Relative Priority checkpoints

Note: These should be assessed by reference to the checkpoints of the Web Content Accessibility Guidelines [WCAG10], and may be met at three different levels.

Checkpoints Conformance
Checkpoint 1.3
Ensure that when the tool automatically generates markup it conforms to the W3C's Web Content Accessibility Guidelines 1.0 [WCAG10]. [Relative Priority] (Techniques for 1.3) 		[no, comment #5]
Checkpoint 1.4
Ensure that templates provided by the tool conform to the Web Content Accessibility Guidelines 1.0 [WCAG10]. [Relative Priority] (Techniques for 1.4) 		[no, comment #5]
Checkpoint 3.1
 Prompt the author to provide equivalent alternative information (e.g., captions, auditory descriptions, and collated text transcripts for video). [Relative Priority] (Techniques for 3.1) 		[no]
Checkpoint 3.2
Help the author create structured content and separate information from its presentation. [Relative Priority] (Techniques for 3.2) 		[yes, comment #6]
Checkpoint 3.3
Ensure that prepackaged content conforms to the Web Content Accessibility Guidelines 1.0 [WCAG10]. [Relative Priority] (Techniques for 3.3) 		[no, comment #7]
Checkpoint 4.1
Check for and inform the author of accessibility problems. [Relative Priority] (Techniques for 4.1) 		[yes, comment #8]
Checkpoint 4.2
 Assist authors in correcting accessibility problems. [Relative Priority] (Techniques for 4.2) 		[yes, comment #9]
Checkpoint 7.1
Use all applicable operating system and accessibility standards and conventions (Priority 1 for standards and conventions that are essential to accessibility; Priority 2 for those that are important to accessibility; Priority 3 for those that are beneficial to accessibility). (Techniques for 7.1) 		[Not Evaluated]

Priority 2 checkpoints

Checkpoints Conformance
Checkpoint 2.1
Use the latest versions of W3C Recommendations when they are available and appropriate for a task. [Priority 2] (Techniques for 2.1) 		[yes, comment #11]
Checkpoint 4.3
Allow the author to preserve markup not recognized by the tool. [Priority 2] (Techniques for 4.3) 		[yes]
Checkpoint 5.1
Ensure that functionality related to accessible authoring practices is naturally integrated into the overall look and feel of the tool. [Priority 2] (Techniques for 5.1) 		[yes]
Checkpoint 5.2
Ensure that accessible authoring practices supporting Web Content Accessibility Guidelines 1.0 [WCAG10] Priority 1 checkpoints are among the most obvious and easily initiated by the author. [Priority 2] (Techniques for 5.2) 		[no, comment #12]
Checkpoint 6.2
Ensure that creating accessible content is a naturally integrated part of the documentation, including examples. [Priority 2] (Techniques for 6.2) 		[no, comment #4]
Checkpoint 7.5
Enable editing of the structure of the document in an accessible fashion. [Priority 2] (Techniques for 7.5) 		[yes]
Checkpoint 7.6
Allow the author to search within editing views. [Priority 2] (Techniques for 7.6) 		[yes]

Priority 3 checkpoints

Checkpoints Conformance
Checkpoint 2.3
If markup produced by the tool does not conform to W3C specifications, inform the author. [Priority 3] (Techniques for 2.3) 		[yes, comment #13]
Checkpoint 3.5
Provide functionality for managing, editing, and reusing alternative equivalents for multimedia objects. [Priority 3] (Techniques for 3.5) 		[no]
Checkpoint 4.4
Provide the author with a summary of the document's accessibility status. [Priority 3] (Techniques for 4.4) 		[yes]
Checkpoint 4.5
Allow the author to transform presentation markup that is misused to convey structure into structural markup, and to transform presentation markup used for style into style sheets. [Priority 3] (Techniques for 4.5) 		[no, comment #14]
Checkpoint 6.3
In a dedicated section, document all features of the tool that promote the production of accessible content. [Priority 3] (Techniques for 6.3) 		[no, comment #14]

Comments

  1.   The tool supports most of the HTML/CSS standard tags and attributes. For those not included, the tool has a "HTML Source" mode that allows the insertion of HTML code, or a powerful "Document Outliner" that seems complete.
  2.   No import/export facility. Only HTML, xHTML.
  3.   As an example, the tool can insert images in the page without a default alt tag, or prompt the author for it.
  4.   Although there is an accessibility checker, the documentation included in the tool is very poor, does not justify the need for the techniques and how to correct problems, nor provides examples or links to external sources of information. It also covers a bare minimum spectrum of accessibility problems and ignores alternative techniques. For example, requests identification of table headers in data cells via "headers" attribute, but does not consider the "scope" attribute.
  5.   Some of the checked wizards and templates do not generate markup conforming to WCAG 1.0. For example, many images do not have ALT text.
  6.   The use of stylesheets is fairly well integrated in the interface, allowing the author to separate content and presentation.
  7.   As already mentioned for templates, there is not alternative text in prepackaged images and animations.
  8.   As mentioned early, a very limited accessibility checker is included in the Windows version, not in the Linux version.
  9.   Partially compliant. The accessibility checker does not include meaningful instructions on how to solve the accessibility problem.
  10.   Not checked.
  11.   The tool supports the latest HTML/CSS specs, and informs the author of incorrect markup.
  12.   Not all the attributes that help to design accessible websites are naturally integrated in the "Attributes" pop-up menu, being necessary hand-editing, or using the "Document Outliner".
  13.   Non-valid markup is highlighted.
  14.   Functionality not supported.