Project Overview
As part of my role at Learnovate Centre, Trinity College Dublin, I worked as a UX Designer at Akari Software's design team. I was tasked with improving the software’s accessibility.
Company
Company
Akari Software provides curriculum management software as a service (SaaS) to universities, helping them streamline and manage their academic programs efficiently by offering robust, user-friendly tools.
Context & My Role
Context & My Role
Given that the company provides essential services to educational institutions, accessibility is paramount. My role was to ensure our software met the upcoming legislative requirements, remained competitive by becoming fully accessible, and was user-friendly for all university stakeholders.
I designed a detailed company-wide resource for all WCAG 2.2 accessibility criteria, identified existing accessibility issues in the main software and other services through testing and visual inspection, designing solutions and supporting the further testing as well as implementation. Additionally, I created Accessibility Conformance Reports using the latest Voluntary Product Accessibility Template (VPAT®).
Research
To thoroughly understand the accessibility challenges within the company and software, I initiated a comprehensive research phase.
Objectives:
1. Gathering insights from various teams across the company to identify the current process
2. Identifying the areas for improvement within the software
Collaborative Discussions within the Company: Gathering Insights
In a series of discussions with key teams—QA, Software Engineering (SE), Customer Success, and the Design team—valuable insights into accessibility challenges were shared. Each team had a unique perspective on accessibility challenges, and these collaborative discussions were essential for uncovering specific pain points related to understanding and implementing the WCAG guidelines.
Through these conversations, it became evident that all teams were facing difficulties in interpreting and applying WCAG criteria. The discussions revealed several common issues with the WCAG guidelines:
Complexity: The technical language and detailed criteria of WCAG are hard to comprehend and apply without specialised knowledge.
Navigation: The abundance of links and fragmented information makes it difficult to find relevant guidelines quickly.
Practicality: The manual is highly theoretical. There is a need for more practical, example-driven guidance to illustrate how to implement the criteria effectively.
Integration: Each team first wants to understand the criteria, and then looks for specific information such as information on how to test for QA, and how to implement for SE and design team. Finding such specific information in the document is time-consuming. Teams struggle with integrating the guidelines into their workflows due to a lack of clear, actionable steps.
Here is a video I created to highlight the complexity of one of the 86 WCAG criteria and its challenges for the teams. It illustrates the intricate and technical nature of the guidelines, emphasising the need for simplified and actionable guidance.
Defining the Problem
After analysing the research insights, I clearly defined the problem hindering the progress towards achieving accessibility:
"The complexity of WCAG guidelines, combined with fragmented information and few practical examples, makes it difficult for teams to understand and apply accessibility standards, causing inefficiencies and unclear guidance."
Designing the Solution: A Simplified and Actionable Guideline
As a result of the insights from research, I designed a Simplified and Actionable Guideline to address the difficulties teams faced with the WCAG 2.2 criteria. This guideline was designed to be more user-friendly and practical, focusing on clear, actionable steps rather than complex technical language.
Key Features of the New Guideline
Simplified Language
Clear, straightforward explanations of each criterion to make them more accessible to all team members.
Clear, straightforward explanations of each criterion to make them more accessible to all team members.
Structured Format
I organised content into 6 sections that provide teams easy navigation to quickly find relevant information without being overwhelmed by excessive links:
I organised content into 6 sections that provide teams easy navigation to quickly find relevant information without being overwhelmed by excessive links:
1. Definition from the Original Guideline: I aimed to minimise the need to switch between documents.
2. What it actually means in the practice: Simple explanation of what this criterion means and impact on users.
3. How to comply: What needs to be added into the system.
4. How to test: Testing tools, manual/automatic test step-by-step.
5. Anything special: Things to be careful about specifically, software specific information.
6. Examples
Practical Examples: Real-world examples and best practices illustrating how to effectively implement each criterion.
Example for 2.4.3 (A) Focus Order criterion
Example for 2.4.1 (A) Bypass Blocks
Actionable Steps: Step-by-step instructions to guide teams through the test and implementation process, ensuring consistency and effectiveness.
Easy Access: I aimed to simplify the access and navigation further by creating the manual on Confluence, a software used by all teams on a daily-basis.
All testing tools in one place: I included a page where all the most current testing tools can be found. I made sure that all necessary resources are readily available, aiming to reduce the time spent searching for tools and improving efficiency in evaluating accessibility.
Impact of the New Accessibility Guideline and Progress
At the annual company meeting, we presented the new accessibility guideline on Confluence, and the feedback from all teams was overwhelmingly positive. The clear and practical nature of the guideline has made it an essential resource for everyone involved in accessibility efforts. Since its introduction, it has significantly improved understanding and implementation across teams, becoming a key tool in ensuring consistent and effective application of accessibility standards.
Advancing Accessibility
While testing and implementation are ongoing, I continue researching the areas for improvement in accessibility. For example, WCAG 2.2 does not specifically address disabled buttons. My ongoing research focuses on identifying and implementing inclusive design solutions to bridge these gaps and ensure comprehensive compliance with accessibility standards.
Reporting Accessibility
To communicate our commitment to accessibility to stakeholders, including clients and regulatory bodies that our software meets the highest standards of inclusivity, I have also created VPAT (Voluntary Product Accessibility Template) reports to document our software's accessibility conformance. This process involves a detailed evaluation and testing of our platform against WCAG 2.2 accessibility standards, and systematically recording our compliance status. Throughout this process, the new guideline has proven invaluable for quickly understanding the criteria and efficiently evaluating the software.
