Getting started with accessibility

Traditionally, verifying that an application complies with accessibility standards was something that happened at the end of the development process. It was part of the pre-release testing process and was completed before an application would receive approval to be launched in production. This is not the most effective way of creating accessible applications, and the Government of Canada’s Digital Standards recommend a different approach to creating accessible products. 

Open

Government of Canada Digital Standards 

The Government of Canada’s Digital Standards form the foundation of the government’s shift to becoming more agile, open, and user-focused. These standards state that “Accessibility must be monitored and built into our processes to continually align with accessibility standards. Accessibility should be a constant part of iterating and improving frequently and designing with users, throughout the design of the service.” For more information on the Government of Canada Digital Standards, see Government of Canada Digital Standards - Canada.ca. 

Build in accessibility from the start

Building in accessibility from the start ensures that previously implemented pages and components do not need to be reworked later for accessibility issues. Regular accessibility testing throughout the product development process is also important as accessibility issues are less costly to fix if they are found early. 

Some accessibility issues can be fixed once. For example, if you have a session timeout length that is too short, you can change this once for your application. However, most accessibility issues will need to be fixed on every page, or in every component where they appear, so the larger your application grows before starting this process the more difficult and costly it will become.

Getting started

The following is a list of tips on how to get started with accessibility on your project: 

Tip #1 – Identify existing accessibility issues 

With existing work, a good first step is to identify issues with what you already have.  

End-to-end accessibility testing involves going through the application and testing components, features, pages and flows against accessibility standards like the Web Content Accessibility Guidelines (WCAG) and can also include testing with assistive technologies like screen readers or some browser extensions. For more information on accessibility testing tools and resources, see Accessibility resources.

Once testing has been completed, any issues found can be added to your product backlog and prioritized. 

Tip #2 – Prioritize accessibility issues 

Addressing a backlog of accessibility issues can be intimidating. This blog post contains good tips on how to prioritize accessibility issues Setting priorities for accessibility issues - Intuit Developer Community Blog.  

Another approach is to begin with the areas of the application or website that are the most frequently used. Having analytics set up can help identify these areas and features. 

As a UX researcher, you can also leverage the insights gathered during user research. The knowledge you have of your users can help you prioritize the accessibility issues that impact them the most. 

Tip #3 – Communicate the impact 

The Web Content Accessibility Guidelines (WCAG) Understanding Documents provide detailed explanations of each WCAG criterion. They briefly explain the goal of the criterion as well as why it is important. They also include an “Intent” section, which often describes who the criterion helps and some typical use cases. Highlighting these personas can be a good way to communicate the impact of accessibility issues using non-technical language. 

Tip #4 – Build empathy 

Including a diverse range of users in research and usability testing is a great way of learning about accessibility challenges directly from the people who are using your product. One of the behaviours described in the Government of Canada Digital Standards that aligns with the principle of building in accessibility from the start is, “Our team conducts ongoing research with users with low-level digital literacy, people with disabilities, and people from different cultural and linguistic backgrounds.” Inviting your team or project stakeholders to participate in these sessions can be an effective way of building empathy with disabled users. 

Tip #5 – Share responsibility 

When talking about building accessible applications, a lot of responsibility tends to fall on the development team. Proper, semantic HTML is a big component to creating an accessible web application, but it is not the only one. Accessibility issues can also originate during the design process. 

Literacy of accessibility and WCAG across the team is valuable because you can create a culture of shared responsibility. If these skills are currently missing on your team, there are great courses and webinars on the Accessibility training & education page of the UX Enablement space. This page also lists some conferences you could attend as a team. 

Tip #6 – Prevent future accessibility issues 

One of the behaviours described in the Government of Canada Digital Standards that misaligns with the principle of building in accessibility from the start is, “Accessibility compliance is added at the end of the development cycle in order to pass compliance checks or audits.” Now that you have identified the existing accessibility issues in your application and resolved them, it is important to incorporate accessibility requirements into your team’s workflow so that you maintain this standard of quality.  

A good way of doing this is to use a checklist, like the one provided here Accessibility review . You can also include these items in your team’s definition of done. For more information on creating a definition of done, see Definition of Done - Agile Wiki - Confluence (atlassian.net).

Tip #7 – Ask for help 

There are several members of the UX community who have skills and experience in accessibility and would be happy to provide help or support. You can reach the MAACE UX community through the UX and Service Design channel on Teams. 

Open