Developing inclusivity in Canvas

The IT Services Accessibility Champions Network spoke to Natalie Burrows and Rob Leung from the 2021/22 Inclusive Teaching Enhancements (ITE) project. They told us how they embedded digital accessibility into their ways of working, resulting in an improved experience for staff and students when using Canvas.   

Tell us a little about the Inclusive Teaching Enhancements (ITE) project and Canvas? 

Canvas is Oxford University’s supported Virtual Learning Environment (VLE) which is used by most  of Oxford’s students. It’s been around for several years now and is where students access their course materials, formative assignments and notes  shared by their lecturers.  

The ITE project aimed to provide students with disabilities and specific needs better access to more equal teaching and learning  by minimising barriers that hinder learning and participation such as long-standing illnesses or health conditions, deafness or serious hearing issues, blindness or serious visual impairment, serious mental health conditions, and more.

What prompted the Canvas team to consider accessibility? 

On previous Canvas projects, the team discovered that the ‘out-of-the-box' platform was not fully compliant with the Web Content Accessibility Guidelines (WCAG) 2.1 which are the agreed international standards for accessibility.  It was clear that improvements were needed.  As a public body, the University is required to adhere to the UK’s Public Sector Bodies (Website and Mobile Applications) Accessibility Regulations 2018, which means that all our online applications need to be  compliant and include a published accessibility statement. As a private company, the supplier was not required to meet the same level of digital accessibility compliance meaning that we needed to do the work ourselves.  It didn’t help that number of customisations had also been added to Canvas when it was originally released at Oxford. 

Even though the Testing Team had helped identify issues at the end of a previous Canvas project, we realised that assessing accessibility as an afterthought was not cost effective or efficient, and we needed to take a different approach in the ITE project.  

How did you approach the accessibility requirements? 

When we started, it felt like a challenge; everyone in the project team was relatively inexperienced when it came to accessibility, so we were all in the same boat. We agreed that we would all attempt it with our best endeavours and embrace picking up a new professional skill along the way.  

Firstly, everyone in the project team watched the IT Learning Centre (ITLC) digital accessibility webinars relevant to their roles, so we all had a common baseline of basic knowledge. Next, we agreed how we would fit accessibility into the project development lifecycle.   

It took us a while to get started, but quickly became manageable. We incorporated accessibility into our Agile project’s ‘definition of done’: all items had to meet WCAG 2.1 success criteria to be delivered and it was the responsibility of the whole team, not just the developers or testers. 

On other projects it was hard to implement accessibility retrospectively but building it in as the project progressed was much more manageable. Sometimes making a feature accessible requires a little more work. But it doesn’t need to be too costly or time-consuming and is more achievable when built into technical decisions and embedded throughout the project. 

So you developed with WCAG 2.1 in mind and tested as you went along? 

Yes, every new feature or bug fix was developed against WCAG 2.1 and tested accordingly. This meant that all the items we delivered during each sprint or iteration would be accessible and compliant.  

We also used the University’s approved supplier AbilityNet to do a more detailed audit during the project; this gave us confidence that we were doing the right things.  The feedback also helped us build accessibility into our business as usual (BAU) processes. The project team learnt that accessibility is never really ‘done’ and is something you must continually monitor as you iterate, much in the same way you consider performance impact when making code changes. 

What were the key challenges you faced in embedding accessibility? 

It can sometimes be difficult to tie in accessibility with the feature you’re trying to implement. We had to weigh up what functionality we wanted to deliver versus making it accessible -the two don’t always go hand in hand so it can be hard to find the right balance. You don’t want an accessibility requirement to result in reduced functionality for all users; you need to take a risk-based approach in those scenarios and weigh up the impact of accessibility vs functionality.  

We also struggled with some of the lower severity accessibility issues found in the original tool. This is going to be an on-going challenge, but as more higher education Institutions are audited by the UK Government, I am sure suppliers will face increased lobbying to address accessibility issues or miss out in a competitive market. In the meantime, we have a clear list of known issues which are included in our accessibility statement, so our users can find out about known limitations.  

Was it difficult to write the accessibility statement? 

Our platform, Canvas, already had an accessibility statement, but we needed to write our own to cover our customisations and to ensure that the statement met the The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations (PSBAR) 2018 legislation. We found templates online, such as the gov.uk sample accessibility statement, and then used our own testing and third-party audit findings to write our Canvas accessibility statement; it wasn’t a particularly onerous task once we started.  

What advice would you give other projects or services hoping to improve their applications’ accessibility? 

Starting can feel hard, but imperfect action is better than nothing. Get some free basic training using ITLC’s webinars, then agree as a project team how you’re going to make an accessible solution and make a start.  

You don’t need to understand in great detail how to achieve accessibility; while it’s important to have a general understanding, sometimes you need to call in the experts just like you do for other requirements, e.g., security or performance. We found great comfort in asking for our work to be checked. While in-house accessibility expertise is useful, for such a prominent user-facing application engaging a specialist company such as AbilityNet for an audit was definitely money well spent and gave us peace of mind.  

Another tip is the importance of getting buy-in from your project board. We were fortunate that the whole purpose of the project was to enhance inclusivity, and accessibility was therefore an easy sell, but that might not always be the case. I think it’s important to articulate that while digital accessibility is a compliance activity, and therefore must be done, it’s not just a tick-box exercise. Good accessibility helps improve usability for all users and that adds real business value to your product or service. It’s also about taking a risk assessment: what is the impact if we don’t make an accessible application? Lay out the benefits clearly and set expectations with both the project board and the delivery team.  

Is there anything you wish you’d done differently, or any resources you think your project would have found useful when embedding digital accessibility? 

The ITE2 project is already underway, and we aren’t significantly changing our approach to digital accessibility; we’re going to use the same approach of embedding it as we go and looking for novel ways to improve inclusivity across Oxford.   

We are asking disabled users to participate in our user acceptance testing (UAT) so that we can get practical feedback; WCAG compliance doesn’t necessarily mean the system is accessible for your specific users or solve the real problems they face. It is important that you understand your users, know their specific needs and gather feedback to understand their struggles. For disabled users with assistive technology, we need to provide them with an interface which allows them to be independent, irrespective of their technical skill level.  

We’re also engaging with AbilityNet again, but this time it might be more for custom consultancy than formal auditing - we found it very reassuring and helpful to pick their brains and ask them about the consequences of not addressing specific accessibility bugs. Understanding the real impact on end users helps us prioritise accordingly and helps the project team build empathy for our users. When you understand why, for example, you need to label a text field in a certain way and the consequences for a blind student of not doing that, it makes it easier to make judgement calls.  

Longer term it would be helpful to have clear departmental guidelines on how to approach digital accessibility consistently across projects and to hear what has worked well for other project teams.

Have you had feedback on the work you’ve done? 

During the scoping phase for the follow-up project, ITE2, we reached out to the Disability Advisory Service, and they confirmed low numbers of accessibility issues reported on Canvas, which was really positive and has reassured us that we have been taking the right approach to improving digital accessibility.