Windows Guidelines for Accessible Software Design from 1997

For thinking about techniques documents, in addition to the examples 
already referenced in our discussions you might want to check out this 
document I created for Microsoft back in 1997.

The Microsoft® Windows® Guidelines for Accessible Software Design
Creating Applications That Are Usable by People with Disabilities
Includes Concise Summary of Requirements and Recommendations
May 7, 1997 Edition
http://www.cs.bgsu.edu/maner/uiguides/msaccess.htm

(This was not the most recent version of the guidelines, but is the most 
recent version I've found on the Web. Also, it was originally 
distributed as a Microsoft Word document; and the formatting of this Web 
page is not exactly the same.)

It's interesting to look back on it now. For example, the Detailed 
Design Guidelines section is divided into functional areas, such as 
Keyboard Access, Exposing the Keyboard Focus, Color, etc. Each guideline 
or group of related guidelines can have a title, an "infobox" (with the 
short form of the guideline, priority rating conveyed by stars, logo 
requirement status, and a list of affected groups), an overview 
paragraph, and a list of benefits by affected population, followed by 
entries for specific guidelines and techniques. Guidelines may also 
include lists of Required Steps, Additional Recommendations, Exceptions, 
Hints, Verification procedures, along with Exercises and a Quiz that 
were published in a separate document.

Here's are two example Guidelines, "Exposing the Keyboard Focus" and 
"High Contrast Mode",  that use different approaches: the first is a 
collection of techniques (each discussed under its own sub-heading) 
while the second is much more concise and standardized elaboration of 
the guideline.


    Exposing the Keyboard Focus

[Begin InfoBox] 

Expose the location of the keyboard focus within a window.

*         Automatic for objects that are separate windows.

*         Within a window, use Active Accessibility
or move the system caret to cover the object's bounding rectangle.

	

[Four Stars]

*Logo Requirement*

Blindness

Low Vision

Dexterity

Cognitive

Language

 [End InfoBox]

ART: Screen shot, close-up of a push button showing the focus rectangle.

Many accessibility aids need to identify the "focus point" where the 
user is working. For example, blind-access utilities describe the text 
or object that the user is working on, and screen-magnification 
utilities pan to enlarge whatever is at that portion of the screen. 
Utilities also rearrange windows to avoid covering up "where the action is."

Sometimes it is easy for an accessibility aid to determine this 
location; the operating system tells them when the focus moves to a 
window, menu, or standard control. It is more difficult to determine the 
location when an application uses its own method of indicating the 
visual focus /within its window/, such as highlighting a cell in a 
spreadsheet, an icon, or a windowless custom control. In these cases, to 
be accessible, the application must make its focus location available to 
other programs in the system. It can do this using Active Accessibility, 
or by moving the system caret; both methods are described in more detail 
below.

*Benefits*

u      *Blindness*: Screen review utilities need to be able to describe 
objects as the user creates, selects, or manipulate them, and describe 
the context in which the user is working.

u      *Low vision*: Screen magnification utilities need to pan to keep 
the keyboard focus in view.

u      *Dexterity*: Voice input and on-screen keyboard utilities need to 
know the commands available, which are dependent on the focus context.

u      *Cognitive/Language*: Reading aids for people with dyslexia or 
who are learning to read need to read or highlight words as the user 
types, selects, or manipulates them.

 


      Using Standard Windows and Controls

Standard windows and controls already expose the keyboard focus

Windows informs accessibility aids when windows get or lose the keyboard 
focus. It does this using Active Accessibility, Windows hooks, and 
window messages. This also applies to standard Windows controls, each of 
which has its own window.

Therefore no additional work is required for standard Windows controls, 
or objects that occupy the entirety of a window.


      Using Active Accessibility to Expose the Focus

Microsoft Active Accessibility is the preferred method of exposing the 
keyboard focus location. The application must call *NotifyWinEvent* 
whenever the focus moves to an object that does not correspond to an 
entire window. It must handle the *WM_GETOBJECT *message when that is 
used to query the focus object. COM objects representing screen elements 
must also support the *accFocus* property.

For more information on Active Accessibility, see .


      Using the System Caret to Expose the Focus

It is easy---and harmless---to expose the focus location by moving the 
system caret

The system caret is the blinking vertical bar that the user sees when 
editing text, but it can be placed anywhere on the screen, made any 
shape or size, and even made invisible. If it is invisible, it can be 
moved to indicate the focus location to applications without disturbing 
what the user sees on the screen.

Making the system caret invisible is easy: simply call the *CreateCaret* 
function to set the caret's size and shape and the *SetCaretPos* 
function to move it to wherever you are drawing the visual focus 
indicator (the highlighted cell, icon, button, and so on). Note that it 
is present but invisible, unless you explicitly make it visible.

Each time the focus moves to a new object with a different size, the 
application should call *DestroyCaret* and then use *CreateCaret* to 
specify the size of the new object. The system caret must cover the 
bounding rectangle of the screen element, so that screen magnification 
tools can allow the user to zoom-in on the left, right,

An application should only display focus and selection indicators when 
they are in the active window. When the window loses activation, the 
application should remove the visual indicator and also call the 
*DestroyCaret* function. (For Win32 applications, this step is not 
strictly necessary, but is still good practice.)


      Examples of Keyboard Focus Location

Sometimes it may seem hard to decide what to indicate as the focus 
location. Extended and discontiguous selection often confuse the issue, 
but the keyboard focus location should be considered independent of 
selection, even if an application normally links the two.

The following examples may clarify the distinction and help you learn to 
identify and indicate the keyboard focus location in your own application:

u      *Insertion bars in text.* When the user moves an insertion point 
within text, it is usually drawn with the real system caret. If the 
application chooses to draw its own insertion point, it should still 
move the system caret invisibly, tracking the location and size of the 
visible insertion bar.

ART: Screen shot showing close-up of text with an insertion bar.

u      *Extended text selection**.* When the user makes an extended 
selection, one end of the selection is always the "active" or moving 
end, and that is the actual location of the keyboard focus. For example, 
to select three characters, you start with the insertion bar in an edit 
control, and then hold down the shift key while pressing the right arrow 
twice. The end where you started is the "anchor," the stationary end; at 
the right, you should see the flashing caret marking the active end. If 
you hold down the shift key and press another arrow key, it is the 
active end that moves, and that is where the system caret should be 
placed. You should display a visible insertion bar at the active end, 
because that is useful feedback for all users.

ART: Screen shot showing close-up of an extended text selection with an 
insertion bar at one end. (Note this may be tricky to get with 
conventional snapshot software.)

u      *On graphic object**s.* When a user moves the keyboard focus to a 
graphic object, such as an icon or a bitmap, an application should place 
the system caret invisibly over the same object so that the caret's 
rectangle covers the entire image. If there is an adjacent label, the 
caret should cover that as well.

ART: Screen shot showing close-up of a folder view with a focus 
rectangle around one of the icons.

u      *Within graphic objects.* Sometimes, an application uses a single 
bitmap to represent several objects, such as a group of graphical 
buttons. The application usually indicates the focus by highlighting a 
portion of the bitmap, drawing a dotted rectangle over it, or even 
moving the mouse pointer. In addition to indicating the focus, the 
application should also place the system caret invisibly over the region 
of the bitmap that corresponds with the "hot spot" or object being 
referenced.

ART: Screen shot showing close-up of IE showing the focus rectangle on 
an AREA within a client-side image map.

u      *Simple controls**.* If an application is drawing simple custom 
controls, such as a custom push button, the keyboard focus is associated 
with the entire control, so the entire control should be covered by the 
system caret. (This is necessary only for windowless custom controls. If 
the control is a window, the window takes the keyboard focus, so it is 
not necessary to identify it using the system caret.)

u      *Complex controls.* A complex or composite control, such as a 
list box, can place the focus on individual elements within the larger 
control. In this case, an application should use the system caret to 
indicate the area of the particular item that has the focus. Even though 
the application might think of the collection of items as a single 
control, they should be treated as separate control elements when they 
are identified to external components.

ART: Screen shot showing close-up of a list box with the focus rectangle 
on one item.

u      *Spreadsheets.* When the user navigates within a spreadsheet, the 
focus is usually placed on an entire cell, rather than on content within 
the cell. Often, this is indicated by a bold cell border, and the 
application should place the system caret over the entire cell. If the 
user begins editing the contents of a cell, the application should 
indicate the focus appropriately for the content text or graphics.

u      *Discontiguous selection.* Discontiguous selection is usually 
supported among discrete items, rather than in text. There is always one 
item that has the keyboard focus or was most recently clicked by the 
mouse, and that object should be covered by the system caret. To see an 
example, select an item in a folder or in File Manager, and then hold 
down the CTRL key while pressing arrow keys to move the focus rectangle 
to a file that is not part of the selection.

ART: Screen shot showing a folder view, with discontiguous selection.

u      *Mouse-only objects.* Although applications should provide 
keyboard access to all their functionality, some objects can only be 
manipulated or selected using the mouse. In this case, you should treat 
the object when it is selected as if it received the keyboard focus and 
use the system caret appropriately to indicate that it has the focus. Of 
course, if the real keyboard focus moves, you should follow it, because 
the mouse-only object is no longer the object of the user's attention.


      Verification

The easiest way to verify this behavior is to use the Magnifier 
accessory included with the Active Accessibility SDK. This will be a 
standard accessory with future versions of Windows and Windows NT. Use 
your application with the keyboard and make sure that the place where 
you are working appears, magnified, in the Magnifier window.

You can download the Active Accessibility SDK from 
http://microsoft.com/enable/.



Here is a second example:


      High Contrast Mode

[Begin InfoBox] 

When the High Contrast options is set,

·    Display only system colors selected through Control Panel or other 
colors that the user can customize.

·    Because documents are typically shared, a user must not be required 
to alter a document in order to adjust the colors drawn on the screen.

·    System colors must be used in their proper foreground/background 
combinations.

·    Omit background images drawn behind text.

	

[Four Stars]

Logo Requirement

 [End InfoBox]

[Begin Callout] High Contrast mode is one of the most important means of 
accommodating users with visual impairments [End Callout]

ART: Screen shot showing detail of something using the High Contrast 
Black (normal size) appearance scheme.

An application that uses standard system colors or allows the user to 
choose colors that are not defined by the system has its basic color 
needs covered. However, this is not always appropriate for the default 
configuration. This is why the use can set the High Contrast option in 
Control Panel to indicate when they need high legibility.


        Required steps

u      *Use only colors that the user can customize *through Control 
Panel or through the application's own view options. Because document 
are often shared, it is not acceptable to make the user change a 
document in order to display it in different colors.

u      *Use colors in their proper foreground/background combinations*.

u      *Omit background images *or other complex backgrounds behind text 
and controls.


        Additional recommendations

u      *Supplement any information that would normally be conveyed by 
color alone*, with text, graphics, or patterns.

u      *Draw images in monochrome *instead of multiple colors, and draw 
them using standard foreground and background colors.

u      *Replace application-specific colors *with colors selected 
through Control Panel, and try to use as few color combinations as possible.


        Exceptions

u      Palettes where the user selects a color may continue to display 
their full range of fixed colors.

u      Applications are not responsible for changing the appearance of 
third-party controls or embedded objects, unless they ship those objects 
with their product.


        Hints

u      Applications can check for this setting by calling the 
*SystemParametersInfo* function with the *SPI_GETHIGHCONTRAST *value. 
Applications should query this value during initialization and when 
processing *WM_COLORCHANGE *messages.

u      Call *GetSysColors *to identify the colors chosen through Control 
Panel.


        *Exercises & Quiz
        *

EXERCIZE: Select the High Contrast Black appearance scheme. Look at your 
application and note in your survey form any screen elements that don't 
appear in the color appropriate for that scheme.  Look up "colors" in 
your application's documentation and see if you can adjust the color of 
the remaining elements.

QUIZ: Given a screen shot, match the appropriate Control Panel color to 
each numbered screen element.

QUIZ: Select the High Contrast Black appearance scheme. Run the test 
application provided and check off which elements don't appear in the 
color appropriate for that scheme.

QUIZ: Which of these are implied by High Contrast flag?  App must be 
fully compatible with the High Contrast Black appearance scheme [NO] App 
must be fully compatible with the Windows Default appearance scheme [NO] 
App must use only colors selected through Control Panel [NO] App must 
support fonts larger than 10 point in size [NO] App must allow the user 
to adjust all colors [CORRECT].