Accessibility is a journey

Joseph Talbot (User Interface Team Lead) spoke to Chloé Ashbell and the IT Services Accessibility Champions Network about how the Teaching Management System (TMS) implementation reminded him of the importance of each user journey and that implementing digital accessibility never really ends. 

What is TMS? 

The Teaching Management System is for academic and administrative staff involved in undergraduate teaching in colleges and departments. The system allows tutors and students to view teaching arrangements, record and track teaching hours, provide easy access to tuition reports and much more. 

When TMS was originally implemented, did you consider accessibility? 

One of the aims of TMS was to provide an easier experience for all types of users, which is why the project was keen to involve me early in the project. In fact, it was probably my first experience at the University of being involved almost full-time on a single project.  

Along with the Testing team, I advocated for accessibility throughout the project. The team ensured that along with light-touch internal accessibility testing, we organised an external audit by the digital accessibility professionals AbilityNet who have an accessibility framework agreement with the University. To ensure compliance with The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 (PSBAR), we also published an accessibility statement using government templates and the University of Oxford web accessibility guidance. However, soon after the system went live we discovered that there is always more to do when it comes to accessibility! 

What made you realise that making a system accessible is a never-ending goal? 

Shortly after go-live we were contacted by a tutor about the challenges they had entering rich text into one TMS field. The tutor suffered with repetitive strain injury (RSI) and as a result used Dragon, a speech to text software, that allowed them to complete tutorial reports in TMS to provide feedback to students using just their voice. Dictating content into the rich text fields prevented the tutor from exacerbating their painful condition. 

The field in question was a ‘What You See Is What You Get’ field allowing users to enter rich text, i.e. text with formatting and styling. The field used a standard CKeditor plugin that is readily available online, but the tutor was finding it difficult to get Dragon to focus on this field, meaning they weren’t able to complete their tutorial reports. The plugin is used by lots of systems, so we had presumed it would be compatible with well-known assistive technologies, such as Dragon. 

Diagnosing the cause of the issue was challenging; firstly, we do not readily have Dragon licences available to us and secondly, as with many assistive technologies, Dragon can be heavily customised to suit an individual’s preferences. We knew that we needed specialist assistance from AbilityNet to help us understand the problem further. It transpired that although the field was technically accessible, it did not work with this user’s setup. It was technically possible to focus on the field in question, but that didn’t match our user’s workflow nor reflect how they used their assistive technology. An accessible field does not always make for an inclusive and useable experience! By understanding how the tutor used their assistive technology we were able to make some small changes to the mark-up and labelling of the field allowing the user to use the system as intended.  

It sounds like that accessibility issue was really niche; how do you think you could have picked up that issue during development? 

It was definitely an edge case and shows how even comprehensive accessibility testing cannot pick up every issue. It was a great example of how it is easy to make a system compliant with accessibility standards and yet still have users encounter difficulties. Only when we engaged with the user’s feedback to understand exactly how they were using TMS could we truly make an inclusive system. It also shows that it’s almost impossible to make a system that is 100% accessible - instead we must constantly strive to improve our systems in an iterative way that improves both accessibility and usability. 

In terms of how we as a project could have potentially identified the issue sooner, I suspect part of the problem was that the overall user experience for TMS was complicated. Users were expected to click through several screens to complete tasks resulting in higher cognitive load. Inevitably, this had the biggest impact and challenges on our users with accessibility preferences and needs. By the time users reached this rich text field, their frustration levels were high, and it is likely that those using assistive technology would be less able to try different methods of accessing the problem field. 

In hindsight, at the earlier stages of the project we probably needed to push back and spend time simplifying and harmonising the business processes. TMS was always going to be a complicated system as we were trying to combine processes that varied between colleges and departments and accommodate them all in one single system. Perhaps if we’d re-evaluated those processes, we could have created a simpler user interface and that would have given an improved (and less cognitively challenging) user experience for all our users, not just those with accessibility needs. 

What accessibility advice do you have for other projects and services? 

I think there is still so much for us to learn when it comes to our approach to digital accessibility; as a department and university we’re still immature in our practices, as was evidenced in the recent Digital Transformation Programme Accessibility Review. However, I think there are themes we should consider in our delivery of services and projects: 

• Accessibility requires advocacy - There are many competing considerations in a project, accessibility won’t just happen; it is vital that any project team has someone to advocate for accessibility. The advocate doesn’t need to be an expert on accessibility, however they do need to have a voice within the project as well as a general understanding of the challenges different users face when using the product. 

• Less is more (likely to be accessible) - Simplicity is key to accessibility, every action and decision the user makes to complete a task adds complexity and the likelihood of encountering an unintentional barrier increases.

In the case of TMS, there were complexities baked in which made it difficult to create an accessible system. The system that TMS was commissioned to replace (OxCort) was designed with college tutorials in mind. The scope of TMS was broadened to include management of all Oxford teaching. 

There was significant variation in processes and workflows across department and colleges which were not addressed prior to starting the project. This led to parallel paths and processes in the system, thus pushing complexity on to the user in the form of more actions and decision making. Simplifying and clearly articulating business processes as much as possible beforehand will reduce the risk of accessibility issues.  

• User Engagement - Engaging with end users more and using quality as a measure of success during a project, rather than just the money and time taken to deliver the system, is vital to providing a good user experience. We need to get screens in front of users from the very beginning of projects, even if they’re mock-ups so that we can understand their challenges and frustrations before we start developing. During delivery we need to be iterative and get our users testing at every stage. 

• Accessibility is a journey, not a destination - Making a product 100% accessible is an unrealistic goal in all but the smallest of projects. Instead, we should: 
  • strive to make the product as accessible as possible on release, using a risk-based prioritisation of design and testing effort (for example, the tutor comments field was a both a key field and unusually complex, so should have been tested by assistive technology users prior to release) 
  • 

    establish an accessibility roadmap to improve the accessibility of the product 

  • provide guidance to users on known accessibility issues and particular details of the system which may be helpful to certain users (e.g., structure of search result listing)  

I think it’s about understanding that there is always more to do when it comes to accessibility and usability; there is always further room for improvement.  

Education is key 

There needs to be strong accessibility knowledge within the development team. It is preferable that everyone involved in building front-end components has a strong understanding of web accessibility considerations. Relying on specialist front-end developers or accessibility consultants can mitigate a lack of accessibility knowledge, but this makes the process less streamlined, adds to cost, risks re-work and is less resilient. Education of developers in front-end good practice in general - and accessibility specifically - is the way forward. 

There is a need for a central repository of accessibility knowledge and we as individuals also need to take responsibility for educating ourselves about accessibility. We won’t be perfect, and that’s ok; edge cases are always going to fall through the cracks, but we can limit their impact by building accessibility in from the beginning.