Conformance of HomeSite 4.0.1 to the Last Call Draft of the W3C's Authoring Tool Accessibility Guidelines

DATE COMPLETED: 3 October 1999
LAST REVISED: 7 October 1999
EVALUATOR: Gregory J. Rosmaita <>

Table of Contents
Part One: Introductory Comments & Notes
A) Materials Used to Compile Conformance Evaluation
B) Abbreviations & Conventions
Part Two: Conformance Evaluation of HomeSite 4.0.1


Materials Used to Compile This Conformance Evaluation

1. Assistive Technology Used in This Evaluation
screen reader: Jaws for Windows 9x/NT, version 3.3
manufacturer: Henter-Joyce <>
2. Speech Synthesizer
Eloquence for JAWS (software synthesizer)
sound card: NeoMagic MagicWave 3DX Sound System
driver: NMA255.VXD version
3. Operating System
Windows95 (version
4. Computer
Gateway Solo 2500 Laptop (using Micron Windows95 keyboard)
CPU: Pentium II 366MHz
5. Authoring Tool Evaluated
Allaire's HomeSite, version 4.0.1
6. Draft of Authoring Tool Guidelines Used in this Evaluation
3 September Last Call Draft

Note: This document was written using Allaire's HomeSite 4.0.1. This evaluation was performed by Gregory J. Rosmaita between 1 September and 1 October, a period in which I used HomeSite to encode several complex hypertext documents. It is provided as a sample of a conformance evaluation, but it is not intended to be a definitive statement of HomeSite's conformance to the Authoring Tool Guidelines, as there are features of the tool which I was unable to independently verify.

This is a work-in-progress. Future revisions will incorporate feedback provided by the general public, members of the Authoring Tool Guidelines Working Group, and the manufacturer of the tool evaluated. This document, therefore, should only be referenced as a work-in-progress.

Abbreviations & Conventions

1) GL
2) CP
3A) An ACCESSKEY has been defined for each Guideline. The ACCESSKEY for Guideline 1, is 1; the ACCESSKEY for Guideline 2 is 2; and so on, through Guideline 7, the ACCESSKEY key for which is 7.
3B) Additional ACCESSKEYS:
C (Table of Contents)
G (List of Guidelines)

Part Two: Conformance Evaluation of HomeSite 4.0.1

GL1: Support accessible authoring practices

1.1 Ensure Author can implement accessible Authoring practices [Priority 1]
Using the "Edit" mode to edit the document source, this is quite easy--provided, of course, that the author has an awareness and foreknowledge of the accessibility features and implications of the markup being inserted. The "Tag Insight" feature, which provides a drop-down menu from which to choose an attribute to add to an element as it is being manually entered (and which is active by default) contains the entire HTML 4.0 attribute set, so, theoretically, it is quite easy for anyone to create accessible content. The property sheets for each element--which one can invoke from the toolbar, via the application menu, or through the "Tag Chooser" (which is accessed via a right mouse click, or the keyboard equivalent thereof [either the "Applications" key on a Windows95 keyboard or via the SHIFT+F10 keystroke] executed in the "Edit" workarea--feature a tab named "Style Sheet/Accessibility". Unfortunately, neither the property sheet tab labels, nor the form control labels are voiced when using speech synthesis (please refer to the comments on GL7 for information). The "Style Sheet/Accessibility" tab in the property sheet for the AREA element, for example, includes fields that allows the author to define an ACCESSKEY, TABINDEX, and TITLE; while, on the main property sheet for the IMG element the "Alt Text" field is given prominent placement--it is the first field one encounters after the "Source" field. As of this writing, I have not yet attempted to use HomeSite's "Design" mode, which (according to the Help files) allows one to "dynamically work with page elements, such as text blocks, tables, forms, and images. Changes are reflected in the HTML code. If you don't plan to use the Design mode, you can turn it off on the Design tab of the Settings (F8) dialog."

1.2 Produce content that conforms to WCAG [Sliding Priority]
The content produced validates, but the author retains the ability to add or subtract from the content produced by the tool. Conformance to WCAG depends upon the markup language chosen by the author

1.3 Ensure templates conform to WCAG [Sliding Priority]
Default template is simplicity itself, consisting of the following elements: The author can also specify a file to use as the default template.

1.4 Preserve accessibility content during transformation etc. [Priority 1]
HomeSite doesn't remove markup. No transformations yet performed.

GL2: Generate Standard Markup

2.1 Use applicable W3C recommendations [Priority 2]
HomeSite supports the following W3C recommendation:
2.2: Ensure Markup conforms to published specification [Priority 1]
Markup Languages supported by HomeSite 4.0.1:
  1. HTML (Hypertext Markup Language)
    1. HTML 2.0
    2. HTML 3.2
    3. HTML 4.0
    4. HTML (MSIE)
    5. HTML (Netscape)
  2. CFML (Cold Fusion Markup Language)
  3. HDML 2.0 (HandHeld Device Markup Language)
    • "A collection HandHeld Device Markup Language (HDML 2.0) tags used for wireless web applications"
  4. SMIL (Synchronized Multimedia Integration Language)
  5. VTML (Virtual Tag Markup Language)
  6. WIZML (Wizard Markup Language)

HomeSite also allows the author use what it calls "Custom Tags", which are defined as "a variety of third-party Cold Fusion tags directed at specific web development needs."

2.3 Use a language that enables accessibility [Priority 1]
HomeSite supports HTML4 and SMIL. The vast majority of the accessibility features defined for both are supported, with (as far as I can tell) only a few odd exceptions, such as supporting ACCESSKEY for the OBJECT element, instead of the HTML4-defined attribute TABINDEX.

GL3: Ensure that no accessibility information is missing

3.1 Prompt for alternative information [sliding priority]
A) While the "Tag Editor" property sheet for the IMG element prominently features an "Alt Text" edit box (second in tab order from the "Source" field), it does not have a LONGDESC field.
B) The property sheet for the OBJECT element contains an "(Alternative) Content" tab, the sole contents of which is a TEXTAREA in which the author can type a textual description of the OBJECT; an "Style Sheet/Accessibility" tab, which includes fields in which to define an ACCESSKEY (parenthetically labeled as "Not in HTML 4.0" and a TITLE for the OBJECT. but does not provide a TABINDEX field (which is one of the attributes listed for OBJECT in the HTML4 Rec)
C) the property sheet for the FRAME element allows the user to define the following alternative attributes: NAME, TITLE,

3.2 Do not insert auto alt text [Priority 1]
I am not aware of a setting that allows the author to do this.

3.3 Provide pre-written alt for packaged clip-art [Priority 2]
HomeSite does not provide pre-written ALT-text for the clip art which is distributed with it.

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]
While an ALT-registry is not available, HomeSite 4.0.1 does offer full support for SMIL 1.0

GL4: Provide methods of checking and correcting inaccessible markup

4.1 Check for accessibility problems [Sliding Priority]
No. HomeSite only checks the validity of the markup against the DTD declared in the document source.

4.2 Assist authors in correcting accessibility problems. [Sliding Priority]
A) Since HomeSite can function as a source editor. It provides context sensitive help (element by element)

B) One can either configure HomeSite so that the "Edit" workarea contains property sheet-type tabs, called "Quick Bars". (Note: if the Standard ToolBar is displayed, one can toggle, via an iconic button, "Quick Bars" on and off.) There are 9 "Quick Bars" available:
  1. Common
  2. Fonts
  3. Tables
  4. Frames
  5. Lists
  6. Forms
  7. Scripts
  8. CFML (Cold Fusion Markup Language)
  9. ASP
Each "Quick Bar" contains a customizable iconic toolbar. By default, the toolbar for "Fonts" contains buttons for the following elements: If one chooses to increase the font size using the "FONT size plus" button, the following markup is added:
<FONT size="+1"> ... </FONT>
If one validates the page, however, using HomeSite's integrated validator (invoked either via the "Tools" menu or the SHIFT+F6 keystroke), the validator returns a the following message:
In HTML 4.0, FONT is deprecated. It may become obsolete in future versions; consider using a style sheet instead;
(Evaluator's note: HomeSite's built-in validator displays four types of messages: messages, warnings, nesting errors, and errors. It is capable of validating HTML, CFML, and SMIL. Only the HTML validation results were tested in this conformance evaluation.)

C) Since validation is the first step towards ensuring accessibility, and since the built-in validator is the only such error-detection mechanism (other than a built-in spell checking utility) available via HomeSite 4.0.1, I have decided to address the major shortcomings of the validation interface in this section, rather than in my comments on Guideline 7. When the "Validate Current Document" command is invoked, HomeSite spawns child window that does not receive the point of regard / focus, which would have (optimally) allowed JFW to automatically voice the child window's contents, or (at the very least) allow me to route the JAWS (speech) cursor to the application cursor and use JFW's screen review or mouse movement / emulation keystrokes to have the contents of the child window voiced. Additionally, a custom control (i.e. a non-standard graphical/iconic button) is used as the "close child window" hot-spot, instead of the standard windows control (by which I mean the traditional close button). I experienced great difficulty locating the custom control using screen review (which provides gross navigational capabilities, using the arrow keys to move the JAWS/speech cursor). When I was able to get a ToolTip voiced ("Close Results"), any attempt to label the graphic using JFW's Graphics Labeler, yielded the following JFW error message: "Graphics Labeler Not Positioned on a Graphic". Despite this, the child window cleared when I used JFW's left-mouse click command. (Note: JFW does not invariably speak ToolTips, but, rather, will assign an unlabeled graphic a number [i.e. "Graphic 69"] which will be spoken when the unlabeled graphic received the point-of-regard from the mouse emulation cursor, if "Graphics Verbosity" is set to "Say All Graphics". Occasionally--depending, I believe, on how quickly the ToolTip is displayed--the ToolTip may also be voiced. Thus, the slower the system is in generating the ToolTip, the better the chances are that it may be voiced.) Needless to say, the user interface issues outlined above are quite frustrating, especially since one of the features of the "Validation Results" child window is that, by activating an error message, the point-of-regard / focus is shifted back to the editing workarea, and the cursor / system caret is placed on the line where the error occurs--and, in most instances, at the start of the invalid code.

E) HomeSite's built-in validator is configurable. The following options are configurable: In addition, one can add tags to the Validation set for:

4.3 Allow the author to override removal of unrecognized markup [Priority 2]
Since I have encountered an instance when HomeSite threatened to remove unrecognized markup, my preliminary conclusion is that HomeSite does not automatically remove unrecognized markup. And, while it is also possible to manually enter unrecognized markup. When one does so, however, a warning is generated. For example, when I inserted the fake element <FOO>, I heard the system sound that I defined for an error, but no error message was voiced. I attempted to route the speech cursor to the application cursor, but that only resulted in JFW reading the line which I was currently editing, and upon which I had typed the non-existent element. I used JFW's "read Status Line" command, and (along with the other information contained on the Status Line), I heard the following: "The tag name FOO is not found in currently active versions", but I was not prevented from using the unknown tag. When I validated the page on which I had defined the non-existent element, it showed up as an invalid element, with the same error message as that which had been displayed on the Status Line during editing: "The tag name FOO is not found in currently active versions."

NOTE: The error message was displayed on the status line only when the "Edit WorkArea" was not maximized. When working in a maximized ("Full Screen") WorkArea, the system sound for an error was generated, but since the "full screen" workarea does not have a status line, there was no error message displayed. (Evaluator's note: When using HomeSite I used the "Edit" workarea mainly in "Full Screen" mode because I wanted to have as much of the document source displayed on the screen as possible, since scrolling right and left is not a viable (or desirable) option when one is using speech synthesis.) For the purposes of this evaluation, I constantly toggled between the "Normal" and "Full Screen" views. It is also worth noting that, when operating in full screen mode, if "Show Gutter" is engaged, the window border was voiced by JFW as "Graphic 706". I silenced the enunciation of the graphic-as-border by using JFW's Graphics Labeler to label it with a null value. (The gutter and line number feature is quite useful.)

4.4 Provide the author with a summary of accessibility status [Priority 3]
No such feature available via HomeSite.

4.5 Allow the author to transform presentation markup or misused markup [Priority 3]
While HomeSite allows some transformations via the "Code Sweeper" utility I have yet to fully test Code Sweeper's transformational powers, mainly because Code Sweeper changes can't be undone by HomeSite.

GL5: Integrate accessibility solutions into the overall "look and feel"

5.1 Make generation of accessible content natural [Priority 1]
A) As a source editor with "Tag Insight" and "Tag Completion" feature, HomeSite makes the generation of accessible content quite easy. However, since the addition of accessible content is left to the author, a more rigorous validation rule set would be a definite boon. For example, there is nothing that precludes an author from defining an IMG without the required ALT attribute, despite the fact that the "Tag Chooser", a feature which (when evoked via the menu bar, a physical right mouse click, or the keyboard equivalent thereof) displays the text-entry field for ALT Text quite prominently, HomeSite's internal validator does not recognize this as invalid markup.

5.2 Ensure highest-priority accessible practices are most obvious and easily initiated. [Priority 1]
Overall, yes, although this could be improved by removing the iconic toolbar buttons from the "Quick Bars" for deprecated elements.

GL6: Promote accessibility in help and documentation

6.1 Integrate accessible authoring practices in all applicable help topics [Priority 1]
While context sensitive tag help is a very useful feature, in general, it fails to explicitly address the accessibility aspects of those HTML attributes and elements which are either known to promote accessibility, or which were added to HTML4 explicitly to enhance the accessibility of web content.

6.2 Explain the accessible authoring practices supported by the authoring tool [Priority 1]
No. While it explains HTML 4.0 it consistently fails to address accessibility. Even when those attributes and elements which are known to promote accessibility are described, the descriptions fail to even so much as mention accessibility and/or the disabled. There is no help topic/book dedicated to accessibility, A search of the online help for the terms "disability", "accessibility", "interoperable" all yielded the "No matches found" message.

6.3 Ensure documentation examples show how to produce accessible content [Sliding Scale]
No. While some of the examples contains markup known to promote accessibility, most do not. Significant failures include the context sensitive help available for:

6.4 Emphasize the benefit of universal design [Priority 3]
Contrary to what I expected--especially after reading Robert Crooks' article, entitled "Street Level: Editors vs. Authoring Tools" on the Allaire web site--the answer is a resounding "no"

GL7: 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]
This is the only checkpoint which HomeSite does not even remotely satisfy.

  1. "welcome" dialog box did not self-voice (needed to use screen review to hear contents spoken.
  2. edit areas, radio buttons, and checkboxes voiced well, but were the only things that were spoken when a new dialog box was generated. In order to listen to whatever other text might be contained in the dialog box, however, it was necessary to use screen review.
  3. SUMMARY: Overall, better than I had feared after encountering the "Welcome" dialog box, but could easily be improved.

Creating a New Document
Allaire Style Editor 4.0

"Tools" Menu
Warning Messages
Runtime Help
Context Sensitive Tag Help

Frames Wizard
General Toolbar Comments & Observations
7.2 Allow the author to change the editing view without affecting the document markup [Priority 1]
The editing view can be changed without affecting the document's markup. A very nice feature of HomeSite in this regard is that, unlike most GUI applications, the color palette is not only iconically/graphically demarcated, but is also textually demarcated. The author can change the following screen attributes for the editing view: In addition, the author can edit HomeSite's color coding scheme--a mechanism which controls the display of the various components of a document as a means of providing visual cues. The components which can be color coded include: According to the reports of sighted colleagues, when using the "Edit" workspace, HomeSite recognizes page components and changes the color scheme accordingly, providing a visual means of cueing the author not only to the page's components, but quickly alerting the sighted author when he or she has failed to correctly close containing tags, forgotten punctuation, etc. The main failing of the color scheme feature is that the color palettes offered for foreground and background colors do not contain textual equivalents of the colors displayed.

Although I have yet to used it to create or manipulate a hypertext document, HomeSite 4.0.1 does offer a WYSIWYG editing environment, which it calls "Design Mode". One of the chief reasons why I have not yet attempted to use the WYSIWYG feature is that, before entering "Design Mode", you are warned:
Design mode is for prototyping HTML pages. If you open a page in Design mode, your HTML may be reformatted or lost. You can use the CodeSweeper (found in the Options menu) to help preserve your HTML. Design mode can be disabled on the Design tab of the Settings dialog.

Please save your work before using Design mode. Do you want to proceeed [sic]?
7.3 Render an accessible equivalent of each property [Priority 1]
All available through standard text interface, or through mouse interface

7.4 Allow the author to edit all properties of each element and object in an accessible fashion [Priority 1]
This is one GL7 checkpoint at which HomeSite excels. One particularly nice feature is the ability to use "Code Templates" which enables the author to insert frequently inserted text blocks using an abbreviation. For example, when this feature is engaged (it is by default), typing the abbreviation dtd4 in the "Edit" workarea would cause HomeSite to insert the following text string:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
While HomeSite comes with nine pre-defined abbreviations (each with an associated value), the author can add, edit, and remove abbreviations from the "Code Templates" list by invoking the "Settings" property sheets (directly accessible using the F8 key, or via the "Options" menu). The list of pre-defined "Code Templates" includes:
  1. dtd2 (inserts DTD for HTML 2.0)
  2. dtd3 (inserts DTD for HTML 3.2)
  3. dtd4 (inserts DTD for HTML 4.0)
  4. linkrels (inserts <LINKREL="StyleSheet">)
  5. metad (inserts <META NAME="description" CONTENT="">)
  6. metaeng (inserts META tag declaring English as natural language)
  7. metagen (inserts META tag identifying the Authoring Tool)
  8. metakey (inserts <META NAME="keywords" CONTENT="">)
  9. scriptj (inserts empty JavaScript block)

All three "Code Template" fields
  1. Keyword (abbreviation)
  2. Description
  3. Value (uses the pipe character to symbolize the system caret position after insertion
are editable.

Unfortunately, the "Settings" property sheets suffer from the same labeling problems detailed in the comments on CP 7.1

7.5 Ensure the editing view allows navigation via the structure of the document [Priority 1]
HomeSite allows navigation from element to element.

7.6 Enable editing of the structure of the document [Priority 2]
HomeSite allows direct editing of the structure of the document via the "Edit" workarea.

7.7 Allow the author to search within editing views [Priority 3]
Yes. Searches can be easily initiated using the standard Windows9x command CONTROL+F. Can search forwards or backwards through a document. Supports the ability to repeat the previous search through the standard Windows95 keystroke (F3) for "Find Next Instance". Searching can be case sensitive or case-insensitive, can be conducted using text-strings, whole words, and "regular expressions". Tags can be excluded from searches. Allows search and replace, as well as an "extended search" feature, which enables the author to search for a string in:
  1. Current Document
  2. All Open Documents
  3. In a user-designated Folder
    1. by file type (optional; supports multiple file-type searching)
    2. include sub-folders (optional)
  4. In "Project"


A preliminary conclusion is that HomeSite 4.0.1 is close to double-A conformance in most areas, and close to triple-A in a few. However, due to the serious problems outlined in my comments on Checkpoint 7.1 HomeSite 4.0.1 does not conform to the Last Call draft of the Authoring Tool Guidelines.

Terminal Index
1) List of Existing Authoring Tools
2) Authoring Tools Working Group Home Page
3) Authoring Tools Mailing List (Public Archive)
4) Web Accessibility Initiative Home Page
5) World Wide Web Consortium (W3C) Home