Working to meet the accessibility standard

When we meet with new client's we've never worked with before and we start to talk about accessibility - it's often the first time they've put any thought into it. They understand it's one of the government's Digital Service Standards and they are almost always completely onboard with it.

But how to meet the standard can feel like a bit of a grey area and the route to get from point A (designing and building a digital service) to point B (launching an accessible service to the public) has many twists and turns. And once the digital service is live - how can we make sure it stays compliant? It's not always easy to keep up with updates to WCAG criteria staff are continuously updating content and making changes to improve the user experience.

In this post we'll look at:

• an overview of how to get from point A to point B;
• stories project teams have shared that helped uncover some of these issues; and
• some of the strategies teams have employed to make sure digital services remain compliant.

Getting from point A to point B

Teams we've worked with have employed a variety of strategies to make sure their digital services and websites are accessibility compliant and meet the government's current accessibility level. 

Using platforms that meet accessibility levels

All of the government's common platforms for public-facing digital services meet the accessibility criteria. In cases where teams use a Commercial Off The Shelf (COTS) product, we've built this requirement into the procurement process to ensure teams are starting from a good place.

Planning and testing for accessibility

For teams working to design, develop and launch digital services, we conduct UX Assessments throughout the service delivery process. Part of these assessments help us work with teams to ensure they have a plan for testing (real people, automated testing or both), they've executed their plan and the result before launch is they have a fully compliant service.

Common accessibility issues and how they were uncovered

Heading tags not in the correct order or missing and missing alt text on images

For one project a colleague who used their mobile device and screenreader volunteered to help with testing. This provided the team with incredible insights. They observed first hand how a person processes information. For example, they had selected the heading tags based on how they looked visually on the page - they did not use them in the correct sequence so when the screen reader was parsing the page content - it was essentially jumping all over the place and it made no sense. 

The other issue they came across was they had forgotten to add alternative text to the images on the page. When the participant came across the images it took them extra time to try and figure out what they were and how they related to the rest of the content on the page. They were annoyed because they felt like they could be missing important information, but couldn't tell what it was.

Members of the team who participated in the session as observers had a list of improvements they wanted to make before the session was over. 

Ensuring targets are large enough for tapping

In one instance we visited a user in their home. This person was a senior and they contacted us to let us know they were having trouble accessing a digital service on their computer. They lived near our office so rather than email back and forth, we thought it would be easier to see first-hand where they were getting stuck so we could help them faster. 

When we got there they showed us their computer and the first surprise was that it was actually an iPad. As they were walking us through the steps they took, one of the observations we made was that the person was finding it challenging to tap on some of the links. Part of the reason for this was their hand shook a bit, but we could also see the links were much too small a target for people on mobile devices to tap on.

Too much information on one page

One of my colleagues reached out to a local organization to see if they thought any of their clients might want to participate in testing a digital service. They had some interest and my colleague visited them on site for an afternoon. Now it's never easy to use a digital service when someone is sitting with you taking notes, but one of the unexpected takeaways from this testing was that a few participants struggled with the volume of content on the page. They used words like "overwhelming" and "I'm not sure where to start" or "I'm not sure where to go." The team he had worked with wanted to add a bunch of information so they were fully transparent, but it actually made it hard for people to understand and process. In my UX words - they had inadvertently added to the user's cognitive load. 

This gave the team a chance to take a step back. They removed content that wasn't needed, made sure the reading grade level was between 6 and 9 and they spread the service out over multiple steps starting with the easiest questions first. 

Colour contrast and colour blindness

Another team we worked with had a very robust accessibility testing plan. They were relying on automated tools. As they looked at the site through a variety of colour blindness filters it became apparent they needed to adjust the colours because it was challenging to see the differences in button prominence. 

We recently came across a similar scenario where we found the spacing around text links in a footer had met compliance when the website launched. Of course as WCAG criteria have changed over the years - we found the spacing was no longer compliant and we're in the process of addressing it now. 

They also identified a few places where the colour contract between the background and foreground was nowhere near where it needed to be. So they were able to make those changes before they launched the digital service. 

Strategies for maintaining accessibility compliance

For really large digital services like Yukon.ca, we use a tool called Siteimprove to continuously track and report on accessibility compliance. This tool assesses Yukon.ca's accessibility compliance compared to a benchmark of how well other government websites are doing. Teams look at this data quarterly at a minimum and they are constantly addressing compliance issues as they come up. Earlier this year the government's WCAG compliance level was updated to 2.2 AA so there is a dip in compliance the team has been working away at.

User feedback is also a helpful tool. If someone comes across an accessibility-related issue they can report it to the team and we'll run testing and make sure it's addressed. 

So Yukon.ca uses a combination of methods to ensure accessibility compliance. 

Other digital services require periodic testing. This is mostly conducted by the department teams that manage the services and they use a variety of automated testing tools to accomplish this. We also revisit digital services when they decide to conduct an additional phase of work and this is another good oppiortunity to assess where things are at and make improvements. 

It's a never-ending job, but we love doing it. 

How do you work with your team to tackle accessibility? What recruitment methods do you use? What automated tools do you find work well? Let us know in the comments or email [email protected].