Jutta Treviranus

ATRC

University of Toronto

 

Larger Context

• Alan Cantor

  • Assistive Devices
  • Alternative formats
  • Personal support
  • Transportation services
  • Adapted furniture
  • Building modifications
  • Low-tech devices
  • Environmental adaptations

Main areas:

• the workstation

• the online catalog and browser interface

• the document

The Workstation

• consider tasks to be performed

• training

• updating

The Workstation

• the operating system

• access system compatibility

• the introductory menu

• unloading access systems

The Workstation

• supporting documentation

• advertise

• security

The Workstation

• large monitor

• system access tools

• CCTV

• screen reader

• screen enhancement

• on-screen keyboard

• refreshable Braille

• alternative keyboard and mouse

The Interface

• simplicity

• consistancy

• problem of pseudo GUI

• front end search engine

• keyboard equivalents to all actions

• text equivalents to all graphics

• text/visual equivalents to all audio cues

The document

• Benefits of e-text

  • can be translated into Braille, large print, speech
  • does not require physical manipulation
  • can be searched and processed in various ways

The Document

• translatable format

• structured document

• descriptive not procedural markup

• SGML, HTML

The Document

• Accessible HTML

  • layout (no columns)
  • descriptive links
  • alt text for all in-line images
  • text equivalent for all image links
  • ISMAP alternatives
  • inaccessible file format alternatives
  • use markup for format
  • e-mail form alternative

Access Barriers

• People unable to use the mouse require several keystrokes per command.

• Quickkeys of the form (Ctrl-?) etc.. allow faster, more efficient navigation for users who are disabled and/or advanced.

Access Barriers (con\'t)

• Screen readers read the text within the HTML tags but omit the graphic surrounding them, causing confusion.

• Placing < · > around the tags would give users who are blind, crucial authoring information.

Access Barriers (con\'t)

• Keyboard users may have trouble with the non-standard cell navigation within tables.

• TAB should move one cell right.

• ENTER should move one cell down.

• Shifting should reverse.

Access Barriers (con\'t)

• The Edit Table palette is inaccessible to non-mouse users.

• The palette should be given keyboard equivalents.

Access Barriers (con\'t)

• Within the Frames Editor, specific frames cannot be selected using the keyboard.

• We suggest the arrow keys be used to select a frame once the user has TABed into the frame area.

General Interface

• Some Tooltip naming is inconsistent with Menu items.

• Dynamic menu lists might inhibit learning.

• Toolbar buttons donât always grey out.

• Thesaurus is inflexible.

• Tag begin/ending is too constraining.

General Interface (con\'t)

• Tables: Double clicking on a cell should pull up the table editor.

• Frame Editor: Frames with defined sources should display some sort of feedback to give the users a wider view of their production.

Transition slide

• and now on to prompting ...

Prompting: Introduction

• Presently, authors are often unaware that the products they create are not accessible to all.

• By prompting the user at critical times, providing tools and guidelines, we hope to inform and aid the user in the creation of accessible documents.

• Warnings can also be used to inform the user at appropriate times...

Prompting: Warnings

• Warnings could be used to alert the author to a problem when it occurs.

• Warnings should be displayed when the user:

  • makes an image into a button
  • forgets to enter an ALT text description
  • uses inaccessible text formatting
  • saves/validates an inaccessible document.

Prompting: Dialogue Boxes

• We can extend and modify HoTMetaLâs existing dialogue prompts in order to guide the process of accessible document authoring.

• We must consider the patience of the typical user.

• We have developed three user settings for prompting...

Prompting: Dialogue Boxes

• The default setting would be at the frequent level - the user is prompted for accessibility requirements at the stage of element insertion.

• The medium setting would only prompt during modification of elements.

• Finally, the lowest setting would only prompt at the accessibility validation stage (end of the authoring session)

Prompting: example

• On the next slide is the sample ALT text dialogue box that might appear following insertion of a graphic element.

• We apologize for the slight distortion of the image...

PPT Slide

 

Prompting (con\'t)

• As seen in the previous slide, our intention is to provide a rationale for what is requested of the user.

• Accompanying this rationale are tips and additional information to clarify the userâs role.

Prompting: adding features

• There are more involved cases to consider, such as movie captioning, image maps, audio clips, applets etc.

• We deal with each of these elements separately, each having its own dialogue, and if necessary, tools.

• For instance, consider the Movie clip ...

PPT Slide

 

Prompting: choices

• In many cases, there is more than one way to make an element accessible.

• An image element can have ALT text, a label, and/or a D-Tag.

• The ÎOther Accessibility Options·â allows this flexibility without overloading the user.

• In addition to the three options mentioned above is a text-only page...

Text-Only Page Stream: Wizard

• The ÎText-Only Wizardâ we have envisioned can be prescribed during the creation, or end of a document.

• It can facilitate the parallel creation of a text-only page stream.

• The wizard can automatically update existing text-only pages.

• The inclusion of style sheets could increase the level of automation.

Summary

• HoTMetaLâs platform is well suited to the method of prompting and accessibility validation.

• Some changes need to be made to the authoring interface.

• Prompting needs to be implemented.

• Some new tools: players, wizards · ?

• Collaboration.

Discussion