HoTMetaL 5.0 (win98) AU Review
25 September 1999
Wendy Chisholm
Summary
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.
Checkpoints:
- 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.
Checkpoints:
- 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).
Checkpoints:
- 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.
Checkpoints:
- 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.
Checkpoints:
- 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.
Checkpoints:
- 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."
Checkpoints:
- 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]
- Yes.
- 7.7 Allow the author to search within
editing views. [Priority 2]
- yes.