Greetings:
The following alpha draft on making the Motif Toolkit more
accessible is, I confess, way over my head. However, I thought I
would pass this on for your comments--if you care to make them.
Please do not comment to this list (NFB-RD@NFBCAL.ORG). Instead,
send comments (with a copy to me, if you would) to Beth Mynat.
Beth's email address is beth@cc.gatech.edu.
Warning Warning Warning!!!!! The following is long.
Regards,
Curtis Chong
curtisc@winternet.com
=================================================================
Investigate Motif for Accessibility
A Collaborative Research Effort between Sun Microsystems
and the Georgia Institute of Technology
Recommendations for Increasing the Accessibility of Motif
(DRAFT - ALPHA)
February 28, 1995
Elizabeth D. Mynatt (Project Director)
Keith Edwards, Sue Liebeskind, Sue Long, Will Luo
I. Executive Summary
--------------------
The purpose of this work is to review the Motif toolkit with respect to
disability access. From this review we make recommendations for
modifications to Motif which will ensure that Motif will use existing
disability access hooks in the X Window System as well as modifications
which will help developers tailor their applications for users with
disabilities (mobility and vision impairments).
We are dividing the review process into four layers that (top to
bottom) focus on the look and feel of an application interface to how
applications can provide information to external access software such
as screenreaders. The four layers are described below:
Motif style guide - How can application writers make their
interfaces more accessible? For example, by not hard-coding
color and font size characteristics, users will be able to
modify the appearance of the interface to meet visual
processing limitations.
Motif functionality - How could Motif be modified so that
Motif applications are more accessible? For example,
to assist access by a blind user, developers should be able to
supply textual labels in addition to pixmaps for icons.
Motif implementation - How to "fix" Motif's implementation
so that it is more accessible? For example, portions of
the Motif toolkit bypass recent "disability-access" hooks
used to support screen reader access.
By examining access issues at each layer, we are able to identify
current weaknesses as well as uncover deficiencies at other layers. For
example, by examining how programmer's specify names for widgets, we
identified deficiencies in how convenience routines automatically create
widget names. This iterative process allows research on one layer to
inform research at another layer.
At this point, we have tentatively added another layer corresponding to
a programming guide. After going over the Style Guide, we came to the
conclusion that it does not make recommendations regarding the internal
design of an application, nor how a widget should be programmed, but
rather how a widget (or interface element) should appear and interact
with the user. Thus an interface element may meet all style guide
guideline and still not be easily accessible to other access softwares
such as a screen reader. A button on a pull down menu can meet all the
requirements recommended by the style guide: having the correct key
activation, exact mnemonic, and appearance, and yet bypass access hooks
in the server with convenient functions or setting variables directly.
One way to solve this is if we make a guideline recommendation in the
style guide that can only be accomplished by a specific programming
techniques, calling XtSetValues(), for example. So to meet this style
guide requirement a programmer will have to use a specific call. Given
that this kind of guideline is possible and exists, it is still a round
about way of simply telling the programmer to use a specific call or to
use the toolkit in a certain way, which is much more clear and to the
point. The question is then "where do the implementation guidelines
belong?"
This document is the ALPHA DRAFT version of our recommendations for
improving accessibility to Motif applications. It is organized along
the four layers. The current contents include:
II. Motif Style Guide Recommendations Summary
An outline of our style guide recommendations based on
different user requirements.
IV. Additions to a Programmer's Guide
As previously described, we are currently compiling a
list of programming suggestions which do not seem
appropriate for the style guide, but may not be "fixed"
by modifications to the functionality or implementation
of the Motif toolkit.
V. Proposed Modifications to Motif Functionality
A list of additions to the Motif toolkit which would
improve the accessibility of Motif applications.
VI. Potential Deficiencies in the Implementation of the Motif Toolkit
A list of problems with the behavior of the current
Motif toolkit with regard to external access by a
screenreader. These observations are based on
experience with the Mercator screen reader.
IX. Demonstration Plan for Improved Motif Application Accessibility
Discussion of ideas to demonstrate improved access to
Motif based on the current list of recommendations.
II. Motif Style Guide Recommendations
-------------------------------------
Outline
This outline is still organized by user requirements but we are listing
interface elements defined by the style guide instead of widget
classes. Some of the disability requirements and guidelines can also be
found in the chapter "Towards Accessible Human-Computer Interaction" and
the CHI Tutorial 28, "Enabling Technology for Users with Special Needs".
(All page numbers refer to the 2.0 Style Guide draft.)
----------------------------------------------------------------------------
-
1. Keyboard:
1.1 Comprehensive keyboard access to the application.
One of the common requirement for a wide range of physical disabilities is
comprehensive keyboard access to the software. This is especially true for
people who cannot use a mouse as productively as a keyboard since a mouse
requires a higher degree of hand-eye coordination than keyboard.
Blind users do not have the visual feedback of the mouse pointer location
to direct it. They must have alternative methods of accessing all
functions
in an application.
The style guide draft already contains specific recommendations on key and
mnemonics assignments for control and choice interface elements. These
guidelines should increase the keyboard accessibility of
applications. We have also included a list of interface elements which
should be keyboard accessible (essentially all elements which receive
user input).
Interface Elements:
Activation, Active Window, Area Technique, Choice: (see Table
11, pp. 136-137) for a list of choice type elements),
Browse Technique, Cascaded Menu, Control: (see Table 12
and 13 for lists of control type elements),
Clipboard , Control Navigation, Direct Manipulation, Menu
(Edit, File, Help, Options, ), Extended Selection, Input Focus,
Internal
Navigation, Menu Navigation, Multiple Selection, Palette, Persistent
Selection, (Point Technique?), Point Swipe Technique, Pop-Up Menu,
Primary Copy, Primary Link, Primary Move, Primary Selection,
Primary Transfer, Pull-Down Menu, Push Button, Range Click and
Swipe Techniques, Sash, Shortcut Key, Tab-Group Navigation,
Tear-Off Menu, View Menu, Window Menu, Window Navigation,
1.2 Consistent key mappings.
This will allow the user to avoid having to learn a new set of key mappings
for each application. Imagine running four or five applications each
one having a different key mapping for similar functions. The style
guide already contains very specific guidelines on key mapping for
common gui control and choice functions.
Interface Elements:
All elements listed under 1.1 and Mnemonics.
1.3 Keys for frequently used functions should be easy to reach.
Frequently performed functions (or all functions, if possible) should not
be
mapped to a difficult key combination. The evaluation of this
requirement can be rather subjective since how easily a key can be
reached differs between users. However, as long as key mappings are
customizable, users can always adjust them to suit their needs.
Interface Elements:
This requirement should be applied to all interface elements which
accept user input (those under 1.1).
1.4 Logical "tab grouping" of input interface elements.
Many applications implement "tab groups" which moves the input focus among
groups of control and input elements. The order in which the input focus
moves among them should be consistent with other input orders (e.g. left to
right, top to bottom in an English environment.)
Interface Elements:
Group Box, Menu Structure, Palette
1.5 Avoid conflicts with keyboard access built into the environment.
Some keys and key combinations are reserved for access purposes. Normal
applications should avoid using these keys and combinations to prevent
unexpected results. A list of these reserved key mapping is in Ch. 9
(p. 138) of the CDE style guide as well as the proposed Ch. 9a for the
Motif Style Guide.
Interface Elements:
This should also be considered for all input elements, Keyboard
(Device), and those elements under 1.1.
1.6 More than one method to perform a keyboard task if possible.
The user can perform a keyboard task differently if one method is
causing
any strain. This requirement appears to contradict 1.2, although, it is
possible
to provide an alternative method or allow the user to change or add
additional key mappings for a task. (For sighted users this requirement is
usually met by having the mouse as an alternative input method. Blind
users may need an alternative keyboard input method though.)
Interface Elements:
same as those under 1.5.
----------------------------------------------------------------------------
-
2. Interface Element Description
2.1 Clear textual descriptions of (invisible) objects.
Provide good descriptions for control and object elements which are
represented graphically (even if the bitmap contains text). Do not rely
solely on graphics to describe an element. This requirement will mainly
benefit screen readers since in some cases the users require textual
information to understand their choices.
Interface Elements:
Column Heading, Object: Container, Group Heading, Icon, Label,
Palette, Push Button.
----------------------------------------------------------------------------
-
3. Auditory Feedback
3.1 Use Auditory Feedback when appropriate.
Auditory feedback has the advantage of using a different mode of
communication, allowing users to concentrate on the visual interface. For
screen reader users non-speech auditory feedback can be added on top of
speech output and still be distinguished.
Interface Elements:
Action Message, Create-On-Drag, Data Transfer,
3.2 Use auditory feedback for the states of toggle buttons/keys.
Provide the user with auditory feedback on the states of keys such as
Caps_Lock and toggle buttons such as radio buttons.
Interface Elements:
Keyboard (Device).
3.3 Visual feedbacks in addition to auditory feedbacks.
Do not depend only on auditory feedbacks. Either include visual feedback or
allow the user to choose either form of feedback. A user may not be able to
detect the audio feedbacks.
Interface Elements:
Audible Cue.
3.4 Allow users to change the volume and frequency of audio cues.
The user may want to modify the audio output depending on the environment
or personal hearing requirement.
Interface Elements:
Audible Cue, Warning Message.
----------------------------------------------------------------------------
-
4. Customizable Application
This can generally be done with widget based applications as long as the
application developers did not hardcode the interface.
4.1 Allow the user to customize application colors, graphical attributes
such as line thickness, border, and shadow, font sizes and styles. Do not
hardcode them.
Allow the user to pick colors which provide them with the greatest
contrast, to increase the font size and/or change the font style for easier
reading, etc.
Interface Elements:
Object: Container, Device; Cursor, Emphasis, Group Heading, Hot Spot,
Icon, Information Area, Information Message, In-Progress Message,
Label, Pointer, Push Button,
4.2 Allow the user to customize key mappings.
Some user may find alternative key mappings more suitable for their
needs. They may also be performing some functions more often than what the
developer thought they would and would like to map these functions to more
easily accessible keys. Applications still need consistent (and well
chosen) default key mappings but allow the user to modify them.
Interface Elements:
same as those under 1.5.
IV. Additions to a Programmer's Guide
-------------------------------------
Some of the style guide recommendations touch on the functionalities of
Motif. On issues such as providing a descriptive name using a common
resource (see Motif Functionality), the Style Guide does not seem to be the
place where implementation guidelines can be placed. This recommendation
does not directly make an application more accessible to the user but it
makes
the application accessible to other applications such as screen readers,
which in term make the application accessible to the user. Recommending
developers to not bypass X11R6 access hooks is another implementation
guideline which cannot be easily included in the style guide.
V. Proposed Modifications to Motif Functionality
------------------------------------------------
Section 2.1 of the recommendation summary (interface elements having good
descriptive names) gets into the issues of Motif's functionality in
addition to usability. Label widgets usually uses the labelString
resource to provide textual information to the user. However, the label
can also be typed PIXMAP. In this case there should also be accompanying
text describing the same information represented by the pixmap. The
programmer can either give the label widget a descriptive name as a
way to provide information about the graphic icon.
While the widget name can usually provide information about a widget
represented by a pixmap, in cases where a widget is created by a
convenience routine, the widget will be named by the convenience routine
instead. e.g. the XmCreateSimpleRadioBox() convenience routine creates a
RadioBox with each button name button_n. If these buttons display graphics
instead of text, then there should be textual information about the
buttons,
preferably as resources that screen readers or other access software can
access. The choices seem to be setting the labelString resource of the
button even if the button is typed PIXMAP or having a standard description
resource. In either case it has to be a resource that an access software
knows how what to look for.
Potential Deficiencies in the Implementation of the Motif toolkit
--------------------------------------------------------------
There are still several unresolved issues that remain for screenreader
access. Some of these are artifacts of the X protocol and some are
artifacts of Motif (or perhaps our understanding of Motif).
These issues are:
- cursor handling
- multiple Motif toplevel windows
- by-passing instrumented Xt calls
- strangeness in Motif gadget resources
CURSOR HANDLING
There's no way to get the glyph used to create a cursor after it's been
created. Note that this is sort of like the GC issue: Xlib provides
no "reverse mapping" to retrieve the information used to create a GC
given its ID. However, in the case of GCs Xlib keeps a cache of
them so that we can retrieve them through the client; there's nothing
like this for cursors though.
Seems there are a few options:
- Simply ignore cursors. The main thing we needed them for was to
detect modalities (eg, the stop watch cursor). There are probably
other ways to detect this, although the cursor method was pretty
clean.
- Instrument the cursor creation calls and have them stash a mapping
between cursor ids and the glyphs/pixmaps used to create them.
Unfortunately this has a space penalty for all clients (even those
who aren't participating in RAP), and requires internal
modifications to Xlib, so it may not be viable.
- Just get cursor information after rendezvous; all cursor creations
before rendezvous is lost. Is this better or worse than doing
nothing?
MULTIPLE MOTIF TOPLEVEL WINDOWS
We've noticed in using Mercator with Motif applications that most
(every?) Motif app creates two children of the root window. Mercator
detects window creations to determine when to contact a new client
application, and in some cases the extra toplevel creates problems for
us.
Mercator uses XmuClientWindow to find the client window of the
newly-mapped window and then sends this window a client message to
tell it to "start rapping."
In the case of most Motif apps this works fine: only one of the two
toplevels has the WM_STATE property set that XmuClientWindow looks
for. But for some reason, Mercator always tries to connect to the
"wrong" window of Mosaic. If we connect "by hand" to the right window
then everything works fine.
We haven't fully investigated the Mosaic source or the Motif source to
find out why this is the case. But if some Motif guru could explain
to us why this is happening we'd be able to code for it better.
BY-PASSING INSTRUMENTED XT CALLS
Mercator receives asynchronous notifications of changes in client
state via messages generated from the callback lists in the
HooksObject in R6. Various Xt calls which change state
(XtManageWidget, XtSetValues, ...) have been instrumented to call
these callbacks.
Unfortunately, many widgets by-pass these instrumented Xt calls for
performance reasons. The most common source for these problems is
when widget writers directly update the value of a resource, rather
than going through XtSetValues.
Mercator calls resources in widgets which may be updated without
calling instrumented Xt routines "unsafe." When a resource is flagged
as unsafe, Mercator does not trust its local, cached copy, but instead
generates a RAP message to retrieve the value on-demand.
Of course, the two problems with this approach are that (1) someone
(probably a guru for the particular widget set) must determine which
resources are unsafe by reading the widget source code, and (2) unsafe
resources incur a serious performance penalty.
STRANGENESS IN MOTIF GADGET RESOURCES
We have found some strange behavior in Motif gadgets. We haven't dug
through the Motif source enough to determine why we are seeing this
behavior. Basically we never receive any X, Y, Width, and Height
resource values for gadgets. When the gadget is first created, its
resource values are passed to Mercator. These resources (which are
necessary for Mercator to be able to deal with gadgets) all have value
zero. Further, we never receive any notification of updates to these
values (which may be because the gadgets are by-passing the
instrumented Xt calls).
Our understanding of how gadgets are implemented is fairly sketchy.
This is one of those areas where a Motif guru may be able to explain
how these resources are set and used in Motif gadgets and save us a lot
of time.
IX. Demonstration Plan for Improved Motif Application Accessibility
--------------------------------------------------------------------
To demonstrate the improved accessibility of Motif applications that follow
the recommended access guidelines, we can empirically compare two versions
of a Motif application, one version following the access guidelines and the
other without. The best choice of a demo application so far, given the
availability of source codes, seems to be NEdit. It is a general purpose
text editor written with many of the main Motif interface elements: menus,
dialog boxes, radio buttons, text entry fields, direct manipulation (text
highlighting/selection), to name a few. We can modify the current version
to follow all applicable access guidelines and compare its accessibility
with the original version or an "adverse" version of NEdit, one which
ignores all access guidelines.
The End
This archive was generated by hypermail 2b29 : Sun Dec 02 2012 - 01:30:03 PST