General Accessibility for DevelopersOverviewWelcome 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:
WelcomeIt 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:
DefinitionsThere 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:
Programmatic AccessProgrammatic 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:
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?
SAMPLE 2: (Image of OK button)
Accessibility APIsWhen 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:
- A support or run-time dynamic-link library. Accessible API CommunicationUIA 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
CONTROL 2: Text - "An investment in knowledge pays the best interest" --Benjamin Franklin
Logical Hierarchy BasicsRegardless 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:
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 HierarchyTake 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:
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 HierarchyThe container for your product and all the other UI elements within it should be mapped out in the logical hierarchy as follows:
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:
Mapping Child ElementsOnce 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:
Full Logical HierarchyAfter completing an inventory of Product X, the logical hierarchy would look like this:
Keyboard NavigationYou 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:
Considering NavigationIf 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:
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 FocusThe 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:
High DPIWriting 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:
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 ContrastHigh 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 ConsiderationsThere are two additional accessibility considerations that you need to think through when developing your product. These are color and sound. Color 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. Sound 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. ControlsAfter 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.
Tools and ResourcesNow 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 CompletionCongratulations, 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:
|
