9 Accessible Development

How to Build Accessibility Into the Development Process

As with any fundamental design constraint, accessibility is best included – and tested – at every stage of development. Good accessibility does not happen by accident. Building on a foundation of good accessibility will guide design decisions throughout the development process, with resulting impacts on visual presentation (e.g., colour contrast and layout) and overall flow and operation (e.g., navigation and wayfinding).

Accessibility standards

It is important to understand digital accessibility standards and how they apply to the work that you are going to do (e.g., website development, updates, app development). In addition to understanding digital accessibility principles in general, be familiar with your institution’s accessibility standards. Being familiar with these will allow you to integrate them into your guidelines and your general development process.

Institutional standards often represent a minimum level of accessibility, sometimes based on legal requirements. Digital accessibility and related guidelines (like WCAG) are continuously updating, reflecting a continuous process of improving accessibility, and in reaction to advancements in technology and web content development. As a result, you may feel that it is practical and forward-thinking to design to a higher level of accessibility than what is represented in your institution’s accessibility standards. In any case, it is essential to establish specific success criteria for accessibility design at the earliest stages of development.

Accessibility throughout development

Accessible design is best planned, implemented, and tested at every level of design. We have taken a generally hierarchical design model, with component, integration (or sub-system), and system levels of design. Simpler systems might not have meaningful distinctions between these levels; larger projects might have more levels of hierarchy. The principles and concepts discussed here can broadly be applied to both simpler and larger projects.

Component Level

At the component level, any control presented to the user needs to be accessible to alternative forms of access. For example, a user needs to be able to use their keyboard to switch between controls, as well as to operate them, unless there is a just reason not to allow it (e.g., a resource testing mousing accuracy). Most standard User Interface (UI) libraries offer keyboard-only functionality, with the ability to Tab between fields, buttons, etc. and the use of the keyboard to select from options, enter text and so forth. If your application requires a new type of control, implement keyboard access as well to remain keyboard accessible.

WCAG offers several guidelines for alternative access to controls, both for reading content and interacting with it. Reading content can include reading the current value of a numerical slider, or alternative text descriptions for video, image, or audio content. Most accessibility standards also describe important criteria for interacting with a control (button, interactive graph, toggle, etc.), including consistent keyboard behaviour.

Integration or Sub-System Level

At the integration level (or subsystem level, or webpage level), accessible design planning includes the flow of focus between controls on the page, including tab order and the logical flow of text and controls.

• Flow of Focus: One consideration is how screen readers will interpret the flow of the page. Screen readers do their best to interpret screen content logically, but do not always get it right. As a result, test to ensure that the order in which elements are read (including alternative descriptions) are consistent with your design goals.
• Flow of Controls: Test flow of control and actions within a single page or subsystem too. Make finality clear to the user if irreversible actions can take place (for example, paying bills in a banking application). Where possible, present the user with a final summary of the transaction, and given the opportunity to accept, modify, or cancel the action.

At this level of development, consider navigation and waypoints. Make UI elements used to navigate the application (or webpages within a website) identifiable and navigable by alternative means such as keyboard access. Where possible, establish a consistent design so that similar actions function similarly throughout an application. This consistency will create a consistent “look and feel” for end users and increase overall usability.

System Level

At the system level, all the design elements and accessibility criteria work together cohesively to create a smooth, consistent user experience. For example, make waypoints implemented at the integration level consistent among all pages.

This level is the final check for success at the lower levels of integration. Navigation blocks should be universal among sub-systems (or webpages within a website) for easy wayfinding. This includes consistent wording, interaction, and placement. Ensure that there are no navigation dead-ends (a page that leads to no other pages) and that the flow between pages is understandable and predictable.