Furst Person
Accessibility
0  /  100
keyboard_arrow_up
keyboard_arrow_down
keyboard_arrow_left
keyboard_arrow_right
Furst Person / Accessibility

Furst Person / Accessibility analysis

Start Reading

The challenge

After months of joint work between Product and Development, when the system was nearly finalized, the client requested an accessibility analysis because they needed the system to comply with W3C's WCAG 2 accessibility guidelines.

Contrast and navigation adjustments without a mouse

The color contrast to meet the standards was low; we had to review all colors using online tools to validate compliance with the standard, additionally, we had to correct the code to facilitate navigation without a mouse.

Keyboard trap

If the user wanted to navigate to the content area using only the keyboard, they couldn't; they could only navigate to the sidebar and header.

Info and Relationships

The area/line chart has a vertical and horizontal value range that does not comply with the standard.
We had to add a table with the same results as alternative content that is not visible in the front-end and is only used in case of screen readers.

Use of Color

The contrast ratio of several graphs and texts does not meet the minimum requirement. The area/line chart is only visualized using colors/textures.
We had to add a table with the same results as alternative content that is not visible in the front-end and is only used in case of screen readers.

Compliance with the regulations would have been much easier if we had conducted these validations from the beginning. However, they are additional processes that take more time and are only carried out if the client requires them, as they increase development costs.

Team, role & responsabilities

1 Accessibility consultant / 1 PO / 1 TL / 1 Dev

As an accessibility consultant, my task was to analyze the changes necessary to comply with the W3C guidelines, communicate these changes to the Product Owner (PO) and Team Lead (TL), and ensure that they were implemented by the developer.

  1. My role: I was responsible for identifying all adjustments, changes, or improvements necessary to comply with the W3C WCAG 2.1 Level A - AA guidelines
  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 initial analysis was completed and the information was compiled into an accessibility document, I reviewed the priority and feasibility with stakeholders and the Developer. I accompanied the Developer during implementation, validating the screens with W3C tools as they were corrected, until the entire system was fixed.

Process

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

I began the process of reviewing the code to understand the extent to which we complied with the regulations, estimate approximately what percentage of compliance we had, and gain a high-level overview of what we were facing.

Both our stakeholders and the client's stakeholders were unclear about 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. Achieving level AAA compliance is so strict and complicated that it's nearly impossible to implement 100% in the current system, and in most systems overall.
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

The next step was to create a document where I meticulously identified which specific guidelines the system fails to meet and which ones it complies with. In addition to listing the identified problems, I also added the solutions that should be implemented by the developers.

In addition to identifying specific accessibility issues in this document, there are also code-level solutions provided. With this document, developers could estimate the impact, feasibility, and implementation time of the solutions.

Live doc

Color analysis

I created another document containing contrast tests conducted using online tools recommended by the W3C. This document indicated the necessary changes to comply with regulations regarding colors and contrast for people with visual impairments or conditions.

Outcomes & results

Correction of all Front-End errors found

With the Accessibility checklist, developers were able to implement the necessary adjustments and changes to comply with the regulations and pass the tests for level AA accessibility.

Correction of sensory issues and color deficiencies

All color and visual presentation issues that made reading difficult for people with different levels of visual impairment or who navigated the system using alternative methods such as screen readers or keyboard-only navigation without mouse assistance were corrected.

More info about this project