Evaluation of Dreamweaver

By Giorgio Brajnik (giorgio@dimi.uniud.it)

6 August 2001

The tool being evaluated is:

The dreamweaver patch 4.01 is not essential to this evaluation. It affects only 508AS in a minor way (ability to detect spacer images by inspecting the sizes of the GIF image).

It will be called DW.

Notes in this document refer to the evaluation process, text of ATAG techniques or guidelines documents.

0. Introduction

This document is based on the "wombat" draft version of the ATAG 1.0 dated 12 July 2001.

I added, marked in green and red comments about the compliance of DW with respect to those guidelines.

Yellow paragraphs are notes concerning the evaluation process, the ATAG documents (guidelines and techniques, Aug 1,2001 draft). They report my doubts and comments.

1. Category

DW is a markup editing tool; it does not offer any functionality to define and edit multimedia documents; it is not a content management tool; it is not a programming environment (though its editor is javascript aware, andf DW is extendible using javascript, but it lacks debuggers and access to the interpreter).

NOTE: I think that strictly speaking and according to the given definition of programming tool, DW should be considered a programming tool. Even more Ultradev (which is Dreamweaver enriched with the ability to visually define queries to a database). But I don't agree because a programming environment to me means something that supports:

and DW does not offer any of these.

The given definition is:Programming Tools:Tools for creating all kinds of Web Applications, including Java applets, Flash, server and client-side scripts, etc.Also includes tools that assist authors to create markup languages (i.e. XML) and tools that assist authors to create user interfaces (i.e. UIML?).

Also in this case I would like to see positive and negative examples.

NOTE: add some example (like tidy) for the category "conversion tools" in the techniques doc.

2. Guidelines (taken from ATAG-wombat 010712)

Guideline 1. Support accessible authoring practices.

If the tool automatically generates markup, many authors will be unaware of the accessibility status of the final content unless they expend extra effort to review it and make appropriate corrections by hand. Since many authors are unfamiliar with accessibility, authoring tools are responsible for automatically generating accessible markup, and where appropriate, for guiding the author in producing accessible content.

Many applications feature the ability to convert documents from other formats (e.g., Rich Text Format) into a markup format specifically intended for the Web such as HTML. Markup changes may also be made to facilitate efficient editing and manipulation. It is essential that these processes do not introduce inaccessible markup or remove accessibility content, particularly when a tool hides the markup changes from the author's view


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.

NOTE: add a link to a description of "structural elements" in the techs doc

NOTE: the technique regarding multimedia tools "Allow the addition of equivalent alternatives for all supported image formats that allow text content, including PNG, SVG, WebCGM, JPEG, and GIF" seems to me out of context. Isn't it related with WCAG? Why don't move this requirement to guideline 3?

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

Supported (but see note below).

NOTE: in reality this checkpoint does not seem to apply to DW. I included it because after reading the techniques that are associated to it I thought that some was relevant to DW.

NOTE: I don't think the"optional advanced implementation" section in the checkpoint description is particularly useful. Implementations will depend on the kind of tool and the specific functionality being inspected. Thus they will be much more specific than the checkpoint. The evaluator should go to the techniques document to get more details.

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:

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.

NOTE: I stopped here because of lack of time. The analysis should be continued with the rest of WCAG checkpoints.

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

Not supported. Templates are examples of accessible site types and are themselves accessible.

But some of them is not accessible (eg. corporate 508/index.html has images with no ALT defined)

NOTE: for the following technique "For tools that allow author's to create their own templates, advise the author that templates should be held to a high accessibility standard, since they will be repeatedly re-used. Help the author reach this goal by making an accessibility check mandatory before saving as a template. (Suggested)":

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.

NOTE: no techniques provided for this checkpoint.

Guideline 2. Generate standard markup.

Conformance with standards promotes interoperability and accessibility by making it easier to create specialized user agents that address the needs of users with disabilities. In particular, many assistive technologies used with browsers and multimedia players are only able to provide access to Web documents that use valid markup. Therefore, valid markup is an essential aspect of authoring tool accessibility.

Where applicable use W3C Recommendations, which have been reviewed to ensure accessibility and interoperability. If there are no applicable W3C Recommendations, use a published standard that enables accessibility.


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.

Well-structured information and equivalent alternative information are cornerstones of accessible design, allowing information to be presented in a way most appropriate for the needs of the user without constraining the creativity of the author. Yet producing equivalent information, such as text alternatives for images and auditory descriptions of video, can be one of the most challenging aspects of Web design, and authoring tool developers should attempt to facilitate and automate the mechanics of this process. For example, prompting authors to include equivalent alternative information such as text equivalents, captions, and auditory descriptions at appropriate times can greatly ease the burden for authors. Where such information can be mechanically determined and offered as a choice for the author (e.g., the function of icons in an automatically-generated navigation bar, or expansion of acronyms from a dictionary), the tool can assist the author. At the same time, the tool can reinforce the need for such information and the author's role in ensuring that it is used appropriately in each instance.

NOTE: in the previous intro "well-structured information" is a requirement for accessibility but:


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.


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.

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.

NOTE there are techniques that do not refer to approproate or existing checkpoints (maybe obsolete?) eg. 4.3, 4.4, 4.5

Guideline 5. Integrate accessibility solutions into the overall "look and feel".

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.


5.1 Ensure that the functionalities for checkpoints 3.1, 3.2 and 4.1 are always clearly available to the user [Priority 1]
Rationale: The user must be easily able to turn on accessibility support functionality

Minimum (required basic functionality): The user interface component to initiate the function must be a visible part of the main user interface

More advanced (suggested): Allow the user to configure this to happen on a schedule or at user request

See also: checkpoints 3.1, 3.2, 4.1, 4.2 Techniques for checkpoint 5.2

Supported. DW offers those functionality as commands from a top-level, always visible, menu called "Accessibility", that is shown in any relevant window.

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]
Note: This checkpoint extends the requirements of checkpoint 5.1 to cover more functionalities

Rationale: that accessibility-related functionality be integrated as seamlessly as possible.

At minimum, the accessibility features should not contrast with the normal operation of the tool. This means that they should be operable with approximately the same number of mouse clicks or keystrokes, the same amount of instruction, and the same degree of flexibility as other features.

For example, if an element's properties are displayed in a floating toolbar, accessibility-related prompts should be added to this toolbar, not implemented as intrusive pop-up boxes.

More advanced implementations might see accessibility features such as checking, integrated to the same level as analogous features unrelated to accessibility.

For example, if underlining or color changes are used to notify the author, while they work, of syntax and spelling errors, accessibility problems should be similarly flagged.

See also: Techniques for checkpoint 5.2

Supported. See above.
5.3 Ensure that all functionality (prompts, checkers, information icons, etc.) related to accessible authoring practices is naturally integrated into the overall look and feel of the tool. [Priority 2]
Rationale: user interfaces can increase the probability that authors will use accessible authoring practices, even when less accessible alternatives are provided by the tool for reasons of completeness.

At minimum, when there is an accessible and a less accessible means for performing an action, the user interface of the tool should be organized so that the accessible means is at least as visible in the user interface and at least as easy to activate in terms of mouse clicks and keystrokes than the less accessible means.

More advanced solutions might purposefully impede the visibility and use of the less accessible means.

See also: Techniques for checkpoint 5.3

Failed. DW does not have accessibility aware inspectors.
5.4 Ensure that creating accessible content is a naturally integrated part of the documentation, including examples. [Relative Priority]
This checkpoint promotes the production of accessible content by implicitly demonstrating to the author that all content, regardless of purpose, should comply with the WCAG guidelines.

At minimum (required basic functionality): all documented examples of the authoring tool interface (i.e. dialog boxes, code views, etc.) should include any relevant accessible authoring practices.

See also: Techniques for checkpoint 5.4

NOTE: why should this checkpoint have relative priority? are we asking that the evaluator should go through all WCAG checkpoints and ensure that the documentation reports on each of them? It looks to much to me.

Failed. Examples and documentation, other than the 508AS manual, do not promote accessibility.

Guideline 6. Promote accessibility in help and documentation.

Web authors may not be familiar with accessibility issues that arise when creating Web content. Therefore, help and documentation must include explanations of accessibility problems, and should demonstrate solutions with examples.


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.

The authoring tool is a software program with standard user interface elements and as such must be designed according to relevant user interface accessibility guidelines. When custom interface components are created, it is essential that they be accessible through the standard access mechanisms for the relevant platform so that assistive technologies can be used with them.

Some additional user interface design considerations apply specifically to Web authoring tools. For instance, authoring tools must ensure that the author can edit (in an editing view) using one set of stylistic preferences and publish using different styles. Authors with low vision may need large text when editing but want to publish with a smaller default text size. The style preferences of the editing view must not affect the markup of the published document.

Authoring tools must also ensure that the author can navigate a document efficiently while editing, regardless of disability. Authors who use screen readers, refreshable braille displays, or screen magnifiers can make limited use (if at all) of graphical artifacts that communicate the structure of the document and act as signposts when traversing it. Authors who cannot use a mouse (e.g., people with physical disabilities or who are blind) must use the slow and tiring process of moving one step at a time through the document to access the desired content, unless more efficient navigation methods are available. Authoring tools should therefore provide an editing view that conveys a sense of the overall structure and allows structured navigation.

Note: Documentation, help files, and installation are part of the software and need to be available in an accessible form.


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


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


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


3. Summary

chkpt 1.1, P1:
chkpt 1.2, P1:
not applicable or possibly satisfied
chkpt 1.3, P1:
chkpt 1.4, P1:
chkpt 1.5,P2:
not applicable or satisfed
chkpt 2.1, P2:
chkpt 2.2, P1:
chkpt 3.1, P1:
chkpt 3.2, relative:
unable to assess
chkpt 3.3, P1:
not applicable
chkpt 3.4, P3:
chkpt 4.1, P1:
chkpt 4.2, P1:
chkpt 4.3, P3:
chkpt 5.1, P1:
chkpt 5.2, P2:
chkpt 5.3, P2:
chkpt 5.4, relative:
chkpt 6.1, P1:
chkpt 6.2, P1:
chkpt 7.1, P3:
haven't checked
chkpt 7.2, P1:
haven't checked
chkpt 7.3, P2:
chkpt 7.4, P1:
chkpt 7.5, P2:
unable to assess
chkpt 7.6, P2:

Compliance level: none

4. General notes

NOTE: It would be handy to have a list of techniques indexed by the tool category. For example all the techniques for the markup editing tools, all the techniques for multimedia tools, etc.

NOTE: there is too little integration, at the moment, between the "at minimum" requirements in the guidelines and the "required" techniques. They are not the same thing (as the required techniques may refer to different types of tools, or different ways in which the "at minimum" clause can be satisfied). However one should be able, by reading the techniques document, to determine if the checkpoint is satisfied or not. May be adding examples of failure to satisfy the checkpoint would suffice.