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

VERSION: 1.01
DATE COMPLETED: 3 October 1999
LAST REVISED: 7 October 1999
EVALUATOR: Gregory J. Rosmaita <unagi69@concentric.net>
DRAFT EVALUATED: <http://www.w3.org/TR/1999/WAI-AUTOOLS-19990903>

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

PART ONE: INTRODUCTORY COMMENTS AND NOTES

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 <http://www.hj.com/>

2. Speech Synthesizer

Eloquence for JAWS (software synthesizer)

sound card: NeoMagic MagicWave 3DX Sound System

driver: NMA255.VXD version 4.0.13.2420

3. Operating System

Windows95 (version 4.01.0.971.B)

4. Computer

Gateway Solo 2500 Laptop (using Micron Windows95 keyboard)

RAM: 96MB

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

<http://www.w3.org/TR/1999/WAI-AUTOOLS-19990903>

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

Guideline

2) CP

Checkpoint

3) ACCESSKEYs

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

• 1: Support accessible authoring practices
• 2: Generate standard markup
• 3: Ensure that no accessibility information is missing
• 4: Provide methods of checking and correcting inaccessible content
• 5: Integrate accessibility solutions into the overall "look and feel"
• 6: Promote accessibility in help and documentation
• 7: Ensure that the Authoring Tool is Accessible to Authors with Disabilities

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 HTML 4.0 Transitional DTD
• <HTML>
• <HEAD>
• <TITLE>Untitled</TITLE>
• <BODY>
• </BODY>
• </HTML>

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.

• Next Guideline
• Email the evaluator
• Complete List of Guidelines
• Return to the beginning of this document

GL2: Generate Standard Markup

2.1 Use applicable W3C recommendations [Priority 2]

HomeSite supports the following W3C recommendation:

• HTML (versions 2.0, 3.2, and 4.0)
• SMIL 1.0

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.

• Next Guideline
• Previous Guideline
• Email the evaluator
• List of Guidelines
• Return to the beginning of this document

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

• Next Guideline
• Previous Guideline
• Email the evaluator
• Complete List of Guidelines
• Return to the beginning of this document

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:

• FONT
• FONT size plus
• FONT size minus
• BOLD
• ITALIC
• STRONG
• EM
• PRE
• H1
• H2
• H3
• SUB
• SUP

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:

• Report errors (on by default)
• Report warnings (on by default)
• Report messages (on by default)
• Report nesting errors (on by default)
• CFML Compiler Errors (only available if using Cold Fusion Studio)
• Other Options
  • Check for High ASCII characters
  • Check for Quotes in Text
  • Check for Line-Spanning Quotes
  • Ignore ASP <% ... %> delimited text
  • Ignore PHP <? ... ?> delimited text

In addition, one can add tags to the Validation set for:

• CFML (versions 1 through 4.0)
• HTML (versions 2.0, 3.2, and 4.0)

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.

• Next Guideline
• Previous Guideline
• Email the evaluator
• Complete List of Guidelines
• Return to the beginning of this document

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.

• Next Guideline
• Previous Guideline
• Email the evaluator
• Complete List of Guidelines
• Return to the beginning of this document

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:

• FRAMES
• FRAMESET
• NOFRAMES
  • While the NOFRAMES explanation available via the Context Sensitive Help system is accurate, this would be an ideal place to insert an explanation of the advantages of defining a NOFRAMES section, for both accessibility and interoperability's sake.
• ACCESSKEY
  • The context sensitive help for the A element details the expected action of an ACCESSKEY defined for a hyperlink, but does not address why one would want to define an ACCESSKEY for a link
  • The implementation example provided for ACCESSKEY in the context sensitive help for the A element is terrible. While the authors of the Help file are justified in pointing out that "the link text is not modified in any way to reflect that an ACCESSKEY has been defined for the link", their advice to the author is highly questionable, as it promotes the use of the type of exclusively visually-oriented markup that a visitor's UA may not be able to render/communicate. The suggested implementation for ACCESSKEY in a link--what the Help file refers to as "a sensible way around [the lack of a visual cue for the ACCESSKEY in a link]" is:
    
    <A HREF="url.htm" ACCESSKEY="W">W<SPAN STYLE="{text-decoration:none}">hat's New</SPAN></A>
    
    The Help file also states that the use of such visually-oriented markup is a means of "alerting the user that there's something special about the 'W' in the link"--an observation that overlooks the shortcomings of using exclusively visual cues to convey meaning.
  • On a more positive note, it is commendable that the Help file contains the following proviso: "Also note that ACCESSKEY settings override those of the main Internet Explorer menus." A more questionable assertion is that: "The ACCESSKEY attribute is Internet Explorer 4.0 and above specific." The wording seems to suggest that ACCESSKEY is proprietary markup, when the problem is a lack of broader UA support for ACCESSKEY.
  • in the context sensitive help for the LABEL element, the ACCESSKEY attribute is described as follows: "The ACCESSKEY attribute can be used to specify a shortcut key for the <LABEL> (activated by pressing 'Alt' and the ACCESSKEY together--like standard Windows applications menu shortcuts). The ACCESSKEY setting does not have to be a character in the actual label text and the label text is not modified in any way to reflect that an ACCESSKEY has been defined." Again, this is an example of describing the expected action of the attribute in a GUI environment, and does not address the use of ACCESSKEY for the purposes of enhancing the interoperability and accessibility of the FORM.
• IMG
  • Example: The section describing the ALT attribute is introduced by the following statement: "Optional text as an alternative to the graphic for rendering in non-graphical environments"
• FORM
  • The context sensitive help for the FORM element details the expected action of an ACCESSKEY defined for a FORM control, but it fails to address--either from an interoperability or accessibility standpoint--why one would want to define an ACCESSKEY for a FORM control.
• LABEL
  • The help file for the LABEL element states: "The <LABEL> element is used to link a text label to control like elements. Typically, these would be form elements--buttons, radio buttons, checkboxes etc. It provides for the kind of functionality built-in to most standard Windows based applications, whereby clicking the label next to a radio button is the same as clicking the radio button itself. Previously, in HTML, the radio button itself would have had to be clicked."
  • The explanation cited above is obviously insufficient, as it addresses only the expected action of a LABEL in the GUI environment. Another shortcoming of the help file for the LABEL element is the explanation of the FOR attribute: "The FOR attribute should directly reflect the ID attribute of the element which the <LABEL> is to be linked to. For example, in the above example, the two <LABEL> elements are linked to their respective radio buttons by their ID attributes. Note that the FOR attribute is theoretically unnecessary, if the <LABEL> element wraps the control it's a label for. Using the FOR attribute will ensure proper functionality though.

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"

• Next Guideline
• Previous Guideline
• Email the evaluator
• Complete List of Guidelines
• Return to the beginning of this document

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.

Installation

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

• Tag Editor property sheet/dialog box
  1. Field labels not voiced when field receives point of regard.
  2. Field labels not voiced when using JFW's "speak control label"(INSERT+TAB) command.
  3. Needed to use JAWS cursor to review full context of window.
• Tag Editor - Span
  1. "Style Sheets / Accessibility (HTML 4.0)" property sheet group label not voiced.
  2. Had to label "Style Editor" button (when routed JAWS cursor to what was voiced simply as "button" when tabbed-to. Needed sighted assistant to read ToolTip in order to use JFW's Graphics Labeler and to label the graphic.
  3. None of the field labels in this property sheet voiced. Needed to use screen review to ascertain labels for edit areas.
  4. when used the CONTROL+TAB to switch property sheets, title of new sheet "Events (HTML 4.0)" not voiced.
     1. checkbox labels voice when tabbed-to and respond to JFW's "speak control label" command.
  5. HTML4 event handlers property sheet inaccessible via the keyboard--only voice when the mouse emulation cursor is used to move from control label to control label
• Tag Editor - STYLE
  1. Only the window title "Tag Editor - STYLE" and default control with focus ("Apply") voiced when window spawned.
  2. JFW recognized label for "Style Editor" button; rest of property sheet had to be explored using the JFW speech cursor.
• Tag Editor - DL
  1. Only window title and control with focus (checkbox labeled "Compact") voiced when property sheet opened. Rest of property sheet had to be explored using the JFW speech cursor.
• Tag Editor - DT
  1. Only window title an control with focus voiced when property sheet spawned
  2. like that "Add End Tag" is checked by default!
• Anchor Property Sheet
  1. None of the edit areas labels voiced when receiving focus moving through the property sheet via the TAB key.. Did not respond to JFW's "speak control label" keystroke.
  2. Three custom control buttons following the "HREF" edit area: first button did not have either a label or ToolTip associated with it, but activating it caused the "Open" selection box to be spawned. Used JFW's graphic labeler to label the second and third buttons ("add from MSIE favorites" and "add from Netscape bookmarks", respectively) after using the left mouse click emulator to open them, but when I subsequently attempted to tab through the items, "select from Netscape bookmarks" was consistently ignored, and had to be invoked using JFW (speech) cursor (using CONTROL+ArrowKeys to move from active element to active element)
  3. "Edit Style" button not voiced as a graphic, but as a "custom control" when tabbed-to. When JFW cursor was routed to the application cursor (bringing the mouse pointer with it). the ToolTip was voiced. I then used JFW's "label graphic" command, to label the graphic.

Allaire Style Editor 4.0

• MAJOR PROBLEM: There is no way to activate the "Update and Return" button using the keyboard
• toolbar icon labels not voiced

"Tools" Menu

• Validate (Shift+F6) spawns child window that does not receive 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 screen review or mouse movement / emulation keystrokes to have the contents of the child window voiced.
• Custom control (graphical button) used as "close child window" hot-spot instead of platform control (traditional close button/box). Had great difficulty locating the custom control using screen review (gross navigation with the arrow keys, using the JAWS/speech cursor), and when I was able to get a ToolTip to be voiced ("Close Results"), any attempt to label the graphic yielded a 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.

Warning Messages

• none of the warning messages issued by HomeSite voiced automatically, save for the control with focus ("OK button") voiced. Had I not set a system sound for warning messages, I would not have even known that I had encountered a warning message. Had to use screen review command (INSERT+B) to hear contents of warning message.

Runtime Help

• Runtime Help is available via the Windows Help format
  1. Runtime Help must be invoked via a "Help Reference Tree" window, which uses the Windows Help format, and, yet, the actual Help files are in HTML format. There is an iconic button which enables the user to "Open In External Browser". When activated, the "Open in External Browser" button spawns the system's default browser and displays the selected Help file. Once I discovered this (thanks to sighted assistance, which I employed to label the buttons), I was able to browse the Help sub-directories directly, using any browser I pleased. The splitting of the main workarea occurs even when the workarea is running in HomeSite's "Full Screen" mode (what Windows applications usually refer to as "maximized"). I had expected the Help to be "maximized" as well, but I have not yet discovered a means of doing this, other than by physically activating the "Open in External Browser" button.
  2. While the images used for the "Back", "Up Level", and "Next" buttons which appear at the top and the bottom of each hypertextualized help file are ALT-texted, there are numerous graphics, such as the annotated screen shot that explains the layout of the main workspace areas (and which appears in the file
     \HomeSite\Help\Using_HomeSite\01_Setting_up_HomeSite\hssetup1.htm)
     are not ALT-texted, nor is there a textual equivalent for the information conveyed by that graphic. Moreover, in the example of the annotated screen shot, there is no textual equivalent for the information conveyed by the graphic. While a LONGDESC could theoretically be used, since LONGDESC isn't currently supported by GUI UAs, a textual link, leading to a textual description of the main workspace areas would be the optimal solution.
• Invoking Help via the menu bar (using the standard control ALT+H) causes the application window to split into 2 side-by-side "child windows"; point of regard / focus retained by the editing workarea
  1. CONTROL+TAB, the standard Windows9x navigational keystroke for switching between 2 independently scrolling child windows did not move the point of regard to the Help window, but instead cycled through the documents contained in the Edit window. When only one document is open in the Edit window and help is invoked, CONTROL+TAB does not move the point of regard into the Help Reference Tree window; instead, I had to use JFW's mouse emulation cursor to force the point of regard into the Help Reference Tree window.
  2. With point of regard in the Help Reference Tree window:
     1. when in screen-review mode, JFW doesn't perceive the barrier between the 2 windows (the Editing window and the Help Reference Tree window), and thus reads across the graphical boundary between the 2 windows, so that the title of the Help "book" is read, along with the parallel line which is displayed in the Editing workarea (or, the Help contents window, when Help is opened and displayed in the "Browse" window (which is overlaid the Editing window). When the editing window is closed, screen review of the Help contents (which is the only means by which I could review and activate the items in the Help window, the parallel line of the "Help topic" was read by JFW as I moved from Help topic to help topic.
     2. when a Help "book" is opened, it opens in a new child window, which is only focusable using JFW's mouse emulation cursor
     3. using JFW's speech cursor (which moves the cursor around the screen without also moving the system/application cursor) I fortuitously discovered that there is a button whose ToolTip reads "Browse Help in Separate Window" (Note: when the mouse emulation cursor is used to move from unlabeled graphic to unlabeled graphic, the ToolTips are not usually spoken by JFW, but I was lucky in this instance). JFW's "Graphics Labeler" reported the label for the button as "Graphic 443", indicating that it is not properly labeled.
     4. when the "Browse Help in Separate Window" button was inactivated, the edit view was suppressed, but CONTROL+TAB still did not move the point of regard to the explanation window

Context Sensitive Tag Help

• context sensitive help for HTML, CFML, and scripting elements is available via the standard Windows keybinding for Help, F1
• context sensitive help invoked via the F1 key is displayed in the Edit/Browse/Display workarea, but it is not possible to switch between the "Browse" tab and the "Edit" or "Display" tabs using the keyboard. (Note: the standard Win32 keybinding for this action is CONTROL+TAB) It was, therefore, necessary for me to use JFW's mouse emulation feature to move to the tab and select it, using the keystroke that emulates a left mouse click.

Frames Wizard

• The "Frames Wizard" is media and mouse dependent. The contents of the first application window were not automatically voiced by JFW, but had to be manually reviewed using the speech cursor. The instructions for the first Frame Wizard window tells it all:
  
  "Click on the frame cell to select it. Hold the shift key down when clicking on the frame to select the whole frameset containing the cell. Use the buttons on the right side to add or remove columns or rows in the selected areas. To resize the frame cell, click on the border line and drag it to the new location."

General Toolbar Comments & Observations

• HomeSite would greatly benefit from a "Toolbars as Text" option--even the sighted assistant who I recruited to help me label the graphics remarked "Good thing they have ToolTips, because otherwise, I wouldn't have had a clue as to what they are supposed to represent, either. They aren't at all intuitive."
• I'm not sure why, but even after some of the graphics were labeled using the JFW Graphics Labeler, the labels were not accurately voiced by JFW, although the JFW Graphics Labeler reported them as labeled.

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:

• Font family
• font size
• Tab width
• charset
• foreground color
• background color

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:

• Allaire Cold Fusion Tags
• Comments
• Default Text
• HTML Anchor Tags
• HTML Attributes
• HTML Image Tags
• HTML Special Characters (character entity sets)
• HTML Style Tags
• HTML Table Tags
• HTML Tags
• JavaScript Identifiers
• JavaScript Keywords
• JavaScript Methods
• JavaScript Numbers
• JavaScript Strings
• JavaScript Symbols
• Microsoft ASP Tags
• Numbers
• Punctuation (such as braces)
• Script Tags
• Strings
• StyleSheet Properties
• StyleSheet Selectors
• StyleSheet Values

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"

• Previous Checkpoint
• Email the evaluator
• Complete List of Guidelines
• Return to the beginning of this document

Conclusions

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