Return to Java/JavaScript Use Guidelines Page.
JavaScript Design Guide and Wishes
7/23/96
1. Introduction
JavaScripts are a way to make html documents more dynamic. If the occurrence and triggering of events is not controllable by and clear to the user, the dynamic nature of the JavaScript page may interfere with accessibility. Alternatively, the dynamic n
ature of JavaScript enhanced pages can be used to custom tailor a page to a users needs.
2. Using JavaScript to Customize a Page For Increased Accessibly
JavaScripts could be used to present existing information in alternate formats, pass user defined parameters to Java applets, and provide access to auxiliary information.
Auxiliary information could be provided by JavaScript functions desplaying descriptors of pages/page layouts/objects and of effects of an action. Descriptors could be available (if the user selected an explanatory mode) via a dialog box which pops up up
on onLoad() or onFocus() of regions of the page ( such as an image map, a href link, a form, button etc.). Information about href/links in a JavaScript document could be provided in a speedlist by the method document.link[i]. Information about the link/hr
ef could be provided in the speedlist (where a href/link leads to and the triggering event or activation event. Some of these links may be conditional. Should they appear in the list when they don't "exist" yet, or be listed along with their creation cond
itions?) The user could activate or cancel these presentations, and using cookies the user preferences could be retained between visits.
For a Java applet, a Javascript could query the user about their preferences (e.g. text size, color scheme, no images, etc.), and then pass these preferences to the applet as parameters.
JavaScript uses existing html attributes to construct a document page and the document page is subject to user browser preferences. The guidelines for Designing Accessible HTML Pages
apply to JavaScript created pages. The format can be transformed by a JavaScript, essentially by rewriting the whole page. The format affecting methods and attributes [fontsize(), fontcolor(), bold(), big(), blink(), small(), sub(), sup(), italics(), f
ixed(), strike(), fgColor, bgcolor, alinkcolor, linkcolor, vlinkcolor] are just written into the new version of the page. The transformed version of the page could provide the information in more accessible formats, besides simply altering color/text c
haracteristics.
Here is an example by Dream Designs of a JavaScript which allows the use user to change the background and font color, and remembers the users preferences between visits.
Certain web page contents have accessibility problems, i.e. Tables, multiple text columns, Frames, Outlines, Forms with too much white space, visual information (changing of the screen contents, graphics, movies and colors), sound and status line.
1. The information in a Table could be presented so the row and column heading and number is associated with the cell entry, each cell entry being on its own line, and a blank line between each row. [Example-Rows] or colum
n [Example-Columns].
2. Multiple column information (screen readers have difficulty with multiple columns) could be presented as one column. [Example].
3. A page with multiple frames (frames are presently difficult to navigate with a screen reader) could be presented in a no frames version. [Example].
4. Outlines ( a series of nested OL/UL) could be presented in a manner to convey the degree of indentation of each list item, and making clear which heading it is under.[Example].
5. Forms with a lot of white space between the elements are hard for a screen reader to tab/navigate. The form could be redraw in a compact format. Since forms are not supported on all browsers and may be very difficult to use for people who cannot see t
he screen, alternates to using a form could be provided. For example, a form for placing an order could have the redundant options of a text based form that could be downloaded and filled out with a text editor and a phone number and hours of availabilit
y for talking with a person (Fontaine).
6. The information in an image, movie or graph could be provided in a textual or auditory form. The information and maneuverability present in an image map could be provided in an alternate form. The event of a button being clicked, presently noted visual
ly, could be noted by an audio cue.
7. Overviews, summaries or page navigation aids could be provided and integrated into the page.
8. All auditory information could be provided in a redundant visual form (such as a ShowSounds format) and vice versa.
9. Text on the bottom line of browser is not accessible to screen readers, so the use of status() to present information should be avoided. This information could be presented in a dialog box. [Example].
Anything about an html page which makes access difficult could be presented in different formats upon the user calling an accessibility JavaScript function built into the page. Using cookies to remember the users preferences, the accessibility
JavaScript could be called as the page loads, presenting the transformed version of the page.
3. JavaScript Causing Accessibility Problems
JavaScript can cause activity on a web page, on its own or in response to users actions. As mentioned above, the changes caused by JavaScript can include changing the HTML/text written to a document . The guidelines for Designing Accessible HTML Pages apply to JavaScript created pages. The JavaScript activity can also involve calling/opening/closing documents/windows/dialog boxes. The actions caused by a JavaScript should not int
erfere with accessibility.
The event which triggers the change in the document should require active input from the user [ onClick(), onBlur(), onChange(), onSelect() or on Focus()] rather than a nonactive trigger event such as onMouseOver(). The user must be made aware that an a
ction will cause a change in the document and that a change has occurred in the document. The visual changes could include document.write(), .close() .clear() to the existing document, open() new documents, movement in history [back(), forward() go(int)]
or creating new windows/dialog boxes [window.open(), .close(), .confirm(), .prompt(), .alert()] . The user could be informed of a visual change event in a nonvisual manner, possibly by sound associated with creation of a dialogbox. The activity of the m
ethod which causes the change could trigger a dialog box noting the type of change which has occurred. The user/browser would set flags or request this mode in a JavaScript presentation control panel (the settings could be remembered between visits in t
he cookie).
4. Automated Page Alterations
The user may need to stop temporal events, to allow them to be analyzed and be responded to. A constantly changing marquee or score board is inaccessible because of the soda straw approach of screen readers. JavaScript applets usually have a method crea
ted by the programmer to measure time, and then trigger a change. To be able to suspend action in each of these unique methods would be difficult on a general level. A means of suspending/activating temporal change events should be built into the individu
al JavaScript.
Alternatively, additions could be added to the browser or to JavaScript to provide user preferences to suspend/activate document/window changes. A point of intervention to suspend temporal change events needs to be common among all methods which are used
to make temporal change events occur. Possibly the action of a timing method (involving setTimeOut()/ clearTimeOut() or another timing method) could be optionally suspended (via user/browser flag or JavaScript request control panel) until the user fulf
ills a triggering condition which allows the change to continue. Or the method which is the change, the write() or open() method of JavaScript might be able to be optionally stopped (via user/browser flag or JavaScript request control panel) until the u
ser fulfills a triggering condition which allows the change to continue.