Guideline 1. Support accessible authoring practices.

Checkpoints:

1.1 Ensure that the author can produce accessible content in the markup language(s) supported by the tool. [Priority 1]

Rationale: this is a basic requirement to allow the author to create accessible content within the tool.

At minimum (required basic functionality): the author can add or edit any elements or element properties of the language that can enhance accessibility.

More advanced (optional suggested functionality): provide an integrated interface to properties affecting accessibility (see also )

See also: checkpoint 7.2, techniques for checkpoint 1.1

Supported.DW in the WYSIWIG mode seems to support most of the structural elements of HTML40. In the code view it certainly supports adding any sort of element and tag. It does not support XHTML.

1.2 Ensure that the tool preserves all accessibility information during transformations, and conversions. [Priority 1

Rationale: Accessibility information is often vulnerable to loss when content is converted or transformed from one format into another.

At minimum (required basic functionality):Accessbility content must be preserved. Where sufficient structure information to allow reversal of the transformation is not preserved, the author must be notified that the transformation cannot be reversed accessibly. [@@issue: this requirement is still under discussion]

Optional advanced implementation: use markup, or some other mechanism to record the transformation and ensure reversibility.

Note this checkpoint covers importing from a format the tool does not use.

See also Techniques for checkpoint 1.2

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]

At minimum (required basic functionality) : Any decisions made for the author by the tool should optimize the accessibility of the content (as per WCAG). This applies to the choice of markup type, file type, and markup practices. The author may be able to override the choices proposed or made by the tool.

See also Techniques for checkpoint 1.3

---

NOTE: this is complex to check since it requires checking each individual WCAG checkpoint. When is ATAG 1.3 satisifed? when all WCAG are satisfied?

---

---

(WCAG 1.1, P1) DW does not provide textual alternatives:

• Generation of an IMG element ("insert image") does not automatically insert an ALT nor a LONGDESC attribute.
• Automatic generation of a data table ("insert tabular data") does not add TH elements nor id, scope, headers attributes.
• No ALT provided nor required for automatic navbar generation ("insert nav bar")
• No ALT is inserted nor required for clientside imagemap regions (even though the ALT attribute is shown in the inspector)
• Table insertion does not require to specify SUMMARY, ID, SCOPE, HEADERS attributes; the user can though set a checkbox to transform a row of TD's to a row of TH's;
• inserting Flash text ("insert Flash Text") creates an object with no accessible alternatives;
• same thing by inserting any Flash object or Shockwave object
• "insert Image field" inserts a button with type=image but with no ALT
• Frame insertion does not add the TITLE attribute to FRAME element
• Frame insertion adds the NAME attribute but without asking its value (e.g. "leftFrame")
• Frame insertion does not insert any NOFRAMES element
• "insert plug-in" inserts an EMBED element with no textual alternative
• same thing for "insert Applet"

However the author can override these choices, by directly editing the document.

(WCAG 1.2, P1) DW does not support in the WYSIWYG mode the definition of server-side imagemaps. Even though one can manually add such a markup. Thus no need to provide redundant text links.

(WCAG 1.5, P3) DW does not provide redundant textual links for client-side imagemaps.

(WCAG 2.1, P1) DW does not have any tool that can show how the page is rendered with no colors.

(WCAG 2.2, Images: P2, Text: P3) Does not apply since DW does not generate images (Ensure that foreground and background color combinations of generated images and text provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen.)

---

NOTE: does the previous checkpoint ever apply to some tool? should it be instead a requirement for tools like Fireworks? Does it apply also to images that are shipped with the tool and that can be included by the author?

---

(WCAG 3.3, P2) Failed. By default, DW uses HTML formatting elements. The user can select menu items and open inspector boxes that allow definition of CSS styles (as separate style sheets or in document style specs).

(WCAG 3.4, P2) Failed. By default DW presents all sizes in absolute units (i.e. pixels). It allows however the choice of relative ones.

(WCAG 3.5, P2) Failed. Users can specify headers as paragraph styles, but DW does not promote in any way their use as structuring devices.

---

NOTE: (WCAG 4.1, P1)DW does not support identification of changes of natural language. But what should an authoring tool do? Ask the language? or provide appropriate attributes in panel/inspector windows? [perhaps a set of authoring tools techniques should be associated to each/some WCAG checkpoint]

---

(WCAG 4.2, P3) Failed. DW does not handle acronyms in a way that their first occurrence is detected and their definition added.

(WCAG 4.3, P3) Failed. DW does not identify the primary language for a new blank page.

(WCAG 5.1, P1) Failed. For generated tables headers are not identified.

(WCAG 5.2, P1) Failed. DW does not insert markup to associate cells in multi-row/column tables.

(WCAG 5.3, P2) Failed. DW does not insert linearized layout tables.

(WCAG 5.5, P3) Failed. DW does not provide summaries for tables.

(WCAG 5.6, P3) Failed. DW does not provide abbreviations for table headers.

---

(WCAG 6.1, P1) NOTE. DW does not provide any automatic style rule so that additional measures should be taken to ensure accessibility.

(WCAG 6.2, P1) NOTE: I don't see how an authoring tool could "Ensure that equivalents* for generated dynamic content are updated when the dynamic content changes"

---

(WCAG 6.4, P2) Failed. Event handles are not device-independent. Automatic generation of rollovers ("insert rollover image") does not use logical events but onMouseOver, onMouseOut.

1.4 Ensure that all pre-authored content for the tool conforms to Web Content Accessibility Guidelines 1.0 [WCAG10]. [Relative Priority]

For example, templates must include accessible markup and content. Images and multimedia libraries must include accessible alternatives, such as alt text and long descriptions for images and captions, auditory descriptions and collated text transcriptions for movies. Applets and scripts must be accessible and include functional alternatives.

At minimum templates, clip art, scripts, applets, example pages, etc supplied with the tool must conform to WCAG 1 (to the conformance level claimed by the tool)

See also Techniques for checkpoint 1.4

1.5 Allow the author to preserve markup not recognized by the tool. [Priority 2]

At minimum (required basic functionality): prompt the author to confirm before removing or changing unrecognised markup. It is acceptable for a tool to reject a document it cannot process.

More advanced implementations may integrate this with the checking and repair functions of guideline 4, allowing the author finer-grained control.

Note: The author may have included or imported markup that enhances accessibility but is not recognized by the tool.

Techniques for checkpoint 1.5

---

NOTE: it is difficult to see why this checkpoint (and its "at minimum") is relevant to ATAG. A "rationale" is missing.

---

Supported. DW does not automatically change the markup.

---

Guideline 2. Generate standard markup.

Checkpoints:

2.1 Use the latest versions of W3C Recommendations when they are available and appropriate for a task. [Priority 2]

At minimum (required basic functionality): If the markup does not conform to W3C Recommendations, inform the author. [@@ issue: How do you decide when something is available (and when is it appropriate) - e.g. when does a tool have to support XHTML to conform?]

More advanced: Provide a mechanism for importing new language definitions

Rationale: W3C specifications have undergone review specifically to ensure that they do not compromise accessibility, and where possible, they enhance it.

See also: Techniques for checkpoint 2.1

Failed, since DW does not support XHTML.

---

NOTE: I was unable to understand what the following means and why it is relevant to ATAG (taken from techniques document): "A modular design that allows for the inclusion of languages will permit tools to have a language "available" later in their development cycle, or may allow tools to use languages which are not specified at the time of development. Specifications that become W3C Recommendations after an authoring tool's development cycles permit input are not considered "available" in time. (Suggested) "

---

2.2 Ensure that markup which the tool automatically generates is valid for the language the tool is generating. [Priority 1]

At minimum (required basic functionality): All markup generated by the tool must be valid @@ issue: do we need an at minimum for here?

Rationale: This is necessary for user agents to be able to render Web content in a manner appropriate to a particular user's needs.

See also: Techniques for checkpoint 2.2, Checkpoint 4.1

---

Supported, since the markup automatically produced by DW seems to be valid (a more thorough analysis needs to be carried out here).

Failed, since DW does not publish proprietary DTDs for certain XML files (like saved reports).

Partially satisfied, since DW uses specific namespaces (in the saved reports) but does not declare the namespace.

---

Guideline 3. Guide the author to produce accessible content.

Checkpoints:

3.1 Prompt the author to provide equivalent alternative information (e.g., captions, auditory descriptions, and collated text transcripts for video). [Relative Priority]

At minimum (required basic functionality): A method for adding alternative information, appropriate to the author-tool interaction, must be provided to the author whenever a non-text object (see Note) has been inserted.

Rationale:This checkpoint requires authoring tools to ask for (and support the creation of) alternate text, captions, auditory descriptions, collated text transcripts for video, etc. at times appropriate to the author-tool interaction.

Note: Some checkpoints in the Web Content Accessibility Guidelines 1.0 [WCAG10] do not apply. [@@issue: identify which checkpoints apply]

More advanced implementations might provide special authoring facilities that automate some of the process of generating alternative information (ex. voice recognition to produce collated text transcripts).

See also: Checkpoint 3.4, Techniques for checkpoint 3.1

---

Failed. DW does not prompt for alternative information. It also does not have either any preview functionality.

---

3.2 Help the author create structured content and separate information from its presentation. [Relative Priority]

At minimum: A method for adding alternative information, appropriate to the author-tool interaction, must be provided to the author whenever a non-text object (see Note) has been inserted.

Note: Some checkpoints in Web Content Accessibility Guidelines 1.0 [WCAG10] do not apply. [@@issue: identify which ones]

Techniques for checkpoint 3.2

---

NOTE: some mistake here?The at minimum condition seems unrelated to the checkpoint.

---

3.3 Do not automatically generate equivalent alternatives or reuse previously authored alternatives without author confirmation, except when the function is known with certainty. [Priority 1]

Rationale: Improperly generated alternatives can interfere with accessibility checking.

At minimum basic required functionality: Usually, when a new object is inserted, the function is unknown, so the tool should prompt the author to enter an appropriate equivalent alternative without providing a generated default entry (e.g. the file name and size). However, alternatives may be automatically generated or re-used when the tool has either placed the object for a specific purpose (e.g. navigation bar) or the user has defined a purpose for the object. Only an alternative that has been explicitly associated with an object may be offered as a default entry for the author to approve.

See also: checkpoint 1.4 and checkpoint 3.4, Techniques for checkpoint 3.3

---

Not applicable since DW does not generate equivalent alternatives.

---

3.4 Provide functionality for managing, editing, and reusing alternative equivalents for multimedia objects. [Priority 3]

Rationale: Compliance with checkpoint 3.3 may be simplified by providing an alternative equivalent management system.

At minimum: store associations between the multimedia objects and alternatives created by the author, allowing the author to edit the alternatives and reuse them easily.

More advanced implementations might collect alternatives from a variety of sources (the author, prepackaged, the Web) and provide powerful tools for managing the associations, including search functions and object similarity estimates.

See also: Techniques for checkpoint 3.4

---

Failed, since DW does not reuse nor manage equivalent alternatives.

---

Guideline 4. Provide ways of checking and correcting inaccessible content.

Many authoring tools allow authors to create documents with little or no knowledge about the underlying markup. To ensure accessibility, authoring tools must be designed so that they can (where possible, automatically) identify inaccessible markup, and enable its correction even when the markup itself is hidden from the author.

Authoring tool support for the creation of accessible Web content should account for different authoring styles. Authors who can configure the tool's accessibility features to support their regular work patterns are more likely to accept accessible authoring practices (refer to guideline 5). For example, some authors may prefer to be alerted to accessibility problems when they occur, whereas others may prefer to perform a check at the end of an editing session. This is analogous to programming environments that allow users to decide whether to check for correct code during editing or at compilation.

Note: Validation of markup is an essential aspect of checking the accessibility of content.

Checkpoints:

4.1 Check for and inform the author of accessibility problems. [Relative Priority]

At minimum (required basic functionality): this utility must provide at least one, automated or manual, check for each WCAG checkpoint (of relevant priority). When this utility runs it must always check those questions pertaining to "In General" WCAG checkpoints, but only those "conditional" WCAG checkpoints that have their conditions fulfilled by the document.

Rationale: provide the author with a utility that helps check documents for accessibility problems.

More advanced implementation: the checks should be automated to the greatest extent possible.

See also: Techniques for checkpoint 4.1

---

Supported for priority 1 WCAG.

• accessibility problems are not detected automatically; the user has to request it.
• problems are highlighted (in code view) and contextual help is provided
• manual tests are prompted
• tests are configurable
• users are assisted in ways that are consistent with look&feel of DW
• there are mechanisms to navigate through problems

---

Not supported: validation of markup.

---

4.2 Assist authors in correcting accessibility problems. [Relative Priority]

Rationale: once accessibility problems have been found, authoring tools help the author to correct them properly.

At a minimum, provide context-sensitive help with the accessibility checking required by checkpoint 4.1.

Advanced implementations: provide the author with automated or semi-automated correction tools, in addition to guidelines and examples.

See also: checkpoint 4.1 Techniques for checkpoint 4.2

---

Supported. Corrections are manual and contextual help and explanations are provided.

---

4.3 Provide the author with a summary of the document's accessibility status. [Priority 3]

Rationale: encourage authoring tools to notify authors of accessibility problems in a coherent way.

At minimum (required basic functionality): provide a list of the problems by type.

Advanced implementations might integrate the summary with the tool's repair functionality to increase the flexibility with which problems can be corrected (see checkpoint 4.2).

See also: Techniques for checkpoint 4.3

---

Supported. Users can see the problems of each page, and their status and the guideline/checkpoint they refer to.

When a new feature is added to an existing software tool without proper integration, the result is often an obvious discontinuity. Differing color schemes, fonts, interaction styles, and even software stability can be factors affecting author acceptance of the new feature. In addition, the relative prominence of different ways to accomplish the same task can influence which one the author chooses. Therefore, it is important that creating accessible content be a natural process when using an authoring tool.

Checkpoints:

Guideline 6. Promote accessibility in help and documentation.

Checkpoints:

6.1 Document all features that promote the production of accessible content. [Priority 1]

Rationale: Documenting each accessibility related feature of the tool (dialog boxes, utility, code views, etc.) will help authors to learn how to use them effectively.

At minimum (required basic functionality): Document the purpose and use of all features of the tool that help create accessible content.

More advanced implementations Provide context-sensitive links to this documentation from the actual features, within the authoring tool user interface. Also provide a dedicated "Accessibility" section of the documentation for this material.

See also: checkpoint 5.4, Techniques for checkpoint 6.1

---

Supported. The online documentation does have a specific manual/help dedicated to accessibility. However Dreamweaver's documentation (not 508AS's one) does not mention accessibility explicitly.

Failed: DW documented examples do not include accessibility-related practices.

---

NOTE: the techs doc. refer to a checkpoiint different than the next one: Ensure that creating accessible content is a naturally integrated part of the documentation, including examples

6.2 Document the process of using the tool to produce accessible content. [Relative Priority]

Rationale: Motivated users of the tool may be able to produce accessible content without the support provided by mechanisms such as accessibility checking and repair functions.

At minimum (required basic functionality): Document the techniques required to meet all WCAG checkpoints at the relevant priority level - (these may include work-around methods where the tool does not yet have the appropriate functionality).

Optional advanced functionality: Automating the process of producing accessible content will mean that nothing special needs to be done to meet this checkpoint. But providing context-senstive linking to this documentation may be an intermediary development strategy.

See also: Techniques for checkpoint 6.2

---

Supported. The accessibility manual has a section describing the process. In addition, most of the problems contain links to examples and tutorials, available on the web, on retrofitting accessibility. However this documentation is not well integrated into the global documentation of Dreamweaver.

---

Guideline 7. Ensure that the authoring tool is accessible to authors with disabilities.

Checkpoints:

7.1 Ensure that the authoring interface follows all operating environment conventions that benefit accessibility (Applies at three priority levels: [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).

This checkpoint requires all aspects of the authoring interface to be accessible to the author. This wide scope means that the checkpoint applies to the implementation of all the other checkpoints in this guidelines document. The techniques for this checkpoint include references to checklists and guidelines for a number of platforms and to general guidelines for accessible applications. In many cases several sets of standards will be applicable. @@issue - there is no minimum here

See also: Techniques for checkpoint 7.1

---

Haven't checked.

7.2 Ensure that the authoring interface enables accessible editing of all element and object properties. [Priority 1]

Note This checkpoint is a special case of checkpoint 7.1 that is especially important to authoring tools.

At minimum (required basic functionality): provide at least one accessible way to edit every element and object property supported by the tool.

More advanced implementations might ensure that all of the ways in which the tool allows element and object properties to be edited should be accessible.

See also

Techniques for checkpoint 7.2

---

Haven't checked.

---

7.3 Ensure that the authoring interface enables the author to edit the structure of the document [Priority 2]

Note This checkpoint is a special case of checkpoint 7.1 that is especially important to authoring tools.

At minimum (required basic functionality): the checkpoint requires that the author be able to copy, cut or paste an element and its content at any level of the document tree hierarchy.

More advanced implementations might provide more powerful ways to edit elements or groups of elements in the structure.

See also: Techniques for checkpoint 7.3

---

Supported.

---

7.4 Allow the display preferences of the authoring interface to be changed without affecting the document markup. [Priority 1]

Note This checkpoint applies primarily to WYSIWYG markup editing tools and requires that the author be able to view the content, as it is being authored, in a way that differs from the presumed default appearance of the rendered content.

At minimum there must be some mechanism for changing the document display independently of the document markup.

There are a number of ways that this can be achieved, including supporting operating environment display preferences and allowing the author to specify an editing style sheet that is different from those included with the end document. In addition, there must be some means by which textual alternatives can be displayed to the author in place of non-text elements. @@issue - need to clean this paragraph up - some is techniques, plus wording and some is useful for the checkpoint

See also: Techniques for checkpoint 7.4

---

Supported.

---

7.5 Ensure that the authoring interface enables accessible navigation of editing views via the document structure. [Priority 2 (was P1 in ATAG10)]

Rationale: simplify navigation for the author.

At minimum, the author should be able to move from element to element. @@issue: is this actually what we need?

More advanced implementations might provide highly flexible mechanisms that take advantage of the hierarchical nature of the document tree.

See also: Techniques for checkpoint 7.5

---

NOTE: Haven't checked as it is not clear.

---

7.6 Ensure the authoring interface allows the author to search within the editing views. [Priority 2]

Note This checkpoint requires that tools provide a search facility. While this is a common feature in most text markup editing tools, it is less common for other authoring tools (i.e. SVG and editors).

At minimum, the tool should allow basic text search with a choice of skipping or including markup

More advanced implementations might have more powerful mechanisms that, for example, can search on the basis of structure or similarity.

See also: Techniques for checkpoint 7.6

---

Supported

---