Greetings:
The following usability document was sent to me by Cearbhall
O-Meadhra, from the Bank of Ireland. Some of you will remember
Mr. O-Meadhra from the Microsoft Accessibility Summit.
If anyone has comments to make, please send them to this list as
well as to Mr. O-Meadhra. His Internet address is:
I have to give the people in Ireland alot of credit. Clearly,
this is a good attempt at trying to identify those features which
blind people need in a good GUI screen reader.
Regards,
Curtis Chong
curtisc@winternet.com
=================================================================
VISUALLY IMPAIRED COMPUTER SOCIETY OF IRELAND
Graphical User Interface
Usability for Blind and Partially Sighted users
Version 1 - 21st June 1995
1 INTRODUCTION
1.1 OVERVIEW
1.1.1 This document has been compiled by the GUI Access sub-committee
of VICS. It outlines essential usability requirements for the
blind or partially sighted user using a GUI computer
operating system.
1.1.2 Blind or partially sighted users access computer systems by
synthetic speech, braille or large print. The hardware and software modules
which provide this access are usually referred to as 'screen readers'. The
term 'display' as used in this document refers to output provided by the
screen reader in one of the above media.
1.1.3 This document is intended as a guideline for access software
developers and a checklist for evaluation of access
software products. It is intended for all desktop GUI environments
i.e. Windows 3.x, Windows 95, Windows NT, OS/2 Warp, the Apple
Macintosh, UNIX GUI systems etc.
1.2 Principle
1.2.1 The guiding principle is that an accessible operating system should
enable the blind or partially sighted user to operate
GUI applications efficiently and effectively in a work environment.
1.2.2 A usable GUI screen reader should enable a competent
visually impaired PC user to be as productive as a
competent sighted user, using the same applications.
1.2.3 A GUI screen reader must be at least as usable as the current DOS
screen readers.
2 ESSENTIAL FUNCTIONAL REQUIREMENTS
2.1 TEXT READING
2.1.1 The GUI screen reader must be able to display all the text which
appears on the screen, irrespective of size, colour, font, or enhancement
such as italics, bold, underline, superscript etc.
2.1.2. It must also be able to display all punctuation symbols and text
graphics characters, such as bullets.
2.1.3 Editing symbols such as paragraph symbols tab marks, etc. should also
be displayable.
2.2 CHARACTER INTERROGATION
2.2.1 The GUI screen reader must be able to request the following
information about a character at any screen location:
* The name of the character;
* The phonetic name of the character;
* Case (upper or lower);
* Point size;
* Font;
* Enhancement (bold, underline etc.);
* ASCII or UNICODE value;
* Foreground and background colour.
2.3 APPLICATION RECOGNITION
2.3.1 The GUI screen reader must be able to recognise an application when
selected and load the appropriate user access definitions containing the
user's choice of optional settings.
2.4 AUTOMATIC OUTPUT
2.4.1 The screen reader should automatically display menu commands when
selected.
2.4.2 While navigating a WP document with the insertion pointer, the GUI
screen reader should automatically display the contents of the line onto
which the pointer has just been placed.
2.4.3 When in a spreadsheet, the contents of the cell onto which the pointer
has just been directed, should be displayed
2.5 CURSOR ECHO
2.5.1 While editing text in any location, the GUI screen reader
must provide the option of echoing characters, words or sentences.
2.6 ACTION REQUIRED
2.6.1 The GUI screen reader must indicate to the user what action is
required in a given situation (e.g. press enter, cursor key, tab, spacebar
etc.).
2.7 SCREEN OVERVIEW
2.7.1 The GUI screen reader must be able to give a screen overview,
indicating the windows, dialogue boxes, icons, and other screen objects
present.
2.8 SCREEN OBJECT NAVIGATION
2.8.1 The GUI screen reader must allow the mouse pointer to navigate the
entire screen, describing each object as it is landed on. It must be possible
to identify the following:
* icon,
* dialogue box,
* command button,
* radio button,
* check box,
* list box,
* combo box,
etc.
2.9 MOUSE CONTROL
2.9.1 It must be possible to direct the mouse pointer from the keyboard.
2.9.2 It should be possible to direct the mouse pointer to any location on
the screen.
2.9.3 It must be possible to issue mouse clicks from the keyboard.
2.10 MOUSE AND CURSOR LOCATION
2.10.1 It must be possible to identify the pixel position of the cursor and
mouse pointer.
2.10.2 It must be possible to customise this location to match the position
status in a WP document or the cell address of a spreadsheet.
2.11 GRAPHIC LABELLING
2.11.1 This section refers to braille and synthetic speech only.
2.11.2 The GUI screen reader should recognise and display the names of all
common icons. It should include a facility to
give verbal labels to new icons. This should apply to all icons, not just
'standard icons'.
2.11.3 It must also be possible to label any other significant graphic
symbols which appear on the screen.
2.11.4 Screen changes, such as the appearance of messages, or the opening of
new windows, should be announced.
2.12 AUTO READ AREAS
2.12.1 It should be possible to monitor certain screen locations, to
display a message if it appears, or to carry out a specified action if a
certain change occurs.
2.13 HIGHLIGHTED AREAS
2.13.1 It should be possible to have any highlighted area displayed on
request. This applies to any current options selected, text
marked for editing in WP etc.
2.14 CURRENT AREA
2.14.1 It must be possible to confine access to the current active
area (window, dialogue box etc.)
2.15 PRE-DEFINED ACCESS AREA
2.15.1 It must be possible to define certain areas of the screen to be
displayed on request - e.g. a status line .
2.16 ROBUSTNESS
2.16.1 Whereas it is appreciated that in new software a certain tolerance
of bugs is necessary, nevertheless regular crashing of the operating
environment by the screen reader is unacceptable.
2.16.2 It is expected that commands should work consistently and that it
should not be necessary for a user to have to issue
commands to flush out buffers or take regular remedial action to coax a
basic screen access command to function.
2.17 FLEXIBLE OPTIONS
2.17.1 It must be possible to turn on or off all of the above features
e.g. the cursor echo feature or punctuation reading feature may not always be
required.
2.18 SILENCE KEY
2.18.1 There must be a facility to instantly silence a synthesiser.
2.18.2 It must be an option to enable the interruption of displayed output
resulting from a prior action, in order to review a more recent display.
3 PRACTICAL TASKS
3.1 WORKPLACE
The accessible operating system must enable the user to carry out practical
tasks in the workplace.
3.2 WORD PROCESSING
It should be possible for the competent user to undertake a WP
examination such as Pitmann or City and Guilds, and to interpret and edit the
types of documents required.
3.3 STANDARD PACKAGES
Other standard office automation applications which the screen reader
should provide access to, include: spreadsheet, database, electronic mail,
terminal emulation and diarying/
scheduling applications.
3.4 OFFICE SUITES
In evaluating a GUI screen reader, particular attention should be paid to the
office automation suites. The current market leader in this category is
Microsoft Office.
End of Message
This archive was generated by hypermail 2b29 : Sun Dec 02 2012 - 01:30:03 PST