When I came to Jackson National Life as a Web Development Intern, my first task was to fully evaluate Jackson’s site for accessibility issues, and to present that information to the Web Accessibility Committee for review. The Committee was made up of individuals from across the organization, including developers, designers, attorneys, and corporate communicators. Indicating accessibility issues, their relevancy, and their level of importance to these different parties was a communication puzzle.
The start of this evaluation process actually reflected much of what I did at my previous job for Usability/Accessibility Research and Consulting. This involved creating batches of pages to evaluate, and then going over lists of requirements to test them. While some accessibility indicators can be tested for (e.g. alt tags on images, names and roles on interactive elements, etc.) others care more contextual and need a human eye to determine whether they are necessary in the current situation.
For example, the WCAG guidelines state that all images should have an alt tag. However, understanding when to actually fill in that alt tag, and what to write in it, is much more contextual. If an image is decorative, we’ll leave the alt tag blank. If an image is fully described in the surrounding text, we might also leave the alt tag blank. However, if we insert an image of a graph, we will need to explain all of the information that this graph conveys via alternative text. This isn’t always in the form on an alt tag, but it can be. (If you’re interested in learning more about image alternative text, take a look at WebAIM’s article on alternative text.)
Because accessibility evaluations can depend heavily on context, for most of this evaluation I went through every page on Jackson’s site and checked against the WCAG 2.0 criteria, as well as section 508 standards. I did this using a simplified version of the WCAG 2.0 AA and Section 508 guidelines that was organized into a checklist-like structure. I broke up pages into batches based on their purpose, and evaluated them in sections this way, as many of the elements on these related pages overlapped and so did their accessibility issues. This was a long process, and probably took around a month to complete (and about 90% of my brainpower during that time). However, once complete we had a huge set of data points to work with.
The next challenge was to adapt those data points into something useful for Jackson’s developers and the Web Accessibility Committee. We wanted to convey the importance of every issue we found to the Committee in order to get approval to work to fix each one. We were concerned that if some issues were presented as more important than others, we wouldn’t get approval to make the site completely accessible, which was the Web Development team’s goal.
The accessibility issues found were tracked in a spreadsheet, and each described the issue and listed the pages the issue affected. From here, we needed to understand how to represent an overview of the issues found to the Committee. I worked together with the Web Development AVP in order to understand what information the Committee would best understand, and what would be most important to them. Together, we determined that our Committee would be most interested in the accessibility issues that affected a large percentage of pages, and that we needed to include empathy in our overview of the analysis to make our purpose clear.
We wanted to include empathy in the overview because although we were working to protect Jackson legally, the best way we could gain support for the accessibility movement was to show that these issues affect users negatively on a regular basis. To do this, I decided to present to the Committee a description of the problems that these accessibility issues could cause for users.
We presented this data to the Committee using the above spreadsheet, talking through the issues, the affects they would have on users, and the pages that they affected. All of these points were taken into consideration when deciding how to tackle the changes that needed to be made to Jackson’s site. Ultimately, the presentation convinced the Committee that all of these changes should be made to the site.
The spreadsheet now needed to be adapted for the developers to use when remediating the site. Again, I took a look at the issues and where they stemmed from, and used this information to suggest pathways to the developers that I worked with. We could either attempt to remediate all of the accessibility issues on a page at once, or we could tackle the project by grouping accessibility issues based on functionality, and then working to fix the same kind of problems at the same time.
It would have been very satisfying to be able to check off an entire page at a time and say, “We’re done!” However, we decided to group issues by functionality and then fix them this way for a couple of reasons:
I created batches of issues based on the functional problem we had discovered, and listed the pages that they affected. For example, we found problems with the forms and input elements on the site, so we created a batch that listed the pages, issues, and completion dates for the issues that affected forms. These were issues like form errors not being read out by the screen reader, or a user changing an input value causing the content on the page to change unexpectedly.
This format actually worked very well for the developers and for the Committee to track progress. We could report on the batches that had been completed, which gave an idea of how far into the project we were, and could also show on which dates the issues for each page had been fixed.
I’m currently still working with Jackson to improve their sites and products, and have to say they have made amazing progress thus far. I can’t wait to see what this team will accomplish in the future.
This project gave me great experience understanding not only how to evaluate a large site for accessibility issues, but also understanding how to communicate those problems to persons outside of development. I was able to gather, organize, and present information in a way that attorneys, developers, designers, and communicators could all make sense of, and allowed these individuals to make a decision about enabling accessibility within their organization.
Although the focus of this project was to protect Jackson preemptively, it was also important to consider the affect that these issues have on users, and to get the Committee and developers to empathize with these struggles.
Finally, I also got a great understanding of how to organize an accessibility project of large scale, and how to communicate with the stakeholders of that project. We were able to find a way to effectively communicate and share progress on a project that was very technical in nature. I think this is probably our biggest success, because it’s opened up new discussions with other areas of the organization to talk about accessibility and the progress we’ve made.