TASB
Accessibility
0  /  100
keyboard_arrow_up
keyboard_arrow_down
keyboard_arrow_left
keyboard_arrow_right
TASB / Accessibility

TASB / Accessibility analysis

Start Reading

The challenge

The Texas Association of School Boards has a SaaS (Software as a Service) that manages all information related to the public school system of Texas. Due to state regulations, they needed to comply with the accessibility guidelines of the W3C. The system had been created without considering any accessibility parameters and with components of varying levels of technical complexity and usability issues.

Providing keyboard-triggered event handlers

We must make it possible to navigate the site without using a mouse, just using the keyboard.

Using semantic elements to mark up structure

Using the appropriate semantic elements will make sure the structure is available to the user agent. This involves explicitly indicating the role that different units have in understanding the meaning of the content.

Ensuring that users are not trapped in content

All pages but especially related to tables with many complex interactions, the calendar, tabbed divs , tables with filters and tables with nested information that appears collapsed.

Tabbed tables and tables with collapsible rows problem

In tables with collapsible rows, the user cannot see the information of the collapsed rows until they click on the row and the information is displayed, which is cumbersome and takes many steps for the user who navigates only with the keyboard.

Complex interactions

In this case it is even more complicated both for blind users who navigate only with the keyboard and for users who navigate with non-conventional devices where they must move the cursor with their mouth, head movements or by voice commands.

Calendar for managing non-school days issue

The user must go through each of the filters and define the parameters, the calendar is particularly complex from an accessibility point of view.

It was a system where implementing many of the accessibility guidelines was particularly challenging because the system had components and workflows that were very complex to use, even for people without any disabilities.

Team, role & responsabilities

1 Accessibility consultant / 1 PO / 1 Dev

As an accessibility consultant, I was responsible for examining the required modifications in the Front-End of the system to adhere to the W3C guidelines. I converted the findings into documents to be reviewed with the Product Owner and the developer to establish the feasibility of the solutions and the development timelines.

  1. My role: Reviewing the Front-End code of the entire system to identify and document adherence or non-adherence to the W3C WCAG 2.1 Level A - AA guidelines. Then, accompanying the developer in the implementation and subsequent validation of the changes using tools recommended by the W3C.
  2. My responsabilities:
    • Analyze the Front-End code to identify the changes to be implemented.
    • Conduct validation testing of the Front-End code and CSS of the system.
    • Explain to stakeholders and the client how to work with the W3C guidelines and discuss the feasibility of implementing each level.
    • Analyze the interface regarding colors, font sizes, and other visual factors to identify accessibility errors.
    • Propose solutions to the identified problems using my HTML/CSS knowledge for implementation by the developer.
    • Accompany and validate the changes made by the developer.
    • Ensure that the changes are correctly implemented by verifying them with tools recommended by the W3C.
    • Ensure that once all adjustments are made, the system complies with the W3C WCAG 2.1 Level A - AA guidelines and passes validation tests.
  3. Team work methodology: Once the analysis was completed, I created an accessibility checklist document and shared it with the Product Owner and the Developer. We then had several meetings to define priorities, importance, and the effort required for the different issues identified. During implementation, I reviewed the developer's work and clarified any doubts about the implementation of certain guidelines. I also validated the screens as they were completed using W3C tools until all screens and flows of the system were addressed.

    There were certain particularly complex accessibility issues. In those cases, I conducted three additional presentations, explaining in detail the problems we faced and the proposed solutions, as they involved more than just code changes or corrections.

Process

Analysis of the Front-End code and validation of compliance with the W3C WCAG 2.1 Level A - AA guidelines.

I began the code review process to understand the extent to which we complied or did not comply with the regulations. I estimated approximately what percentage of compliance we had and got a high-level overview of what we were dealing with.

Both the client and our stakeholders were not very clear on the different levels of accessibility and the Web Content Accessibility Guidelines (WCAG). My recommendation was to aim for level AA accessibility, as it covers the majority of cases. Level AAA is so strict and complicated to implement that achieving 100% compliance in the current system, and in almost any system, was nearly impossible.
I recommended using WCAG 2.1 as it was the most comprehensive and well-established set of guidelines at the time. However, it's worth noting that a new version, WCAG 2.2 was launched in October 2023.

Accessibility checklist

While analyzing the Front-End code of the system, I was populating the accessibility checklist with the description of the problem, the guideline it was violating, the scope within the system (whether it applied to the entire system or just to a specific screen, section, or flow), and lastly, the solution that needed to be implemented according to the W3C guidelines.

I added additional descriptions to the document about the purpose and the reason why certain adjustments were important. I did this because the client and our stakeholders needed to understand in clearer language how these adjustments impacted the experience of users with disabilities.

Live doc

Review of the most critical points

While conducting the analysis, I noticed that there were extremely complex issues that couldn't be solved with code modifications alone. Therefore, I created presentations to showcase to both internal and external stakeholders what the problems were and the potential solutions for these issues.

Calendar for managing non-school days problem

The problem with the calendar was that there are many actions in different parts of the page and the user navigating through the keyboard would have to change the focus many times to execute the actions and in some cases it is not possible to execute the action because of the complexity of the task flows.

Problem of complex tables with advanced filters for blind users

Users who navigate only with the keyboard should have a way to configure the table filters to display the information they are looking for through the keyboard by changing the cursor focus just by pressing the TAB key several times until reaching all the controls and information on the page.

Tabbed tables and tables with collapsible rows problem

The problem with tabbed tables is that the tab has to be selected and then click on it to display the information which is not possible only with the keyboard and in the case of tables with collapsible rows is that the user cannot see the information of the collapsed rows as long as he does not click on the row and the information is displayed, which is cumbersome and takes many steps for the user who navigates only with the keyboard.

Outcomes & results

Front-end code error correction

Over 800 accessibility errors were found, the majority of which were easy to correct.

Correction of critical errors by creating an alternative and 100% accessible version

The most critical errors were related to task flows hindered by components or poor accessibility programming practices. These issues couldn't be simply corrected by changing a few lines of code; they required a redesign with accessibility in mind. However, due to the complexity of the processes, while the redesigned version greatly improved usability for users with disabilities, it resulted in a worsened experience for users navigating the system traditionally. For this reason, the decision was made to maintain the current version of the system for typical users and create a separate version that utilized the same databases but presented information in an accessible and user-friendly manner for users with special needs.

Removal of videos from the system

One of the challenges we faced was with the help videos in the system. To comply with regulations, audio descriptions of dialogues and actions within the videos needed to be recorded so that blind users could understand the actions and events depicted in the video. Additionally, subtitles needed to be created for users with hearing impairments or who are deaf, so they could understand the content being explained in the videos. In the end, the decision was made to remove the videos because the effort required was considerable. This task was postponed for a subsequent iteration of the platform.