Print this page


Lucy Greco

  Accessibility in Education

02/05/2014

How a Website Accessibility Review Works

Tell a Friend

Lucy Greco, Web Accessibility Expert at UC Berkeley, takes us through a typical web accessibility review process with her team of user experience experts and web developers.

Even a simple form can be a challenge if it’s not coded correctly for a screen reader user

Image: Even a simple form can be a challenge if it is not coded correctly for a screen reader user

The favorite part of my job is testing websites and applications for accessibility. I really enjoy sitting down with the developer to put their site or application to the test of a real screen reader user. This is extremely rewarding work because when developers see what problems a real person, has they begin to empathize and understand why accessibility is important. I find it critical that I test with the developers because it gives them a deeper understanding of what the problems are. However, lately I am finding too many problems that the developers can’t solve and it turns out that the assistive technology I use is the actual problem.

First, I think it’s important to explain what one of my typical accessibility reviews is like. Typically my user experience expert and I sit down with developers and other key people on the project. We always ask the project team to inform us who they think their users are and identify the key tasks they want people to perform on their project.

We begin one of our reviews by introducing a few key concepts for accessibility, such as how a screen reader works and a general understanding of what we would be looking for. Now the fun begins; we start by just reading the screen and letting everyone in the room hear what the blind person would hear the first time they visit the site or run the application.

I tend not to examine a project beforehand because I want the developers to witness my first encounter to a barrier in real time. This is not saying that I don’t pre-review some sites, but most of the time I like it to be as real and natural as possible. While we are listening to the page, my user experience (UX) person is already running through the source code and looking for any obvious problems within the code to point me toward. Once we discuss what we have heard, we review whether there are any problems that we all caught. Then it’s time to move on – now, the real work begins!

The first quick run-through will reveal very simple, easy-to-fix problems such as semantic structure of the page being incorrect (headings out of order) or unlabeled graphics, or unlabeled form fields. Once we have gotten these barriers out of the way, we start to work through a development task list. I am given a scenario that a typical user would have to perform on the site, and without assistance and instruction, try to complete that task and scenario, describing not only what I am doing but any problems I encounter, as I encounter them, and potential ways to fix these problems.

It’s astounding how even a simple form can be a challenge if it’s not coded correctly for a screen reader user. For example, if one form field populates other form fields, depending on the answer, can the screen reader get to the new fields or does it even know they exist? These reviews can be as long or short as the project owners like and we repeat them as frequently as we can to avoid introducing any new accessibility barriers. Development teams appreciate these reviews because it gives them a real grasp of how a user with a disability interacts with their site. We found that for many of the problems revealed by these reviews, when they are fixed, also generally makes the site easier to use for everyone.

***********************************************************************************************************************************************************************************************************

Related Resources

Blog: Web Accessibility Standards in Ontario: Looking Ahead | Read Robert Pearson's Article.

Publication: Web Accessibility for Better Business Results | Download the G3ict Report.

Event: G3ict ICT Accessibility Week India | February 13-21, 2014 | View Event Details.