HoTMetaL 5.0 (win98) AU Review

25 September 1999
Wendy Chisholm


HoTMetaL 5.0 does not comply to the AU Guidelines. For example, it fails for Priority 1 checkpoints 3.1 and 3.2. However, it is close and does many good things for accessibility.

Guideline 1. Support accessible authoring practices


1.1 Ensure the author can implement accessible authoring practices for the markup language(s) supported by the tool. [Priority 1]
Can do.
1.2 Produce content that conforms to the W3C's Web Content Accessibility Guidelines [WAI-WEBCONTENT]. [Priority 1 for level-A conformance, Priority 2 for double-A conformance, Priority 3 for triple-A conformance]
Yes, it is cabable of producing conforming content. Most of it depends on the author. When inserting images and applets, the "alt" attribute is listed with other element attributes. If strict prompting is on, it will ask for a description and insert a d-link. However, no helper tools to provide noframes, noscript, or table properties (e.g.). If provide the info in the source view, won't complain.
1.3 Ensure that templates provided by the tool conform to W3C Web Content Accessibility Guidelines [WAI-WEBCONTENT]. [Priority 1 for level-A conformance, Priority 2 for double-A conformance, Priority 3 for triple-A conformance]
Templates are not horrible but tend to use deprecated elements and some structural for presentation.
1.4 Preserve all accessibility information during authoring, transformations and conversions. [Priority 1]
I have not had a problem with this. May need to be more thoroughly tested.

Guideline 2. Generate standard markup


2.1 Use applicable W3C Recommendations. [Priority 2]
For the most part, does use W3C, but also allows EMBED, BLINK, etc. There are also a number active elements that can be inserted into a page that I am not as familiar with (different types of scripting, ActiveX, Shockwave, etc.) [Unless using the W3C strict template.]
2.2 Ensure that markup is generated in accordance with a published specification [Priority 1]
The SoftQuad DTD seems to include most of the HTML4 stuff, but also other proprietary elements.
2.3 Ensure the tool produces markup in a language that enables accessibility [Priority 1]
It will produce a doc in HTML, but it may not be the most accessible use of HTML (it will most likely not be strict HTML4 unless using the W3C strict template).

Guideline 3. Ensure that no accessibility information is missing


3.1 Prompt the author to provide alternative information (e.g., captions, expanded versions of acronyms, long descriptions of graphics). (Priority 1 for alternative information that is [Web-Content-Priority-1], Priority 2 for alternative information that is [Web-Content-Priority-2], Priority 3 for alternative information that is [Web-Content-Priority-3])
It does not satisfy this for all HTML elements that should have alt info.
3.2 Do not insert automatically generated (e.g., the filename) or place-holder (e.g., "image") equivalent text, except in cases where human-authored text has been written for an object whose function is known with certainty. [Priority 1]
It uses defaults for "alt" on images, and NOFRAMES. May also do this for other elements or attributes.
3.3 Provide pre-written alternative information for all multimedia files packaged with the authoring tool. [Priority 2]
Doesn't include much media, other than some images (that i could find). I don't see alternative info for them.
3.4 Provide a mechanism to manage alternative information for multimedia objects, that retains and offers for editing pre-written or previously linked alternative information. [Priority 3]
?? don't think so.

Guideline 4. Provide methods of checking and correcting inaccessible content


4.1 Check for and alert the author to accessibility problems. (Priority 1 for accessibility problems that are [Web-Content-Priority-1], Priority 2 for accessibility problems that are [Web-Content-Priority-2], Priority 3 for accessibility problems that are [Web-Content-Priority-3])
You can run a check (or have it check as you go). The checks and messges seem to be using a much older version of Web guidelines (which makes sense since this was released in '98 and WCAG in '99).
4.2 Assist authors in correcting accessibility problems. (Priority 1 for accessibility problems that are [Web-Content-Priority-1], Priority 2 for accessibility problems that are [Web-Content-Priority-2], Priority 3 for accessibility problems that are [Web-Content-Priority-3])
No assistance is given. A report of errors is given in a dialog box. The author only has to click "ok" then the message goes away. There is not even a report as to which elements caused the errors. When strict checking is on, after clicking "ok" it presents a dialog box for each error. For example, if you use tables it will tell you to provide an alternative for each table. If you have more than one table on the page, it will give you this dialog box for each one. It means you click through the messages and ignore them.
4.3 Allow the author to override any removal of unrecognized markup. [Priority 2]
When it doesn't recognize something it will ask if it may "automatically" correct it. sometimes I say yes, usually I say "no" It may continue to give you a hassle each time you hit "save," but it never removes it unless you tell it to.
4.4 Provide the author with a summary of the document accessibility status. [Priority 3]
This is available through the accessibility checker. It will tell you how many errors you have on the page (if any). I haven't found a way to save this to a file for later review.
4.5 Allow the author to transform presentation markup that is misused to convey structure into structural markup, and to transform presentation markup that is stylistic into style sheet markup.. [Priority 3]
No guidance, but has a SS "tool" . up to author.

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


5.1 Make generation of accessible content a naturally integrated part of the authoring process. [Priority 1]
What they do support is natural. When insert an image, get a dialog box of attributes. "alt" is one of them. Also, you can keep the attribute inspector viewable at all times. If use strict access prompting, also get prompted to add a description.
5.2 Ensure that the highest-priority accessible authoring practices are among the most obvious and easily initiated by the author. [Priority 1]
They don't highlight all of the P1 WCAG practices, therefore I guess they don't do this.

Guideline 6. Promote accessibility in help and documentation


6.1 Integrate accessible authoring practices in all applicable help topics. [Priority 1]
Where they support this, they support it well. e.g. alt on IMG, description/d-link. However, on a quick skim of "tables for layout" I don't see mention of access issues.
6.2 Explain the accessible authoring practices supported by the authoring tool. [Priority 1]
"HoTMetaL PRO includes the following features to make accessible authoring easier and faster. Accessibility prompting dialog boxes Descriptive text editor Accessibility validation Pop-up warnings This information Copyright © 1997, 1998 SoftQuad Inc." I could only find this info through the index, not in the main table of contents. The section of accessibilty validation has more info about setting up the prompts.
6.3 Ensure that all documentation examples show how to produce content that conforms to W3C Web Content Accessibility Guidelines [WAI-WEBCONTENT]. [Priority 1 for level-A conformance, Priority 2 for double-A conformance, Priority 3 for triple-A conformance]
Examples do not all conform (mostly thinking of templates, and discussions of particular uses of elements - like tables for layout).
6.4 Emphasize the universal benefit of accessible design. [Priority 3]
It is mentioned a few times. I would not say it is "emphasized."

Guideline 7. Ensure that the Authoring Tool is Accessible to Authors with Disabilities


7.1 Use all applicable operating system and accessibility standards and conventions (Priority 1 for standards and conventions which are essential to accessibility, Priority 2 for those that are important to accessibility, Priority 3 for those that are beneficial to accessibility). [Priority 1]
From what I can tell, they seem to do.
7.2 Allow the author to change the editing view without affecting the document markup. [Priority 1]
Can switch between HTML source, "tagged" view, and WYSIWYG w/out affecting document markup.
7.3 Render an accessible equivalent of each element property. [Priority 1]
I don't think so. In regards to images, you can choose to load the image or not, but it won't load the alt-text if you don't load the image.
7.4 Allow the author to edit all properties of each element and object in an accessible fashion. [Priority 1]
You can press shift-F6 to get to the attribute inspector. Once in that window you can tab between attributes that are available for the element that has focus in the editing view, or you can arrow through the elements in the hierarchy. Pressing Escape returns you to where you were editing when you pressed shift-F6.
7.5 Ensure the editing view allows navigation via the structure of the document. [Priority 1]
I can navigate by word, but not by element. It doesn't prevent going through the structure, but does not provide a structured way to navigate through it (that I can tell). Although, if I want to highlight an element, in the tag view I can go to the out side of the element, press control-arrow and get the rest of it higlighted easily.
7.6 Enable editing of the structure of the document. [Priority 2]
7.7 Allow the author to search within editing views. [Priority 2]