Does your application sound as good as it looks? It should!

An important part of designing an application is making the user interface easy to use. But designers often overlook the possibility that the target audience for their application may include people with disabilities.

Designing an application that is accessible to all users requires a basic knowledge of accessibility issues and the techniques to solve them. The good news is that it's not difficult to design an application that looks good for sighted users, sounds good for blind users, and is easy for everyone to use.

Because of new legislation in the U.S. and abroad, federal and state governments are making accessibility a requirement for information technology. In the U.S., Section 508 requires all federal agencies to make their information technology accessible to their employees and customers with disabilities. Starting in 2001, all new IT equipment and services purchased by federal agencies must be accessible. At least 13 states have adopted similar legislation requiring accessible products.If you are designing applications, it's critical that you know how to design and test your applications so that they meet accessibility standards.

This article discusses the common issues that people with disabilities encounter when using R5 applications and provides techniques for developing and testing your application to meet accessibility guidelines.

Accessibility issues and R5 applications

Accessibility is an attribute that makes a product usable by people with disabilities. Someone with a disability will use assistive technology to access information technology. Assistive technology includes both hardware and software. For example, someone who is blind may use a Braille display or a screen reader that speaks the information that appears on the screen. Alternative input devices such as voice recognition or alternative keyboards may be used by someone with mobility impairments. Assistive technology won't work with an application unless the application has been designed to meet accessibility requirements.

R5 provides many new accessibility features (see the Iris Today article, "Notes R5: Accessibility" for details), but application designers must incorporate those features into their applications. Here are some of the most common problems a person with a disability encounters when using Notes and Domino applications.

Blind and visually impaired users

Blind and visually impaired users encounter problems in the following areas:

• Keyboard navigation
  Someone who is blind or visually impaired uses the keyboard to navigate an application because they cannot use the mouse. If the application uses controls that are difficult or impossible to access with the keyboard, the application is not accessible.
• Field help
  Screen readers cannot accurately identify the text label associated with an input field, so they use the field help to provide information to users. When a user tabs to an input field, a screen reader reads the field help for that field and not the text label. If field help is not included, when the user tabs to the input field, the screen reader will say only "edit."
• Graphics
  Applications can use graphics and still be accessible. Assistive technology uses alternate text and text labels to provide information about graphic objects. When alternate text is provided, screen readers speak the alternate text for the graphic so a blind user can get the same information as a sighted user. When alternate text is missing, the screen reader says "graphic" and the information is lost.
• Web navigation
  Someone who is blind must navigate a Web site sequentially. There is no easy way to skip repetitive links unless the page includes a "skip navigation" link. Web pages can also be navigated by frames if meaningful frame titles have been included in the design. If these items are missing, it can take several minutes to read the navigation bars on the top and bottom before the user finally hears main content on the page.
• Inaccessible controls
  Some functions (for example, navigators, text pop-ups, and some Java applets) are not accessible to assistive technology. If the application includes these controls and does not provide an alternative way to get the information, the application is not accessible.

Mobility impaired users

Mobility impaired users encounter problems with:

• Keyboard navigation
  Someone who has a mobility impairment may not be able to use the mouse for navigation and will require keyboard navigation.

Deaf and hard of hearing users

Deaf and hard of hearing users encounter problems with:

• Visual presentation of audio information
  Most R5 applications are accessible to someone who is deaf or hard of hearing. However, if the application uses audio information, that information will be lost unless the information is also provided in a visual format.

Back to top

Example: How a blind user reads a Notes application

To better understand why accessibility requirements are important, it's helpful to understand how someone who is blind accesses your application. The R5 mail template is a great example of an accessible application, so let's use that to demonstrate how a screen reader works.

The bookmark bar

Sighted users scan the bookmark bar and then click the bookmark they want with the mouse. Someone who has to use the keyboard can easily access bookmarks on the bookmark bar by typing Alt-B to display a number or letter for each bookmark. You can then open the bookmark by typing Alt-B + the number or letter of the bookmark you want.

The process is a little more complicated using a screen reader since information must be read sequentially. When you type Alt-B, the screen reader announces the bookmarks by number or letter; for example, "One is Mail. Two is Calendar. Three is Address book." You can't scan the list; you have to wait for the bookmark you want to be accessed and remember that number. Because it can be difficult to listen to a long list of bookmarks, there is also an option you can add to your NOTES.INI file that allows you to type Alt-B and then use the arrow keys to read each bookmark one by one.

Task buttons

The task buttons for open windows are accessed in a similar way. Type Alt-W and the number or letter for each open window's task button appears. The screen reader reads each item; for example, "One is Welcome. Two is Workspace. Three is Shannon Rapuano Inbox. Four is Untitled." You can also use Ctrl-Tab to switch between tasks.

An untitled window occurs when the developer does not include a window title for a form. As a sighted user, you can click on the item to give it the focus, scan it quickly, and figure out if it's the document you want. It's not so easy if you are using a screen reader. You would type Alt-W, get the number of the "Untitled" window, which in this case is 4, and then type Alt-W+4. Then the screen reader starts reading the document sequentially until you have heard enough information to determine if it is the document you want. Window titles are so easy to include in the design and greatly improve productivity for someone using assistive technology.

The Mail file

Let's take a look around the Mail file using a screen reader. Open your mail Inbox with Alt-B+1. You will hear the window title for the application and then information about the document highlighted in your Inbox; for example, "Shannon Rapuano-Inbox. Unread Craig Lordan 8/31/2000 9:00 am. Input for your Iris Today article." Because R5 uses Microsoft Active Accessibility (MSAA) to expose object information, the screen reader identifies those documents that are unread. You can use the Up and Down arrow keys to read the items in your Inbox or tab to the next unread document.

If you press F6 to go to the next frame, you will hear "Mail Title." This is the title of the page that displays the word "Mail" in the frame. Press F6 again to go to the next frame, and you will hear "Tree view Inbox selected." You know it is a view and that the Inbox is selected. As you use the arrow keys to move through the view, each item is read. You can press Enter to open the selected view or folder.

You can press F6 until you get to the last frame, and you will hear "Open Calendar Frameset." The graphics have been labeled with alternate text, so they can be read by the screen reader. You can press the Spacebar to activate the calendar.

Back to top

R5 application accessibility checklists

The IBM Accessibility Center develops accessibility checklists for R5 and R4 applications as well as Software, Java, Web content, and hardware. Each checklist provides detailed rationale, development techniques, and test strategies that can be used to implement and verify the accessibility of your products.

The sections that follow discuss key accessibility requirements for various parts of your R5 applications. You can also view the Accessibility Center's complete R5 Application Accessibility Checklist.

Back to top

Key issues for forms

Include action buttons and forms in the appropriate menu

The action bar is accessed from the keyboard by holding down the Alt key and pressing the number key that corresponds to the number of the action. When you press the Alt key, the number appears above the action button, and screen readers will read the number and the button label. For example, when Alt is pressed in the Inbox view, the screen reader says "1 is New Memo, 2 is Reply, 3 is Forward." Accessing the buttons using this method is slow, and the user has to remember the number of each button as it is spoken. Including the buttons in the Actions menu provides easier access for someone who cannot use the mouse or someone who is using a screen reader.

Here are techniques for handling action buttons and forms:

• Include all action buttons in the Actions menu. This option is selected as the default in R5.
• Include forms in the Create or Actions menu if users need them to create documents.
• Define meaningful keyboard shortcuts for the actions. This allows users to type the shortcut (for example, Ctrl-O for Open) instead of navigating through the list with the arrow keys.

Test the keyboard access to action buttons and forms by verifying that there are equivalent actions available in the Actions menu for all action bar actions. Using only the keyboard, press Alt-A to open the Actions menu and verify that the action buttons are listed. If the action is not listed in the Actions menu, it may be listed in the Create menu. To access the Create menu from the keyboard, press Alt-C and navigate through the selections with the arrow keys.

Provide short field help for all editable fields

Field help gives users additional information to assist them with filling out documents. Field help can be useful to everyone, but it is critical for someone using a screen reader. A sighted user can read the field label to understand the field's general purpose and look at the field help for additional information. However, the field label is not always accessible to someone who is blind.

When someone using a screen reader tabs to an input field, the screen reader reads the contents of the field help, the type of control, and then the value of the input field if it is not blank. Since Notes does not associate the label programmatically with the input field, the screen reader may not "see" the label and may not read it to the user. Screen readers rely on the field help to tell users about the editable field.

Here are techniques for field help:

• Provide short field help for all editable fields.
• Where possible, field help should be no longer than five to eight words in length. When the user tabs to the field, the entire help line is read by the screen reader. If the help is too long, it interrupts the reading of the rest of the document.
• If a form contains similar fields, provide unique field help for each field. For example, if the form has an editable field for Home Address and Business Address, the field help should be unique for each item, not generic help text such as "Enter the address."

You can easily test field help by tabbing to each editable field and verifying that the field help text appears at the bottom of the screen near the status bar.

Back to top

A key issue for graphics

Provide alternate text for important graphics, image maps, and image map hotspots

Adding text descriptions to graphics allows users who are blind to visualize the graphics. Screen readers use the text description (entered as the graphic's alternate text) to identify the graphic to the user. If the graphic is not a link or if it is unimportant or redundant, do not include the alternate text. Someone listening to a document cannot ignore text the way someone viewing the document can ignore a graphic.

Here are some techniques for graphics:

• Assign alternate text to each important graphic using the Alternate Text field in the Picture properties box. If the image is a picture of an object, the object's name would be appropriate alternate text. For example, the alternate text for a picture of a red balloon would be "picture of a red balloon."
• Assign alternate text to image maps using the Alternate Text field in the Picture properties box.
• Assign alternate text for image map hotspots using the Alternate Text field in the Hotspot properties box.

You can test alternate text using several different methods:

• Start the application in your browser and move the cursor over graphics on the page. Alternate text appears as a text pop-up. If no text pop-up appears for important images, alternate text is missing.
• Turn off images in your browser. Each image is replaced with its alternative text.
• Test the site with Bobby, a free HTML analyzer tool from the Center for Applied Special Technology (CAST).

Back to top

A key issue for buttons

Provide text labels for buttons

Screen readers use the text label on a button to describe the purpose of the button. If the button label is blank or the label is a graphic or icon, the screen reader will say "button" and the user will not know the purpose of the button. If an action button only has a printer icon, a sighted user would know they would use the button to print a document. The screen reader does not have information about the icon, so it can only say "button."

Here are some techniques to use with buttons:

• Provide a name (text label) for all hotspot buttons.
• Provide a name (text label) for all action buttons. If you include an icon, do not select the option "Only show icon in button bar."
• Do not use graphic buttons on layout regions or navigators because the graphic cannot be labeled with alternate text.

You can test text labels for buttons by visually verifying that all buttons have text labels.

Back to top

Key issues for navigation

Provide a title for each frame

A sighted user can scan a Web page to look for the information they want on the page. A blind user must navigate the Web page sequentially. If the page is a frameset, they can also navigate the page by frame. When the frames have meaningful names, the user can select the frame they want to visit and skip over the information that is redundant or irrelevant.

Here are some techniques to use with frames:

• In the Frame properties box, provide a meaningful and unique name for each frame within the frameset.
• "Banner Frame," "Navigation Frame," and "Main" (for the main content of the page) are good frame names because they identify the primary function of the frame. Frame names like "Top," "Left," and "Red" cannot be used to navigate the page.
• Minimize the use of abbreviations in frame names. The frame name "navfr" is not understandable when read by a screen reader.

You cannot verify frame names without the use of assistive technology. The IBM Accessibility Center Web site has a list of resources for assistive technology products including those that provide trial versions. When one of the assistive technology products is installed, you can use the List Frames option to display the list of frames in the frameset. Verify that the list of frames provides meaningful information to assist you with navigating the page.

Provide methods for skipping over navigation links to get to the main content of the Web page

When a navigation bar appears at the top of the page or down the left side of the page, sighted users can ignore the links and go directly to the main content. Users who are reading the page with a screen reader must listen to all links across the top and down the left side before getting to the main content. This occurs for each page visited on the site when consistent layouts are used. However, sighted users can ignore the links and go directly to the main content. The purpose of this checkpoint is to enable users who are blind to skip over the navigation links and go quickly to the main content.

Here are techniques for skipping over navigation links:

• Provide a link at the top of the page attached to an unimportant image. The target of the image link is the beginning of the page's main content. This technique is used at the IBM Accessibility Center site. A person using a screen reader can activate the link and skip to the main content of the page. The alternative text for the image is "skip to main content." The link is only visible to sighted users if they move their mouse over the image. Provide an anchor for the main content that will be the target for the "skip to main content" link.
• Provide a text link at the top of the page to skip to the main content. The textual skip navigation link is visible to sighted users or someone using a screen reader.

You can verify that the page includes either a text link to skip navigation or that an image at the top of the page has a navigation link to the main content and has the alternate text "skip to main content." To see the skip navigation link, move the mouse over the graphic. The alternate text will appear in a pop-up.

Back to top

A key issue for embedded controls

Where possible, do not put multiple embedded objects on a page

Embedded elements (views, folders, outlines, navigators, and date pickers) can be placed on a page or form, subform, or document to add interactive control with an application. A page that contains more than one embedded element is very difficult to navigate with the keyboard when that page is included in a frameset. The user must already know the page layout in order to navigate with the keyboard.

Here are techniques for handling embedded elements:

• Place each embedded element on a single page to allow the user to easily navigate between elements using the F6 key. Putting the elements on a single page can usually be done without compromising the visual look of the page.
• Do not place embedded elements in a table.
• If you must have multiple embedded elements on a page, do not have more than two controls, and make sure the placement of embedded elements is consistent throughout the application. This will allow the user to use the same steps when navigating new framesets in the application.

Visually, you may not be able to tell if an application includes multiple embedded elements on a page, however you can easily verify this by using the keyboard to navigate the application:

• Press F6 to navigate to the first frame and then use the arrow keys or the Tab key to move through the frame. If you cannot access all items in the frame by using the arrow keys or Tab key, the frame contains multiple embedded items.
• Press F6 to navigate to the next frame and continue the process.

Back to top

Conclusion

As you can see, designing an R5 application that is accessible does not mean you have to compromise the visual appeal of the application, but it does mean being aware of accessibility issues. Many accessibility requirements like field help and button labels benefit all users. Others, like alternate text and frame titles, are critical for accessibility and may be transparent to sighted users. Including accessibility in your design is not difficult and will ensure that your applications are ready to meet accessibility standards that will be required by your customers. For more information, please visit the IBM Accessibility Center Web site.

Resources

• Notes R5: Accessibility
  
  
• IBM Accessibility Center
  
  
• R5 Application Accessiblilty Checklist
  
  
• Center for Applied Science Technology
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Accessibility issues and R5 applications
• Example: How a blind user reads a Notes application
• R5 application accessibility checklists
• Key issues for forms
• A key issue for graphics
• A key issue for buttons
• Key issues for navigation
• A key issue for embedded controls
• Conclusion
• Resources
• About the author
• Comments

Next steps from IBM

• Try: Lotus Domino Designer
• Webcast: Modernization approaches to reduce the total cost for multi-platform enterprise applications
• Briefing: Smarter collaboration with IBM Lotus solutions

My developerWorks community

Dig deeper into Lotus on developerWorks

Calling all developers

Download no charge Lotus Domino Designer

Special offers