Preparation for application design

Designing for accessibility means understanding the specific needs of your application users to drive decisions about the experience that you want to create for them. You already have research on who your users are and how they use the application, and you are also aware of best practices in UX design. In the Prepare phase, you use this information to establish user personas. 

By using personas, you categorize users into convenient groups according to their work objectives, tasks, needs, attitudes, skill sets, and behavior. You derive personas from behavioral and work process research in your business organization.

Personas have the following features:

• You typically present them in a concise visual format to display the meaningful commonalities among each user group.  

• Personas are related to but not synonymous with user roles (for example, a customer service manager). A user role defines the best way to perform tasks. In contrast, a user persona creates a broader narrative to answer critical questions about the needs of a given user group to build user empathy, prioritize user needs, and align with business outcomes.   

When you design for accessibility, include a diverse set of personas. In this list, cover any personas that you identify in the Discover phase. Use personas to facilitate conversations with members of your project team. Personas bring these users to life as you explore how to best meet their needs. Some of your best ideas and innovations can come out of these discussions that benefit all users.

Providing multiple ways to access content is helpful to meet a variety of needs. In the following image, click the hotspot (+) icons to see examples of personas that represent users with different abilities and perspectives.   

After you select the user personas that you want your application to support, define your acceptance criteria for each task or workflow that you create. As a best practice, ensure that your acceptance criteria focus on the ability of users to comprehend the content and complete any tasks that they require. You can include your accessibility requirements in these acceptance criteria. Including your accessibility requirements as part of the non-functional requirements for your definition of done is a recommended approach. Non-functional requirements are part of the core system and are unrelated to specific tasks or behaviors.

With the basic accessibility principles of the World Wide Web Consortium (W3C), you can find various ways to meet the needs of all your users. W3C uses the POUR acronym to convey these principles: 

• Perceivable information and user interface

• Operable user interface and navigation

• Understandable information and user interface

• Robust content and reliable interpretation

Consider the following example of how to build the acceptance criteria for a specific task or workflow:

Persona

Ian is a recent college graduate. Born blind, Ian uses a screen reader to use the computer. He works for a state government office and handles license permits for hunting and fishing. Ian generally uses JAWS for work but prefers VoiceOver on his phone in his private time. He gets frustrated when forms have no labels because he makes mistakes in his filings. He also likes to quickly finish his work but web pages with poor navigation take him longer to use, so he needs more time to complete his work and leaves the office later.

User story 

As an agent for the Environmental Conservation Department who relies on the JAWS screen reader to access the automated licensing system for the state, I want to approve any fishing license applications that meet the basic requirements for a permit so that my customer can take his daughter fishing this spring, and our department can collect the related fees. 

Acceptance criteria 

• The user can complete the task by using keyboard-only, JAWS, or NVDA.

• The user can access all interactive elements on the page as well as the meaning of any icon or image. 

Non-functional requirements for the definition of done  

• All interactive items can receive focus, and focus is visible.

• All interactive items have an appropriate name, role, and state.

• All visible notifications are announced in ARIA-alert.

• All images have valid alternative text.

• All buttons, icons, and input fields have valid associated labels.

Check your knowledge with the following interaction: