This document includes techniques that are intended to assist users of the Tribeworks iShell authoring tool to create content that meets the requirements of the W3C Web Content Accessibility Guidelines (WCAG 2.0) [11 March 2004 Public Draft].
This document should be treated as a draft because the version of WCAG 2.0 that it references is a public working draft. Also, the techniques described in this document should not be considered to constitute an exhaustive list.
Duff McCourt - Resource Centre
for Academic Technology
Jan Richards - Resource Centre for Academic
Technology
Simon Clark - Digital Frog International
iShell, by Tribeworks, is a multimedia authoring and development tool available for both the Windows and MacOS platforms. It may be used to implement a wide range of applications, including virtual reality tours, interactive kiosks, custom MP3 players and video games. iShell applications are stand-alone exectuables that can be distributed on physical media or via the Internet. The techniques in this document, when used in conjunction with the ZebraSpeak iShell Accessibility Plug-in, should enable iShell developers to increase the accessibility of their applications for users with disabilities.
The current document is provided solely as an informative supplement to iShell developers who are already following the Web Content Accessibility Guidelines (WCAG 2.0) [11 March 2004 Public Draft] in their work. Developers should continue to pay close attention to the WCAG 2.0 Succss Criteria statements, as the current document does not attempt to provide a substitute for WCAG 2.0 or even a complete guide to satisfying the requirements of WCAG 2.0 for all iShell applications. Final conformance to a future WCAG 2.0 W3C Recommendation will be determined by the degree to which these success criteria are met..
In addition to a working knowledge of the Web Content Accessibility Guidelines (WCAG 2.0) [11 March 2004 Public Draft], the current document also assumes a working knowledge of the iShell authoring tool, the HTML Techniques for WCAG 2.0 [9 December 2003], as well as the ZebraSpeak iShell Accessibility Plug-in.
References to W3C guideline and techniques documents are made throughout the current document. These documents are created by the W3C and are referenced here in good faith.
There are several ways to provide text equivalents for non-text content in iShell.
Technique 1:
Use HTML to include images within an iShell document. Make sure to use the alt
element in the img tag for text equivalent. The longdesc
attribute may also be used when images require extra description (e.g. maps,
charts, etc.). For more information, see the HTML
Techniques for checkpoint 1.1.
Technique 2: Apply a 'Mouse Idle' event to each images in an iShell document. The events can trigger the display of text alternates. A 'mouse leave' event on the image can be set to clear the display. The disadvantage of this method is that other uses of 'Mouse Idle' or 'Mouse Leave' will be precluded.
Technique 3 (Figure 1): Using the ZebraSpeak iShell Accessibility Plug-in, ensure that every image is included in the 'Tab Handler' list (for more information on setting up a Tab Handler, see Techniques for Checkpoint 2.1). Once the 'Tab Handler' list is properly set up, a single keyboard event is used to capture any presses of the "d" key ("d" has been chosen for English language applications, to stand for "description"). These key presses then launch either a spoken description of the content or a text dialog as described in Method 2, or both. Using the 'Speak' command from the ZebraSpeak iShell Accessibility Plug-in will, when directed towards an image object, use its built-in text-to-speech capability to automatically speak the contents of any available text file which has the same name as the image, but with the '.txt' extension (i.e. the text description for 'picture.png' will be stored in 'picture.txt' in the same directory). These text files must be manually created.
Figure 1: This screenshot shows the code authoring inteface of iShell. The interface is not a text editor. Instead a series of horizontal bars encodes for objects and behaviours with embedded form fields for defining object attributes. In the example, three images in a project are set to be referenced by a Tab Handler. The Speak behaviour (controlling text-to-speech) is defined to output the Current Focus.
For more information see checkpoint 1.1 in WCAG 2.0.
Neither the base iShell authoring tool nor the ZebraSpeak iShell Accessibility Plug-in currently support SMIL, which is the ideal method for implementing captions and other synchronized media. This may change in future versions. In the meantime, there are various alternate methods.
Technique 1: Movies can be captioned or described externally in the original media (e.g. Quicktime, Real, etc.).
Technique 2 (Figure 2): For each Movie object on the screen, create a 'Caption' text field. Within the movie, set various 'Time' events, one for each caption. In each 'Time' event, create a 'Tell' command which changes the contents of the caption field to the desired caption. If there is a long time interval between captions, a 'Time' event with an empty 'Tell' command should be used to clear the caption field. This method can also be used for synchronized speech or sound by using a 'Time' event with either a 'Speak' command (using the ZebraSpeak iShell Accessibility Plug-in) or a 'Sound' command. The disadvantage of this method is that the same iShell Movie object is often used by developers to play different video clips, but the captions are specific to a given video clip. So, if this method is used, only one video clip can be used per 'Movie' object. One way to work around this problem is to create an iShell project file containing the video and captions for each clip. When movie switching is desired, switch the iShell projects rather than the movie clips alone.
Figure 2: This screenshot of the object-oriented iShell authoring interface shows an example of a movie and a caption field. There are three time events in the movie each of which places a new caption in the Text field named "Caption."
For more information see checkpoint 1.2 in WCAG 2.0.
Currently there is no way to extract all the textual/informational content from an iShell document in a way which preserves structure. Any information which is stored in a plain-text file and then used via a Text field is easily accessible, although its relationship to other elements in the document cannot be programmatically determined. Future versions of iShell may support exporting or extracting of text content. Alternately, future versions of the ZebraSpeak iShell Accessibility Plug-in may support direct piping of spoken content to a socket or interface in plain-text.
Technique: In the meantime, the best practise is to put as much textual content as possible into text files, rather than iShell internal labels, as the latter are much harder to extract.
For more information see checkpoint 1.3 in WCAG 2.0.
Technique: When including both foreground and background elements in an iShell document (i.e. when one element is appearing in front of another) ensure that the foreground information is clearly differentiable from and perceivable despite the background information. One way to test this is to see whether the foreground content is still perceivable when 256 shade grayscale is used. When using a background image, which includes a wide range of color values, ensure that the alpha channel is set to at least 40%. This will cause the background image to become increasingly transparent and thus blend into the document background color and be less obtrusive or distracting. Also, there should be a prominent "disable background images" button in any document where the possibility of interference between background image and foreground content exists.
For more information see checkpoint 1.4 in WCAG 2.0.
Technique: When including audio information, ensure that foreground sounds are at least 20db(roughly 4 times) louder than background sounds.
For more information see checkpoint 1.5 in WCAG 2.0.
Technique 1 (Figure 3): By default, iShell applications are primarily mouse-driven. Using the ZebraSpeak iShell Accessibility Plug-in to create a 'Tab Handler' object in the root document will allow for basic keyboard navigation. The 'Tab Handler' object captures any depresses of the "tab" key. In order for the Tab handler to properly navigate the document, a 'Loaded' event must be added to the 'Tab Handler'. One 'Tab' command for each tabbable item in the document must then by added to the 'Loaded' event. 'Each Tab' command takes an 'Object' parameter, which must refer to another object in the document. The order in which the 'Tab' commands appear in the 'Tab Handler' list will dictate the order of tabbing through the page. In order to meet this checkpoint, every element which supports mouse interaction must appear on the 'Tab Handler' list. Note that, if AYAG Checkpoint 1.1 is being satisfied using Method 3, all images must also appear on the 'Tab Handler' list.
Figure 3: This screenshot of the object-oriented iShell authoring interface shows an example of how the Tab Handler looks as well as three instances in which the Tab command is called, each associated with an Image object in the project. The Tab handler includes information on the state, position, size, duration, kind, highlighting, mouse actions, and speech actions.
The 'Tab Handler', by default, duplicates the Mouse Enter event upon first tabbing to an object and the 'Mouse Up' event when "enter" is pressed. If more complicated mouse events are used in a project, other methods may have to be employed to provide keyboard equivalents.
Technique 2 (Figure 4): One possible method is to redefine the mouse events duplicated tab events. These parameters are defined in the properties dialog for the 'Tab Handler' object.
Figure 4: This screenshot of the object-oriented iShell authoring interface shows an example of a Tab Event being used to change the Tab Enter behavior of a single Image object to toggle visibility of the image. This would have no effect on or relation to any Mouse Enter event which may also be defined for the object.
Technique 3: Another method for providing more sophisticated keyboard interaction is to add 'Tab' events into the specific object which requires alternate interaction. By changing the parameters of the 'Tab' event, it is possible to redefine the way tabbing is handled for a single object, while leaving the rest unchanged.
Technique 4: More sophisticated keyboard interaction can also be achieved by adding further 'Keyboard' events to the 'Tab Handler' and defining behavior for other specific keypresses (as was done for "d" in the Figure 1).
For more information see checkpoint 2.1 in WCAG 2.0.
For every element in an iShell document that uses the 'duration' attribute as a timer, there must be some easily perceivable indication of the fact that a timer is running and a simple way (preferably a "stop timer" or "I need more time" button) to stop the timer or lengthen the duration. If multiple timers are running at once and elements will move or appear and disappear dependent upon timers or time-dependent user responses, there must be a "pause" or "stop all timers" button. In extreme cases, a "step forward" button may also be necessary, which will increment all timers by some small amount with each click.
Technique: The exception to these requirements are cases where the content is streaming from a live source or when the interaction is inherently time-dependent because of the actions of external parties, such as a multi-player game or online auction.
For more information see checkpoint 2.2 in WCAG 2.0.
Technique: Do not cause screen flicker in the range of 3 to 49 Hz. In other words, do not have the screen dramatically change color or brightness at a rate equal to or higher than three times per second.
For more information see checkpoint 2.3 in WCAG 2.0.
Technique 1: Ensure that the different structural elements, such as different levels of headers, appear different from one another on the screen and are differiented when read by the text-to-speech system. For example, different levels of sub-titles should be identified.
Technique 2: The visual (and audio) structural layout of a document should not change as a user navigates. It is important that both the position and appearance of navigational and structural elements remain consistent within documents.
Technique 3: Include navigation for bypassing large blocks of repeated content, such as navigation bars.
Technique 4: When a document grows to great length (in excess of 50,000 words or 50 perceived pages) include some mechanism for navigating the content. For example, if a document contains a scrolling text field which holds 50 pages of text, the author should delineate it into pages and/or chapters and provide a linking mechanism (e.g. a button) which will allow the user to jump directly to the beginning of the next chapter without scrolling.
It is important to ensure that the structural and navigational elements of the document can be easily distinguished from the content elements. The transition from structure to content can be identified with various types of cues, including color, position and visual style (font, text size, etc.). When creating buttons or links in an iShell document, be sure to use already existing metaphors to distinguish content from structure. For example, use buttons with the raised "3-D" appearance and use color and underlining to identify text links. Furthermore, it is important not to use these metaphors for reasons of presentation. Do not use in-line underlining and color change for purposes of emphasis, for example, as this will confuse users into believing that these elements are hyperlinks.
For more information see checkpoint 2.4 in WCAG 2.0.
Technique 1: In any situation where user input is required and unacceptable or unexpected input is given, an iShell document must generate an error message rather than failing silently. The error report should be informative, but unobtrusive. In situations where a large amount of user input is required (such as extensive text input) a more comprehensive form of error catching (such as a spell checker) may be required.
Technique 2: In any situation where a user's selection could cause an irreversible change such as deleting a file, a confirmation dialog must be provided. In programs where such confirmations may be annoying or obtrusive, it is acceptable to include a user preference, which allows the confirmation to be disabled.
Technique 3 (Figure 5): iShell automatically handles run-time errors with a pop-up box. Using the nav.xd meta document, it is possible to over-ride errors by including an error event. Note that this will suppress the default behavior.
Figure 5: This screenshot of the object-oriented iShell authoring interface shows an example of how an Error Handler looks when it contains an ZebraSpeak iShell Accessibility Plug-in 'Speak' command to speak out loud the error text, which would normally appear in an iShell generated pop-up. For this method to work, it must be contained in a nav.xd style meta document. Note: The 'Key Handler' element which appears above the 'Error' event is part of the nav.xd functionality and is not related to the Error Handler.
For more information see checkpoint 2.5 in WCAG 2.0.
iShell outputs Unicode by default. It is suggested that all text and HTML documents used in an iShell project be encoded in Unicode, whenever possible. In situations where Unicode is insufficient or undesirable, there is no programmatic way to declare the method of encoding. A visible message indicating the style of encoding may be desirable, but is not required. Future versions of iShell may address this.
Technique 1:
There is no built-in capability within iShell to programmatically determine
the language of content. To achieve partial compliance with this checkpoint,
use HTML when including a text object in an iShell program. When using HTML,
use the relevant HTML techniques for this checkpoint, such as the lang
attribute.
HTML:
<p lang="en/us">Here is a paragraph which is in American English except for <span lang="fr">un petit peu en Francais.</span></p>
iShell does not include a built-in definition/expansion scheme, but there are several techniques for incorporating such a scheme into iShell:
Technique 2: Create an empty text field somewhere in the interface. This text field may be at the bottom, where it can function as a status bar and also be used for satisfying other checkpoints such as Checkpoint 1.1. Once this text field has been created, the acronyms and abbreviations can be implemented as separate labels and a mouse event can send a 'Tell' field command to the status bar with the appropriate expansion text. This method is not recommended, but is included for the sake of completion.
Technique 3: The iShell HTML parser does
not currently support the ABBR and ACRONYM tags that
are the preferred way of meeting this checkpoint using HTML. However, if you
use HTML to include all your textual content, you can use these tags (as described
in the HTML techniques document) to specify definitions and expansions. Although
this will not be readily accessible in current versions of iShell, the information
will be programmatically available and my be taken advantage of by future, more
compliant versions of iShell.
Technique 4 (Figure 6): Use RTF (Rich Text Format) to encode documents, format all acronyms and abbreviations as "Strike-Through". Immediately following each acronym or abbreviation, include the expansion or definition formatted as "Invisible". When the RTF encoded text is imported into iShell, this formatting system will be automatically interpreted as Hot Text. Create a status bar Text field (as in Technique 1) and use a Hot Text event within the Text object which is sensitive to a mouse event. Within the Hot Text event, include a Tell Field command which writes the value of the Hot Text to the status bar field. A single event (or pair of events) can handle all of the instances of Hot Text within an RTF document.
Figure 6: This screenshot of the object-oriented iShell authoring interface shows an example of how an RTF document containing "Hot Text" can be set up with two "Hot Text" events. The first event sets the content of a Text field to the value of the Hot Text on 'Mouse Enter'. The second event resets the contents of the field to an empty string on 'Mouse Leave'.
An iShell document, like any other web document must be written using the clearest and simplest language that will serve the purpose and with an inclusionary intent whenever possible.
For more information see checkpoint 3.1 in WCAG 2.0.
An iShell program, like any other Web content must be written in a consistent fashion, such that the content is not confusing or hard to follow.
For more information see checkpoint 3.2 in WCAG 2.0.
iShell allows some other technologies to be included in its projects. When using technologies such as HTML or RTF, ensure that usage of these technologies meets existing standards and specifications. Specifically, when using HTML, you should state which W3C HTML specification you are using (HTML 4.0, XHTML transitional, etc.). Also, when using HTML ensure that all content meets the HTML techniques for WCAG 2.0.
For more information see checkpoint 4.1 in WCAG 2.0.
For more information see checkpoint 4.2 in WCAG 2.0.
The ZebraSpeak module adds text-to-speech and advanced keyboard interaction to iShell. Together, these two features enable you to create products in iShell that are accessible to blind and physically disabled users.
The Text-to-Speech works with Apple's built in speech synthesizers on Mac OS 9 and OS X. On Windows, it uses the Chant® SpeechKit® engine to provide compatibility with the main speech synthesizers for Windows, including the standard Microsoft¨ speech engines.
The Speak commands are very flexible, allowing you to speak the names and contents of elements, speak the contents of a text, rtf, or html file, or speak a string generated on the fly.
The keyboard interaction tools allow you to build a dynamic list of elements to receive keyboard events, so you can easily create and maintain complex keyboard navigation schemes. A special Tab Handler object is used to automate interaction with "tabbable" elements on a screen, elements that need to respond to the tab and return keys.
ZebraSpeak works with iShell 3 and iShell 4, and requires Mac OS 9, Mac OS X 10.2 or later, and Windows 95 or later
Download the ZebraSpeak iShell Accessibility Plug-in
Many accessibility functionalities in iShell are global
to an entire project. It makes much more sense to abstract these functionalities
out to a document which can then be included in every other document in the
project than it would to unnecessarily do the same work many times.
The two primary uses of nav.xd are for error catching and key catching. For
example, if you are using the ZebraSpeak Accessibility
Plug-in
and would like to use the Text-to-Speech engine, the nav.xd approach allows
you to provide one simple functionality for turning TTS on and off. All you
need to do is include a Key Handler element in nav.xd which then contains
a Keyboard event. Normatively, the standard for turning TTS on and off in
iShell projects is a single press of the 't' key. Beneath the Keyboard event
which captures the 't' keypress, include an If-Else command which detects
the current TTS state and then activates a SpeechPrefs command to change the
value. Figure
7 shows what a TTS toggle should ideally look like in nav.xd.
Figure 7:
Likewise, you can include any global keyboard functionality in nav.xd using similar methods. Also, error catching (as described in the techniques for checkpoint 2.5 and shown in Figure 8) can be handled best by being abstracted into the nav.xd document.
Figure 8:
Once the nav.xd document is completed, simply include it in every other document as a root level element. It is important that nav.xd always be the LAST element in the list. Figure 9 shows an example of nav.xd properly included in a iShell document.
Figure 9:
