Macromedia Dreamweaver 4.0 evaluation

Introduction

This report evaluates Macromedia Dreamweaver 4.0 according to Authoring Tool Accessibility Guidelines 1.0. It reproduces findings in regard to the degree of support of ATAG 1.0 checkpoints.

Dreamweaver, together with Microsoft Frontpage, is one of the most popular web design tools, specially among web designers not so familiar with HTML and CSS. It has also a wide implementation because its localization to many EU languages.

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]
Checkpoint 1.2
Ensure that the tool preserves all accessibility information during authoring, transformations, and conversions. [Priority 1] (Techniques for 1.2) 		[yes]
Checkpoint 2.2
Ensure that the tool automatically generates valid markup. [Priority 1] (Techniques for 2.2) 		[no]
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]
Checkpoint 7.2
Allow the author to change the presentation within editing views without affecting the document markup. [Priority 1] (Techniques for 7.2) 		[no]
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]
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]

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]
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) 		[n/a]
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]
Checkpoint 3.3
Ensure that prepackaged content conforms to the Web Content Accessibility Guidelines 1.0 [WCAG10]. [Relative Priority] (Techniques for 3.3) 		[no]
Checkpoint 4.1
Check for and inform the author of accessibility problems. [Relative Priority] (Techniques for 4.1) 		[no]
Checkpoint 4.2
 Assist authors in correcting accessibility problems. [Relative Priority] (Techniques for 4.2) 		[no]
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) 		[n/a]

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) 		[no]
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) 		[no]
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]
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]
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) 		[no]
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) 		[yes]
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) 		[yes]
 

Comments

  1.   Although not all the HTML tags and attributes are supported in the WYSIWYG mode, it is possible to manually do so in the Edit-source mode.
  2.   Partial compliance. It generates automatically valid markup, although it might not correspond to the specified DOCTYPE.
  3.   Both the English and German version document thoroughly HTML and CSS. However, it is not documented how these elements help to create accessible content. The only reference found on the topic within the help is the reference to Macromedia's website and to WAI's web site.
  4.   Using the preferences menu function, it is possible to change many of the editor presentation settings. However, it is not possible to define an "editing" stylesheet independent of the presentation stylesheet.
  5.   It provides accessible "Select parent tag" and "Select child" functions. Also specific tags may be searched for. Note: Although it is possible to edit a table element by hand in the code view, there appears to be no way to enter/exit a table in the WYSIWYG with the keys except using PgUp and PgDn which are too imprecise for most purposes.
  6.   The tool allows a document to be created by dragging and dropping images and saving without ever prompting for the insertion of an alt attribute. In addition, an automated tool for creating rollover images is included that also does not prompt for alt text. It also automatically generates HTML FONT markup for colors instead of using style sheets.
  7.   Trial versions do not appear to have default templates.
  8.   Although the tool does include a high priority field for alt text in the properties bar, it does not prompt the user for other required equivalents, such as longdesc or text transcripts. Also, the image properties bar is not displayed when an image is drag and dropped.
  9.   It does provide support for the proper use headings, style sheets, alt text and other content. However, this answer is qualified since the tool does not usually prompt for alternate equivalents.
  10.   It does not include pre-written alt text for packaged images.
  11.   Macromedia offers an extension to Dreamweaver that allows the user to request an automated check of common 15 accessibility problems. In addition, it includes (english version) a list of suggested manual checks that encompass some of the Priority 1 checkpoints in WCAG 1.0. Unfortunately, there seem to be no suggested manual check for alternate equivalents besides alt text as required by WCAG 10 (Checkpoint 1.1), such as transcripts for audio, and longdesc for images.
  12.   The accessibility checker provides links to the WCAG document for the Priority 1 WCAG 1.0 checkpoints that it detects automatically or suggests manual checks for. However, as with 4.1, there are some P1 problems that DW4 does not suggest manual checks for or provide a link for.
  13.   Not tested.
  14.   Not all the W3C attributes of the HTML 4.01 are automatically supported, although the author can add them manually.
  15.   The accessibility checker is not a natural part of Dreamweaver's interface.
  16.   For example, the only use of the term noframes in the help section is in a single, stand-alone page about how to create noframes content. In addition, the help content for inserting images mentions alt in the image properties, but the only example of the image properties bar in action, shows the align drop down covering the alt field.
  17.   It provides powerful structure editing including "Select parent tag" and "Select child" functions.
  18.   It provides a powerful searching function that can search the source, the WYSIWYG text, tags, etc.
  19.   The author of the report has been able to introduce manually invalid markup without problems.
  20.   In a very limited way with the accessibility checker.
  21.   This appears to be possible using a combination of "find and replace", "clean up HTML", "clean up Word HTML" and a command recorder.
  22.   The accessibility features of Dreamweaver are posted on the Web at: http://www.macromedia.com/Macromedia/accessibility/features/dreamweaver.html.

Acknowledgements

This report has been ellaborated based on the conformance evaluation made by Jan Richards for the Authoring Tool Accessibility Guidelines Working Group. This report has been completed by the download of the Trial version in German under the scope of WAI-DA.