Conformance of HomeSite 4.0.1 to the Last Call Draft of
Authoring Tool Accessibility Guidelines
DATE COMPLETED: 3 October 1999
LAST REVISED: 7 October 1999
EVALUATOR: Gregory J. Rosmaita <firstname.lastname@example.org>
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 220.127.116.110
- 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
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
Abbreviations & Conventions
- 1) GL
- 2) CP
- 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
GL1: Support accessible authoring practices
- 1.1 Ensure Author can implement accessible Authoring practices
- 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.
- the HTML 4.0 Transitional DTD
- 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:
- 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:
- HTML (Hypertext Markup Language)
- HTML 2.0
- HTML 3.2
- HTML 4.0
- HTML (MSIE)
- HTML (Netscape)
(Cold Fusion Markup Language)
- HDML 2.0 (HandHeld Device Markup Language)
- "A collection HandHeld Device Markup Language (HDML
2.0) tags used for wireless web applications"
- SMIL (Synchronized Multimedia Integration Language)
(Virtual Tag Markup Language)
(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
- 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
- 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
- A) Since HomeSite can function as a source editor. It provides context sensitive help (element by
- 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:
Each "Quick Bar" contains a customizable iconic toolbar. By default, the
toolbar for "Fonts" contains buttons for the following elements:
- CFML (Cold Fusion Markup Language)
If one chooses to increase the font size using the "FONT size plus" button,
the following markup is added:
- FONT size plus
- FONT size minus
<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
In addition, one can add tags to the Validation set for:
- 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
- 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
- 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
- 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
- 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
- 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
- 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:
- 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.
- 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
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.
- 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"
- 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.
- 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"
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
- This is the only checkpoint which HomeSite does not even remotely
- "welcome" dialog box did not self-voice (needed to
use screen review to hear contents spoken.
- 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.
- 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
- Field labels not voiced when field receives point of regard.
- Field labels not voiced when using JFW's "speak control
- Needed to use JAWS cursor to review full context of window.
- Tag Editor - Span
- "Style Sheets / Accessibility (HTML 4.0)" property
sheet group label not voiced.
- 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.
- None of the field labels in this property sheet voiced. Needed
to use screen review to ascertain labels for edit areas.
- when used the CONTROL+TAB to switch property sheets, title
of new sheet "Events (HTML 4.0)" not voiced.
- checkbox labels voice when tabbed-to and respond to
JFW's "speak control label" command.
- 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
- Only the window title "Tag Editor - STYLE" and default
control with focus ("Apply") voiced when window spawned.
- JFW recognized label for "Style Editor" button; rest of
property sheet had to be explored using the JFW speech cursor.
- Tag Editor - DL
- 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
- Only window title an control with focus voiced when property
- like that "Add End Tag" is checked by default!
- Anchor Property Sheet
- 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
- 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
- "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
- 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
- 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.
- 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
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
- 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
- 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.
- With point of regard in the Help Reference Tree window:
- 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.
- when a Help "book" is opened, it opens in a new child window, which
is only focusable using JFW's mouse emulation cursor
- 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.
- 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
- 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
- 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:
- Font family
- font size
- Tab width
- foreground color
- background color
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
- Allaire Cold Fusion Tags
- Default Text
- HTML Anchor Tags
- HTML Attributes
- HTML Image Tags
- HTML Special Characters (character entity sets)
- HTML Style Tags
- HTML Table Tags
- HTML Tags
- Microsoft ASP Tags
- Punctuation (such as braces)
- Script Tags
- StyleSheet Properties
- StyleSheet Selectors
- StyleSheet Values
- 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
- 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
- dtd2 (inserts DTD for HTML 2.0)
- dtd3 (inserts DTD for HTML 3.2)
- dtd4 (inserts DTD for HTML 4.0)
- linkrels (inserts <LINKREL="StyleSheet">)
- metad (inserts <META NAME="description" CONTENT="">)
- metaeng (inserts META tag declaring English as natural language)
- metagen (inserts META tag identifying the Authoring Tool)
- metakey (inserts <META NAME="keywords" CONTENT="">)
- All three "Code Template" fields
- Keyword (abbreviation)
- Value (uses the pipe character to symbolize the system caret
position after insertion
- 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
- HomeSite allows direct editing of the structure of the document via the
- 7.7 Allow the author to search within editing views [Priority
- 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:
- Current Document
- All Open Documents
- In a user-designated Folder
- by file type (optional; supports multiple file-type searching)
- include sub-folders (optional)
- 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
- 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