Building Accessible Applications

About this chapter

This chapter provides information about guidelines and requirements for making applications accessible to users with disabilities. It explains what features PowerBuilder offers to support the creation of accessible applications, and it includes pointers to additional sources of information.

Understanding accessibility challenges

When designing and developing software applications and Web pages that you want to make accessible to people with disabilities, there are four general types of impairments you need to consider:

  • Visual

  • Hearing

  • Mobility

  • Cognitive or learning

Visual impairments

Application users who are blind require text equivalents for all graphic images and videos available to the sighted user. The text needs to convey content that is conceptually equivalent to the information provided in graphical form, so that assistive technologies such as screen and braille readers can make the information fully accessible. All user interface (UI) elements must have text or menu equivalents, and blind users need keyboard equivalents for entering input that a sighted user would enter with a mouse.

To accommodate users who are color blind, you should avoid using color as the sole means of conveying information. Using fill patterns in addition to colors in graphs and other images is one strategy for supplementing information conveyed by color. Auditory cues can serve as an alternative way of presenting warnings or other content signaled by color only.

By enabling high contrast support, you can allow color-blind users and users with low vision to adjust default system colors and fonts to make areas of a window or Web page easier to distinguish. Users with low vision also use hardware or software magnifiers to enlarge the pixels on a display, and they depend on alternate text to get some of the information presented in images.

Hearing impairments

Users who are deaf or hard of hearing require visual representations of auditory information. You might need to provide alternate visual cues in your application for audible warnings, for example. Blinking text is one alternative, though the blink rate must be within a certain range to avoid causing problems for users with seizure disorders. Audio tracks require transcripts, and videos might require closed captioning.

Technology to assist with hearing impairments includes voice recognition products that can convert auditory information to text or sign language. Important also are TTY/TDD modems that connect computers with telephones and convert typed ASCII text output to Baudot code, which is what deaf individuals commonly use to communicate over the telephone.

Limited mobility

Users with limited mobility often have difficulty handling hardware and media, but input is typically their biggest challenge. Depending on the disability, mobility-impaired users might need to use voice recognition or an on-screen keyboard with an electronic switch, tracking ball, or joy stick. They might enter input at a slower pace, which means that timers and response times should be adjustable. Systems with built-in intelligence can provide cues to cut down the amount of input required. For Windows applications, the FilterKeys feature is available to slow the keyboard repeat rate, and the Windows StickyKeys feature allows users to enter multiple keystrokes such as Ctrl/Alt/Delete as key sequences.

Cognitive impairments

Reading difficulties, an inability to process visual or auditory information, problems with text input, and short-term memory problems can all affect a user's access to the content of software and Web applications. Use of clear, simple language, enforcement of consistent design, and presentation of the same information in redundant format, such as both audio and video, can all help users with cognitive impairments to access information. Providing adjustable response times is important to those whose comprehension is slower than normal. Making content available to screen readers to reinforce visual representation is another strategy for aiding comprehension of people with cognitive impairments.

General suggestions

For Web display, it is important to use elements for all markup instead of manipulating text features such as font size directly. Visual appearance should not be the only indicator of function for text elements. Element markup allows assistive technologies such as screen readers to announce text elements such as headings by their function.

Good design for accessibility benefits not only those with disabilities, but users in general. By enforcing a consistent interface design, using simple language, ensuring ease of navigation, and providing the same information in a variety of ways, you can make your applications more usable for everyone.

For more information

For general information about making websites accessible, see the World Wide Web Consortium website at http://www.w3.org/ and the Utah State University WebAim website at http://www.webaim.org.

For information on how your users can adjust various browsers for better legibility, and for ways to accommodate vision impairments in general, see the Lighthouse International website at http://www.lighthouse.org/.

Accessibility requirements for software and Web applications

Organizations that want to make their applications accessible to the disabled might have to comply with several sets of slightly different regulations and guidelines, depending on the countries in which their products will be sold or used.

Section 508

Section 508, enacted in 1998, is an extension of the U.S. Government's Rehabilitation Act. Section 508 requires that all electronic and information technology that U.S. Government agencies develop, procure, maintain, and use must be accessible to members of the general public who have disabilities. Many individual states in the U.S. have adopted these requirements as well. Organizations that offer software applications for sale to the U.S. Federal government and many state governments, as well as companies that use or sell accessibility aids, must comply with these regulations to ensure that their products qualify for purchase.

WCAG 1.0

The Section 508 guidelines are based on the accessibility guidelines published in May 1999 by the World Wide Web Consortium. These are known as the Web Content Accessibility Guidelines (WCAG) version 1.0. The WCAG 1.0 is the common basis for most accessibility guidelines and the standard for government enforcement of regulations in many countries today. These guidelines have three priority levels. Priority 1 deals with features essential for access to Web content; Priority 2 defines practices that make websites more usable and comprehensible in general, and especially to those using accessibility tools; Priority 3 describes enhanced usability features that make use of the newest technology.

Section 508 includes most of the Priority 1 WCAG recommendations, several from Priorities 2 and 3, and also a few other requirements that are not in the WCAG. The WCAG recommends that organizations strive to meet the Priority 1 and 2 guidelines.

French legislation

The French government has also enacted legislation requiring Web accessibility for those with disabilities and published criteria for conformance called AccessiWeb. AccessiWeb includes three levels, Bronze, Silver, and Gold, that correspond roughly to the three priority levels of the WCAG, but AccessiWeb promotes many level 2 and 3 requirements to higher levels and includes more detail than some of the WCAG recommendations.

U.K. legislation

The United Kingdom has passed legislation called the Disability Discrimination Act that requires websites targeting British residents to be accessible to those with disabilities. Enforcement of the U.K. law currently is based on the WCAG 1.0 Priority 1 and 2 guidelines.

Other countries

Many other countries have enacted legislation requiring government or general-use websites to be accessible to the disabled. Several of these countries explicitly require compliance with Priorities 1 and 2 of the WCAG 1.0, but a few require only Priority 1 compliance. Many other countries without legislated requirements use the WCAG standards in practice.

WCAG 2.0

The WCAG standards are currently being updated with the intention that they will become a universally accepted set of international guidelines for Web accessibility. WCAG 2.0 will focus on general principles that set out the characteristics websites must have to be accessible to users with disabilities. Separate documents will spell out the technical requirements so that these can be updated easily as technology changes without requiring updates to the general principles.

For more information

For information about the accessibility requirements of the U.S. Federal Government for software applications and websites, see the Section 508 Standards for Electronic and Information Technology at https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-section-508-standards/section-508-standards and the Guide to Section 508 Standards at https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-section-508-standards/guide-to-the-section-508-standards.

For the generally accepted international recommendations for Web accessibility, see the WCAG guidelines at http://www.w3.org/TR/WCAG10/. For the new guidelines under development, see the WCAG 2.0 guidelines at http://www.w3.org/TR/WCAG20/.

For the Web accessibility criteria adopted by the French government, see the AccessiWeb criteria at http://www.accessiweb.org.

Creating accessible software applications with PowerBuilder

PowerBuilder supports the following two technologies of Windows accessibility and automation -- Microsoft Active Accessibility (MSAA) and Microsoft UI Automation.

MSAA is a legacy technology introduced in Windows 95; it supports the PowerBuilder standard controls well; but it imposes major limitations on the PowerBuilder custom controls such as DataWindows. Starting from PowerBuilder 2019 R3, PowerBuilder supports a newer and more capable technology which overcomes the limitations of MSAA; this new technology called Microsoft UI Automation offers a richer set of properties and extended interfaces to manipulate not only standard controls but also custom controls (such as PowerBuilder DataWindows and child controls in DataWindows).

The support for Microsoft Active Accessibility (MSAA) and Microsoft UI Automation is enabled by default. You can disable the support using the Accessibility option in the PB.INI file:

  • Accessibility=0: Disable both MSAA and Microsoft UI Automation

  • Accessibility=1: Enable both

  • Accessibility=2: Enable Microsoft UI Automation only

  • Accessibility=3: Enable MSAA only

For example,

[Data Window]
ACCESSIBILITY=0

It is recommended that you enable (value is 1) or disable (value is 0) both technologies; if you set the value to 2 or 3 (enable only one of them), some testing tools may not work well with only UIA or MSAA, and may cause the application to malfunction or crash.

Microsoft UI Automation

With the Microsoft UI Automation technology, the UI elements of the PowerBuilder control can be accessible to the screen reader (such as Windows Narrator), the accessibility tool (such as Accessibility Insights, Inspect), and the automated testing tool (such as QTP) in Windows 10 and Windows Server 2019.

The Microsoft UI Automation technology allows you not only to access and test the PowerBuilder standard controls (see Table 1), but also the PowerBuilder DataWindow controls (see Table 2 and 3).

Table 1: PowerBuilder controls/objects supported by Microsoft UI Automation

Animation

CheckBox

CommandButton

DataWindow

DatePicker

DropDownListBox

DropDownPictureListBox

EditMask

GroupBox

HProgressBar

HScrollBar

HTrackBar

ListBox

ListView

MonthCalendar

MultiLineEdit

Picture

PictureButton

PictureHyperText

PictureListBox

RadioButton

SingleLineEdit

StaticText

StaticHyperText

Tab

TreeView

UserObject

VProgressBar

VScrollBar

VTrackBar


The following PowerBuilder controls/objects are unsupported by Microsoft UI Automation:

  • Graph

  • InkEdit

  • InkPicture

  • Line

  • OLE

  • Oval

  • Rectangle

  • RibbonBar

  • RoundRectangle

  • RichTextEdit

  • WebBrowser

Table 2: DataWindow presentation styles supported by Microsoft UI Automation

CrossTab

FreeForm

Grid

Group

Label

N-Up

Tabular

TreeView


DataWindow controls of the following presentation styles are unsupported:

  • Graph

  • OLE 2.0

  • Composite

  • RichText

Table 3: Controls in DataWindow supported by Microsoft UI Automation

Button

Column (and the following edit styles are supported: CheckBox, DropDownListBox, DropDownDataWindow, Edit box, EditMask, and RadioButtons)

Computed Field

GroupBox

Text


The following controls in DataWindow are unsupported by Microsoft UI Automation:

  • Graph

  • InkPicture

  • Line

  • OLE Object

  • Oval

  • Rectangle

  • RoundRectangle

  • Picture

  • Report

  • TableBlob

Examples

To enable support for PowerBuilder controls/objects through Microsoft UI Automation, you will need to set the AccessibleName and AccessibleDescription properties in the controls' Property tab page. Note that AccessibleRole property is unsupported by Microsoft UI Automation.

The following statements set the AccessibleName and AccessibleDescription properties for a command button in a Window:

cb_1.accessiblename = "Delete"
cb_1.accessibledescription = "Deletes selected text"

The following statement sets the AccessibleName property of a button in a DataWindow object:

dw_1.Object.b_1.accessiblename = "Update"

Deployment

When you deploy an accessible application, you must deploy the pbacc.dll and PBAccessibility.dll files.

For more information

For more information, refer to the PowerBuilder VPATs report, and also the Microsoft general accessibility website at http://www.microsoft.com/enable. Also helpful is the WebAim website at http://www.webaim.org.

Microsoft Active Accessibility (MSAA)

PowerBuilder provides the infrastructure and properties needed to build accessibility features into your Windows and Web applications. Its features allow applications to conform generally to Microsoft Active Accessibility (MSAA) Version 2. MSAA is a Windows standard that defines the way accessibility aids obtain information about user interface elements and the way programs expose information to the aids.

PowerBuilder standard controls support all required Microsoft Active Accessibility properties as listed in the following table:

Microsoft Active Accessibility property

PowerBuilder property support

Name

objectname.AccessibleName

Some controls support the Name setting through the Text or Title property. For all controls, Name is customizable through the AccessibleName property.

Role

objectname.AccessibleRole

Customizable through the AccessibleRole property.

State

Default Active Accessibility support

Location

Default Active Accessibility support

Parent

Default Active Accessibility support

ChildCount

Default Active Accessibility support

Keyboard Shortcut

Default Active Accessibility support for "&" access key of the Text property

Also, PowerBuilder Accelerator property setting if applicable to the control.

DefaultAction

Default Active Accessibility support

(For example, a selected check box has a default action of uncheck.)

Value

Default Active Accessibility support

(For example, a selected check box has the value checked.)

Children

Default Active Accessibility support

(For example, items in a list box.)

Focus

Default Active Accessibility support

Selection

Default Active Accessibility support

Description

objectname.AccessibleDescription

Customizable through the AccessibleDescription property.

Help

Not supported

HelpTopic

Not supported


Visual controls

For PowerBuilder visual controls that inherit from DragObject, you can manipulate the IAccessible Name, Role, and Description properties of each control by using PowerBuilder dot notation or the Other page in the Properties view of the painters. You can also manipulate the IAccessible property KeyboardShortcut using PowerBuilder properties wherever the ampersand in text property and accelerator property are supported. Other IAccessible properties are set automatically using Active Accessibility default support. (For example, location is automatically updated with absolute screen coordinates for Windows controls at runtime.)

The following table lists PowerBuilder visual controls that inherit from DragObject and their default accessible roles:

PowerBuilder visual controls

AccessibleRole enumerated value

Animation

animationrole!

CheckBox

checkbuttonrole!

CommandButton

pushbuttonrole!

DataWindow

clientrole!

DropDownListBox

comboboxrole!

DropDownPictureListBox

comboboxrole!

EditMask

textrole!

Graph

diagramrole!

GroupBox

groupingrole!

HProgressBar, VProgressBar

progressbarrole!

HScrollBar, VScrollBar

scrollbarrole!

HTrackBar, VTrackBar

sliderrole!

ListBox

listrole!

ListView

listrole!

MonthCalendar

clientrole!

MultiLineEdit

textrole!

Picture

graphicrole!

PictureButton

pushbuttonrole!

PictureHyperLink

linkrole!

PictureListBox

listrole!

RadioButton

radiobuttonrole!

RichTextEdit

clientrole!

SingleLineEdit

textrole!

StaticHyperLink

linkrole!

StaticText

statictextrole!

Tab control

clientrole!

Tab page

clientrole!

TreeView

outlinerole!


The OLEControl control is set to pushbuttonrole! by default. You need to set this role depending on content.

DataWindow control

PowerBuilder implements the MSAA standard for the DataWindow custom control and its children.

The AccessibleName and AccessibleDescription properties take string values. The AccessibleRole property takes the value of the AccessibleRole enumerated variable.

There are some limitations regarding accessibility support in the DataWindow:

  • For the navigation function accNavigate, spatial navigation (navigation by keyboard based on screen location) is not supported. Logical navigation, where keyboard navigation follows a logical tab sequence, is supported only for columns in the detail band. Columns that have a tab value set to 0 so that users cannot update them cannot be accessed from the keyboard.

  • The Composite, Label, N-Up, OLE 2.0, and RichText DataWindow styles are not supported.

  • Support for OLE objects, OLE database columns, and nested reports in DataWindows is limited.

PowerBuilder cannot provide accessibility for control content. This must be provided by the control vendor.

Examples

The following statements set the IAccessible properties for a command button in a Window:

cb_1.accessiblename = "Delete"
cb_1.accessibledescription = "Deletes selected text"
cb_1.accessiblerole = pushbuttonrole!

The following statement sets the AccessibleName property of a button in a DataWindow object:

dw_1.Object.b_1.accessiblename = "Update"

The following statements set the AccessibleRole property for a button in a DataWindow object to 43 (the number associated with PushButtonRole!) and return the property to a string variable:

string ls_data
dw_1.Object.b_1.AccessibleRole = 43
ls_data = dw_1.Describe("b_1.AccessibleRole")

Deployment

When you deploy an accessible application, you must deploy the pbacc.dll file.

For more information

For more information, refer to the PowerBuilder VPATs report, and also the Microsoft general accessibility website at http://www.microsoft.com/enable. Also helpful is the WebAim website at http://www.webaim.org.

About VPATs

A Voluntary Product Accessibility Template (VPAT) is a table designed to help U.S. Federal officials make preliminary assessments of accessibility compliance for products offered to the government for sale. A VPAT lists the criteria for compliance with accessibility requirements for various types of products and provides columns where you can indicate and comment on how your product meets them.

VPATs are available for software applications and operating systems, Web-based Internet information and applications, and other types of products. Even if you do not need to fill out a VPAT, reviewing the template for your type of product can give you a clearer understanding of the requirements of Section 508 for software and Web applications.

To view the various VPATs, see the Information Technology Industry Council website at http://www.itic.org.

You should read PowerBuilder VPATs carefully and assess the applicability of any defects or exceptions listed for your particular application.

Testing product accessibility

The MSAA 2.0 Software Development Kit (SDK) includes several tools for verifying the MSAA compliance of your application. They include AccExplorer, Accessible Event Watcher, and Object Inspector. These tools are available on the Microsoft website at http://www.microsoft.com/en-us/download/default.aspx.

To test the user experience of your application for those with disabilities directly, you can use various methods. For example, try using a text-only browser; enter input using only the keyboard; use the application with a screen reader such as JAWS, Window-Eyes, Hal, or Supernova.

Several commercial applications are also available for testing Web sites for compliance with Section 508 and the WCAG 1.0.

For more information

For a checklist for testing WCAG 1.0 compliance, see the appendix to the WCAG 1.0 on the W3C website at http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/full-checklist. The W3C website also lists and evaluates tools for testing accessibility.