Skip to main content

General Accessibility for Developers


Welcome to the Accessibility Training: General Accessibility for Developers course. As a developer, you are responsible for implementing accessible solutions and a little work up front on your part goes a long way towards integrated, accessible code in the final product. This course is tailored to help meet your needs as a developer and will give you specific tools and skills to create more accessible, user-friendly products.

As a result of this course you will be able to:

  • Identify development issues you may encounter when creating accessible products early in the product lifecycle
  • Develop a logical hierarchy for your product


It takes skillful planning and execution to create products that are flexible and accommodating to a variety of peoples’ needs. Developers play an integral part in meeting those needs by creating accessible products.

This course is organized to help you locate information quickly when you need it and is laid out in the following manner:

  • Programmatic Access
    • API Information
    • Creating a Logical Hierarchy
  • Keyboard Navigation
  • System Settings
  • Controls


There are a number of terms used in this course related to assistive technology (AT) and the APIs. Take a moment to understand what each of the following terms mean:

  • Clients - Accessibility or test automation tools that use an accessibility API to programmatically access application user interfaces.
  • Providers - Applications that implement an accessibility API for their UIs. Providers are referred to as "servers" in MSAA because its role appears as a component object model (COM) server of IAccessible.
  • Assistive Technology Vendor (ATV) - An independent software vendor that develops and ships accessibility tools such as a screen reader or magnifier.
  • Logical Hierarchy - A systematic mapping of the product's navigation for programmatic access that a user of AT would use to navigate a UI. It is also used to determine where keyboard focus is required and assists in planning for code implementation.

Programmatic Access

Programmatic access involves ensuring all user interface (UI) elements are exposed programmatically to the AT. Without it, the application programming interfaces (APIs) for Assistive Technology (AT) cannot interpret information correctly. This leaves the user unable to use the products sufficiently or force AT to use undocumented programming interfaces or techniques never intended to be used as an "accessibility" interface. When UI elements are correctly exposed to an AT, it is able to determine what actions and options are available to the user. Without proper programmatic access, a user may receive useless or erroneous, or even no information about what they are doing in the program.

Programmatic access is achieved when an application or library of UI functionality exposes the content, interactions, context, and semantics of the UI via a discoverable and publicly documented API that can be used by another program to provide an augmentative, automated, or alternate user interaction. Basic information conveyed through programmatic access includes:

  • Navigation
  • Interactive elements
  • Asynchronous changes to the page
  • Keyboard focus
  • Other important information about the user interface

Users of AT often miss critical information when programmatic access is done incorrectly. You can read the code samples below to see how programmatic access affects end user experiences.

SAMPLE 1: What is your favorite city?

  • <SPAN>What is your favorite city? </SPAN><INPUT id="Text1" name="txt2" size=”20”>
  • Incorrect. This editable text field does not have the sentence before it set as a label. A user would not know what this text field should contain, and navigation might not go from question to text field if not coded correctly.
  • <LABEL for="txt1">What is your favorite city? </LABEL><INPUT id="Text2" name="txt1">
  • Correct! This editable text field has the sentence before it set as a label. As a result, the user would know what this text field should contain, and navigation moves from question to text field correctly.

SAMPLE 2: (Image of OK button)

  • HTML: <button class="button"></button>
  • CSS: .button { background:url('OkButton.png') no-repeat top left; border-style:none; width:81px; height:26px; }
  • Incorrect. This button uses an image for the button. Since the "OK" text is in the image, the user does not receive its name or know what the button does.
  • HTML: <button class="button">OK</button>
  • CSS: .button { background:url('OkButton.png') no-repeat top left; border-style:none; width:81px; height:26px; }
  • Correct! This button labels the button using text, rather than embedding the name in an image. In the case of images, the user does not receive its name or know what the button does if text is in the image rather than coded as text.

Accessibility APIs

When coding your products, ensure good programmatic access by exposing the appropriate events and properties to the AT by using either UI Automation (UIA) or Microsoft Active Accessibility (MSAA). Each API offers information to users that allows them to interact with applications using alternative interfaces. What is the difference, and why are there two API’s? The following overviews of each will help you understand the different ways they provide information.

UIA Basics

In 2005, Microsoft released a new accessibility framework called UI Automation (UIA). In UIA, a core service lies between the server (called a provider) and the client. The core service makes calls to the interfaces implemented by providers and offers additional services, such as generating unique runtime identifiers for elements. Client applications use library functions to call the UIA service.

MSAA Basics

In 1997, Microsoft released its first version of MSAA, which is a COM-based API used by AT products. MSAA consists of the following components:

  • IAccessible
    A COM interface that exposes information about user interface (UI) elements. IAccessible also has properties and methods for obtaining information about and manipulating those elements.
  • WinEventsAn event system that allows servers to notify clients when an accessible object changes.
  • Oleacc.dll

- A support or run-time dynamic-link library.

Accessible API Communication

UIA providers can supply information to MSAA clients, and MSAA servers can also provide information to UIA client applications. Because MSAA does not expose as much information as UIA, the two models are not fully compatible. A proxy/bridge is used to fill in this gap.

What Information Is Conveyed by Each API?

Understand the difference in information conveyed by each API. Discover what a user of AT would receive for each of the controls shown below:

CONTROL 1: Slider Bar

MSAA InformationUIA Information
  • Role: Slider
  • Value: 22 (Only the current Value)
  • Pattern: RangeValue
  • Current Value: 22
  • Minimum Value: 1
  • Maximum Value: 50

CONTROL 2: Text - "An investment in knowledge pays the best interest" --Benjamin Franklin

MSAA InformationUIA Information

Role: Text

  • Value: "An investment in knowledge pays the best interest" --Benjamin Franklin (single Value for the entire text)

Pattern: Text

Powerful range navigation:

  • For the entire text
  • By word, line, or paragraph
  • Text attributes (font, color, italic, etc.)
  • Text selection

Logical Hierarchy Basics

Regardless of which API you use, you will want to create a logical hierarchy to plan the navigation of your application.

Creating logical hierarchies requires close examination of the product and thinking carefully about how a user would navigate logically through the UI, whether they can see it or not. You can use this inventory of your UI as a blueprint for building your application. The following questions will help you start thinking about information that will be needed in the logical hierarchy:

  • Could you list the items from the UI in the order a user would navigate through them?
  • What would be important for you to know about the items in the UI if you were trying to navigate the page without seeing it? For example, what functionality do controls offer?
  • Which items would you expect to receive keyboard focus in the list so that users can interact and fire events?

A user of assistive technology needs to know that these questions have been addressed in the navigation of the page so that they can quickly and confidently use the product.

Creating a Logical Hierarchy

Take inventory of your UI, and use it to create a logical hierarchy for the product. This logical hierarchy is a basic way to ensure inclusion of all items for your product in the MSAA or UI Automation (UIA) Tree for your users.

Product X

In this section, we will use Product eXample (Product X), an application that allows people to track their stock values, to create a logical hierarchy. Product X relays a number of important items to users, including:

  • stock trading price tracked over days, months, or years
  • earnings announcements for the company
  • news related to Wall Street
  • news related to the company

The product also allows users to access the news information from a list of information and links below the chart. Links at the bottom provide the user a way to navigate to web sites related to stocks, and the OK button takes them out of the product.

Beginning the Hierarchy

The container for your product and all the other UI elements within it should be mapped out in the logical hierarchy as follows:

  • Begin by listing the basic items and controls on the UI. Do not worry about any smaller items within controls (child elements) yet.
  • List items in the order you would logically navigate to them on the screen. For example, in English-speaking countries, navigation is usually left to right and top to bottom

Localization-Be aware of the specifics of the language and navigation standards for the users of your product and create the logical hierarchy appropriately. Product X is in English, so the navigation will begin at the top. Please visit MSDNfor assistance with localization issues.

Product X

Here is what the first level of the logical hierarchy for Product X looks like:

  • Text: "Review Company Stock Information…"
  • Text: "Stock Info Program Details…"
  • Link: How to Use Stock Information Chart
  • Text: "View by"
  • Link: Days
  • Link: Weeks
  • Datagrid: Stock Graph
  • Text: "Information for Date"
  • List: Articles
  • Link: Select New Stock
  • Link: Search Stocks Online
  • Link: Get Online Stock Advice
  • Button: OK

Mapping Child Elements

Once the first level of the logical hierarchy is complete, you will repeat this process for items within each control, where applicable, until all levels of child elements are mapped for each control.

Using the Product X data grid as an example, the following items would be child elements of the data grid control:

  • Scroll bar (left)
  • Grid item (dated column)
  • Graphic (stock price chart)
  • Graphic (dollar symbol indicator)
  • Graphic (circle symbol indicator)
  • Graphic (triangle symbol indicator)
  • Multiple instances of the grid item (dated column) and children
  • Scroll bar (right)

Full Logical Hierarchy

After completing an inventory of Product X, the logical hierarchy would look like this:

  • Text: "Review Company Stock Information…"
  • Text: "Stock Info Program Details…"
  • Link: How to Use Stock Information Chart
  • Text: "View by"
  • Link: Days
  • Link: Weeks
  • Datagrid: Stock Graph
    • Scroll bar (left)
    • Grid item (dated column)
      • Graphic (stock price chart)
      • Graphic (dollar symbol indicator)
      • Graphic (circle symbol indicator)
      • Graphic (triangle symbol indicator)
    • Additional instances of the grid item (dated column) and children
    • Scroll bar (right)
  • Text: "Information for Date"
  • List: Articles
    • Header: Source, Summary, Date, Action
    • Group: "Wall Street News"
      • List Item: Wall Street News
      • Text: Name of article
      • Link: Article link
    • Group: "Company News"
      • List Item: Company News
      • Text: Name of article
      • Link: Article link
    • Group: "Earning Announcements"
      • List Item: Earning Announcements
      • Text: Name of article
      • Link: Article link
  • Link: Select New Stock
  • Link: Search Stocks Online
  • Link: Get Online Stock Advice
  • Button: OK

Keyboard Navigation

You will also want to plan for effective keyboard interactions in your product. It is difficult to rework the keyboard navigation once the product development begins, so plan carefully and plan early.

There are three components to navigation:

  • Creating a logical hierarchy (which was just addressed in the Creating a Logical Hierarchy section of this course)
  • Considering keyboard navigation
  • Determining keyboard focus

Considering Navigation

If you take the time to map out navigation plans for your product, it will be easier to make accessible decisions when the coding begins. Important questions to ask yourself about the application:

  • How are the elements laid out in the UI?
  • Are there a few significant groups of elements that may need to be navigated to and within?
    • If yes, do those groups contain another level of groups?
  • Among peer elements, should navigation be done by tabbing around, via special navigation (such as up, down, left, or right arrow keys), or both?
  • Which items should receive focus, and how will non-text items be labeled in order to provide the best experience for users?
  • Are all applications navigable using only a keyboard? Tab order and shortcut keys should all be provided in the spec.

Additional Information for Keyboard Navigation

For more information about planning keyboard navigation on the MSDN website, see the Windows User Experience Interaction Guidelines, and the Guidelines for Keyboard User Interface Design.

Keyboard Focus

The completed logical hierarchy will allow the user to identify items on the page and understand what they might be able to do with them; however, users will not need to click to fire events on all of the elements on the hierarchy. Only those items that will require user interaction in order to function should be given keyboard focus. Which items in the product need keyboard focus?

Answer: The items that need to receive keyboard focus in order for the user to fire events are:

  • Links: The user must be able to activate a link by clicking with the mouse or pressing a button.
  • Scroll bars: The user needs to be able to scroll for additional information from other dates.
  • Grid Items: The user must be able to select the date they are interested in reviewing.
  • Buttons: The user needs to be able to press the button either by clicking with the mouse or pressing a button.

High DPI

Writing a dpi-aware application is the key to making a UI look consistently good across a wide variety of different DPI settings. An application that is not dpi-aware but is running on a high DPI display setting can suffer from many visual artifacts, including:

  • Incorrect scaling of UI elements
  • Clipped text
  • Blurry images

By adding support in your application for dpi-awareness, you guarantee that the presentation of your application's UI is more predictable, making it more visually appealing to users. As more manufacturers ship greater numbers of high-resolution displays, the default 96 dpi setting can no longer be assumed by applications.

High Contrast

High contrast mode must remove flashing animations and remove or reduce transition animations. It should also be set to omit non-functional images, gradients or patterns behind text. Be sure not to hard-code colors and have alternative color icons available for high-contrast setting users. When creating applications, be sure to adhere to the high contrast standards.

Other Considerations

There are two additional accessibility considerations that you need to think through when developing your product. These are color and sound.


Avoid relying on color alone to convey information in the UI. Different icons or use of words will help users with visual impairments get the information they need. Additionally text and background color contrasts need to meet at least a 4.5:1 color contrast ratio. Remember to keep color choices appropriate for users with colorblindness.


Provide closed captioning or visual notifications for sounds used in applications. Users with hearing impairments or computers that do not have sound available will need alternate notifications such as these.


After creating a logical hierarchy and noting where keyboard focus should be created within it, it’s time to make decisions about the controls you will use or create for your application.

As you will learn in each individual framework’s course, using controls provided by the framework greatly reduces the cost of implementing the accessibility requirements discussed so far. Inversely, creating custom controls is extremely expensive and will require you to implement all of the accessibility yourself.

Take note of which common controls in your framework can be leveraged and which items in the product will require you to make custom controls. Using your logical hierarchy as a guide, you can then create a chart using the information below for the implementation your controls. In this case, a framework that uses UI Automation is used.

Logical Hierarchy ItemNameAutomation ID



UIA Pattern, Properties, Methods & EventsFramework Control
Identify each unique element from the logical hierarchyCreate a Name for the element that will be disclosed to AT usersChoose a unique identifying name or string for the elementDetermine which UIA ControlType is needed, or if custom control note any applicable ControlTypes to be implementedFor each control, determine the appropriate patterns, properties, methods and events neededNote which common control is to be used in your Framework, or any related controls if custom

Tools and Resources

Now that you’ve learned more about developing accessible products and services, you may want to explore the subject further. Here are some online resources you might find helpful.

Course Completion

Congratulations, you have completed the General Accessibility for Developers course.

You now have an increased understanding on how to plan and assess the costs for creating accessible applications, using a logical hierarchy. You can also see the benefits of including accessibility into your product development cycle in a programmatic way to enhance the development process. Further courses are available on how to write accessible code and address platform-specific issues for accessibility. You can also consult the Microsoft Accessibility developer portal on MSDN for more information.

The courses in the Accessibility Training for Developers include:

  1. Introduction to Accessibility
  2. General Accessibility for Developers
  3. Windows (Win 32) Accessibility for Developers
  4. WinForms Accessibility for Developers
  5. WPF Accessibility for Developers
  6. Silverlight Accessibility for Developers