a11y Monthly: Testing for Accessibility, or my journey

In my previous monthly post, I’ve shared a few tips and tools for accessibility testing for beginners. In this post, I’d like to tell you when I was a complete beginner myself, and how starting to test for accessibility helped me to be a better professional. Not surprisingly, my first impact with assistive technologies wasn’t easy. In the end, it changed the way I think of web development, code, and semantics. I hope it can help you too.

How I started testing for accessibility

Many, many years ago I was working on a big project: the corporate website of an important public administration office. The website had to be accessible, according to the local regulations. The team I was working with brought in some accessibility specialist consultancy. They gave us some good feedback, reports, and action plans. After that, I was nominated the person in charge of the accessibility plan. I had the responsibility to coordinate the development and continuously test the accessibility improvements introduced in the project.

I was a complete beginner and I had no idea what to do.

At that time, there was no awareness about web standards and accessibility. Using tables for layout purposes was pretty standard. When a website “worked” visually, it was considered a good job. No one, or very few, cared about semantics, support for assistive technologies and so on.

Luckily, there was already a lot of proper documentation around. The first version of the W3C Web Content Accessibility Guidelines was published a few years before, in May 1999. I did my homework and started learning.

Starting off

With the little accessibility knowledge, I was able to get in a few weeks, I started testing actively. Some accessibility things are straightforward to check and even as a complete beginner I was able to do my job. For example: checking the images alt attributes, or ensuring color contrast was sufficient. I guess those are the things every beginner can understand with ease and focus on.

At some point, it became evident that wasn’t enough. Yes, there were some tools to help with accessibility testing, but what about the real user experience? How to check the overall accessibility level of the project in real use case scenarios? Today, when budget allows it, usability and accessibility testing are a common practice. The web industry has evolved and there are companies specialized in user testing. At that time, there weren’t so many. Not to mention our project didn’t have a dedicated budget.

So I installed a screen reader for the first time.

My first journey using a screen reader

It was puzzling.

When a screen reader runs, it starts reading all the content of a web page automatically. Having the screen reader firing off that vast amount of words to me was shocking. I wasn’t even able to understand what the screen reader was reading out. – Wait a minute, what’s going on? – I was thinking in my head – Why is it reading the site title so many times? How can I stop this thing? Help!

Yes, the first thing I learned was how to interrupt the screen reader speech. My gut reaction was: how it is even possible that a web page that visually looks OK, where everything seems to make sense, instead it’s so messy when read out by a screen reader? Many years after, I now know that’s what assistive technologies users experience the most.

I also realized that, as a sighted person, I had a significant advantage: I was able to look at the page and see what the screen reader was reading out. So I decided to take a step further and switch off my computer monitor. Tried again with the screen reader on the same test web page I knew like the back of my hand. The same avalanche of words. I wasn’t even able to find the information I was looking for, even if I perfectly knew where that section was placed on the page.

Screen readers read what we tell them to read

In a first moment, I was tempted to blame the technology. “These screen readers don’t work so well!” was a perfect excuse. Of course, in the following days, I soon realized screen readers just read out what we, as developers, put in our web pages. All that amount of meaningless words and disorganized information I was hearing announced by the screen reader was just the way we coded our web pages. It was our responsibility, and we weren’t doing a good job.

I managed to get a bit more proficient with the screen reader and things started to be a bit clearer to me. However, I soon realized what the most common virtue assistive technologies users must rely on when using the Web:

Patience.

Those days were an eye-opener experience for me. As a web professional, I felt uncomfortable in delivering such low-quality experience to our users. Web standards and semantics were already discussed at a scale at that time, but we rarely realize how important something is until the moment we need it. Web standards and semantics may appear abstract and academic topics to many, but they do have fundamental importance in the way we organize and deliver our communication on the Web. And on the web, we communicate through code.

Machine readability

The ultimate goal of any website or application is about communication. We want to communicate something to our users, or we want to empower users to communicate. To do so, we use a vast range of technologies and programming languages, in a process that we simply call “design”.

“Designing for users” is a mantra in the web industry. Everybody knows, or has heard at least once, about “user-centered design”. I’d argue “designing for humans” sounds better to me and I also extremely appreciate new approaches and theories about universal design or inclusive design and the like.

However, there seems to be something missing. We need to design for machines too. We need to learn how to craft our communication in a way that is understandable by machines and software as well. That’s the only effective way to make our communication perceivable by people who use those machines. This is precisely the point where standards and semantics come into play.

I’m happy to work at Yoast, where this concept is obvious and our products are designed to be used by people and by machines (i.e., the ones that want to rank our websites). I’m not so sure this same concept is shared in the design and development community yet. After all, it’s nothing new. On the web, everything we design is first interpreted by browsers and operating systems before it reaches the users. In a way, we already design for machines. But we need to take this a step further and understand that many people use additional software. We need to design for this software as well, whether it’s a screen reader, a speech recognition software, etc. In this regard, accessibility is certainly part of the design process and I’m confident more and more people will start taking this into serious consideration.

What can you do to improve things?

Start testing with accessibility software yourself. Even using a screen reader just a few times can help you understand what the main usability and accessibility barriers in your product are. If you use a Mac, the screen reader VoiceOver is built in, and all you have to do is press Cmd F5 to activate it. On Windows, you can use the excellent NVDA, free and open source. On Linux, you can use Orca.

Even better: test with people who use assistive technologies. Recently, I read an excellent post by the UK Government Digital Service where they tell how they’ve experienced testing with real users of assistive technologies can be a quick and effective way of identifying issues that affect all users. I couldn’t have said that better myself.

I can’t count the number of times I’ve discovered bugs or noticed possible enhancements thanks to a screen reader. The simple fact they can read out what is invisible to our eyes makes them a perfect debugging tool. Remember: when they appear to behave crazily, it’s not because they don’t work well, but in most of the cases it’s because our code is messy.

More importantly, testing for accessibility has led me to increase my knowledge of the existing specifications, best practices, browsers and accessibility APIs interactions, web design basics, and countless other topics that should be in every web professional’s toolbox today.

Want to help?

At Yoast, accessibility matters. We know it’s a process and we’re continuously improving, testing, iterating, and developing. We’re always open to feedback and contributions. Please do not hesitate to let us hear your voice. Please report any issues or potential improvements you notice in our products.

Read more: Web content accessibility at Yoast »