The Problem
Our app is built for use by the US federal government and must meet or exceed the guidelines laid out for Level AA compliance testing with WCAG 2.0. Several challenges informed the process:
- The site is in a transition of being modernized and has a mix of older and newer coding standards.
- The app development team does not have training in accessibility.
- The release schedule is full each quarter and set by the client’s priorities.
My Goals for Success
My objective is to ensure that the entire team is on the same page about the standards and requirements and provide leadership around implementation.
Research
I began with an audit of each page in current development using the WAVE Web Accessibility Evaluation Tool. The main errors identified were:
- Missing alternative text
- Missing form labels
- Language is missing
- Empty buttons
- Empty links
- Very low contrast
The modernized pages contained a few accessibility errors in repeated components. There were extensive contrast errors throughout the entire design system. Both were flagged as a high priority, as they will affect every page of the site.
The legacy pages contained many accessibility errors, some of which may potentially affect the functionality of those pages. These pages will be modernized in the future but are receiving modifications at the moment. Balancing the client’s immediate needs alongside the long-term needs for modernization and accessibility is paramount.
I coordinated with the developers to understand their background and experience with accessibility practices and with our product manager to discuss priorities.
Generate Solutions
Prioritize
A primary challenge was navigating the feasibility of changes during the current release cycle. The goal is to correct all accessibility errors without delaying the delivery of the requested software changes. We prioritized these changes as low-impact, high feasibility:
- Missing alternative text
- Language is missing
- Empty buttons
- Empty links
Many of the legacy pages are rich forms with many inputs and complex layouts. With that complexity in mind, these errors were identified as high-impact, low feasibility in most areas:
- Missing form labels
- Very low contrast
Design Solutions
To facilitate several of the necessary changes, new CSS classes were needed with guidance around implementation. I designed documentation around ways to hide content for all, hide visually but remain visible to assistive technology, or remain visible but hide from assistive technology.
1. Hide for All
Using display: none in CSS hides elements from everyone, both visually and non-visually via screen readers. This is appropriate when an element needs to be truly hidden in all instances. An example would be temporarily hiding a functionality that the client may want to restore later. Use CSS class hidden:
.hidden {display:none;}2. Hide Visually
Using the clip method hides content visually but it remains available for screen readers to access in the natural flow of the code. An example would be a label on the search field. Visually users can understand that it is a search field, but the text label needs to be present for non-visual users to understand the purpose of the field.
Another example is an icon button. One experience of this button is seeing it as a circle with an icon. Another experience is hearing the computer read what the button does. Visually presented with only an icon, the button must still contain text describing the button’s functionality for screen readers.
<button class="button-primary circle" type="button">
<i class="button-icon fal fa-search" aria-hidden="true"></i>
<span class="button-label hidden-view">Search this Site</span>
</button>Use CSS class :
.hidden-view {
border: 0;
clip: rect(0 0 0 0);
height: 1px;
margin: -1px;
overflow: hidden;
padding: 0;
position: absolute;
width: 1px;
}3. Hide from Assistive Technology
The aria-hidden attribute hides content from assistive technology but does not visually hide it. For example, a button that displays visually with both an icon and text label would hide the icon for screen readers:
<button class="button-primary">
<i class="button-icon fal fa-search" aria-hidden="true"></i>
<span class="button-label">Primary</span>
</button>Delivery & Implementation
To move these issues forward for implementation I did the following:
- Provided a live overview of the 508 guidelines and the criteria for web accessibility (perceivable, operable, understandable, robust) to the app developers.
- Created a repository of accessibility documentation with explanations on purpose and implementation.
- Created a developer accessibility checklist that outlines the seven things a developer should check around specific HTML elements.
- Provided guidance on how to use an automated accessibility checker, WAVE.
- Created change requests with specified solutions for the accessibility errors identified and flagged as feasible within the current release cycle.
Conclusions
Accessibility is about developing solutions that meet the needs of all users, with and without disabilities. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive abilities.
Throughout this process, I learned how to better collaborate and communicate the larger principles of accessibility in concrete and actionable terms. Leading accessibility efforts requires a close relationship between design and development to ensure that solutions consider all users and deliver functionality to all users. The primary goal is to get everyone on the same page about what’s to be built and why.
Process Improvement
A major improvement was around the company’s processes, which previously did not include accessibility. I was able to implement process improvements during design, development, and testing to ensure that all future development appropriately addresses accessibility errors.
Evolving a Living Application
These are ongoing efforts to improve a living and evolving application while also maintaining timelines and delivering new functionality to the client. While it would be great to redesign the entire app from the ground up and ensure everything is built to the highest accessibility standards, that is rarely a feasible option. Our goal is still to be in complete Level AA compliance and we have the groundwork to reach that goal.