I assumed that it was not that important, would be a lot of work, and would only benefit a small portion of our target audience. I now stand corrected on all three assumptions.
If this sounds familiar, keep on reading. I’ll tell you a bit about my quest and help you on your way.
Thirty days of accessibility testing
This all started out by Ministry of Testing’s ‘30 days of accessibility testing’: 30 daily assignments aimed at learning both the ‘why’ and the ‘how’ of accessibility.
The first days of the challenge focus on the ‘why’. I think the most important lesson I learned was to let go of my mental image of a ‘disabled person’ being this blind guy or deaf woman.
We are all impaired one way or the other, and impairments can even be temporary or environment-specific. For example, you’re impaired when you can’t see your screen very well because of sunlight, or when you need to zoom in on an application to make it visible to the audience during a presentation. So, these improvements will not only benefit my prototypical ‘blind guy’, but they will benefit each of us in one way or the other.
The biggest misconception about accessibility is that by adding it you're doing somebody a favor. You're not, you're doing your job. - James Williamson
Learning how to make our application more accessible
After learning the basics, I figured that I would benefit more from doing an actual accessibility course so I could see how much effort would be involved and what needed to be done for our application. My guess was that if it would be easy to adhere to a set of standards, I could get my team onboard on this too. But if it would imply rewriting all of our code and investing a lot of energy, I’d have to go a different route.
I chose to do the (free) accessibility course that Google provides on Udacity. The course will take you only a few hours, so it’s a very good investment of your time. As expected, a few quite minor changes to our code would already provide a lot of benefit to our users. For example, our images frequently had no ALT-tag. So screen readers would happily start reading the filename out loud. The simple fix was to provide empty ALT-tags for images that have no significance on the page, and to provide a descriptive ALT-tag where useful. The rule of thumb being: ‘would you mention this image if you described this page to a friend?’.
Another example was making the site keyboard-only accessible by improving the order of focussed elements and clearly indicating which element has focus. This not only benefits impaired users, but also our power users that prefer to operate their computer by keyboard instead of mouse.
Getting the team onboard
After gaining some basic knowledge myself, my second challenge was to get my team on board. Like me, they’ve spent most of their careers quietly ignoring accessibility. So it seemed like I might have a hard time to convince them to change their ways of working. However, I was lucky, in several aspects.
First of all, the application we were working on was being used in the medical sector and mainly by elderly people. For them, the benefits were clear and obvious. The product owner was easily convinced and was willing to put some of the team’s effort into this. On top of that, the new designers had a lot of experience with accessibility and were willing to help us. The stars were all aligned to make this work!
Of course, just declaring ‘we’ll make stuff accessible from now on’ would be futile. There were two hurdles we’d need to take: the team members needed to learn how to write ‘accessible’ code, and we had to do some refactoring on our current code to ensure that we had a healthy starting point. If either of these would be lacking, we’d have a hard time keeping this effort up in the future.
We decided to organise an ‘Accessibility Bash’: one afternoon, free from all other appointments and distractions, focussing only on accessibility. The goals I had defined for this afternoon were to learn about accessibility (the why and how), get cranking on some low hanging fruit (the what) and to leave the application in a better state then we found it. At the start of the bash, the team itself expanded to the goal to ‘make our primary path fully keyboard-only accessible’: perfect!
To facilitate learning, I had prepared a couple of ‘challenges’. Progressively more difficult and harder to implement. As expected all attendees had ignored my suggestion to have a look at the Udacity-course prior to the Accessibility Bash. That slowed us down a bit in the beginning, since people were unsure how to approach the problem. However, very quickly subteams emerged, each addressing different aspects and syncing their work.
In one afternoon, we made a big leap in accessibility support. We are in no way experts yet, but we now have a solid foundation to build on in the future. And for all features we implement from now on, accessibility will be part of the acceptance criteria.
What we missed most while doing this was feedback from actual users. We had little to no idea of the conventions that are typically used, or what changes would benefit them the most. This is something our designer will pick up in the upcoming weeks: he intends to find a testing group specifically for these kinds of questions. (UPDATE: we’ve actually formed this testing group now, with people with a wide range of impairments.)
From here, we will need to take gradual steps to steadily improve the application and ourselves. They way I look at it now, accessibility should be part of your normal routine the same way writing unit tests is!
Do you have thoughts on this subject you’d like to share? Reach out to me at email@example.com.
About ‘30 days of accessibility
As the name suggests, there are 30 daily assignments concerning accessibility, pushing you to actually dig in and get your hands dirty. It’s a great starting point to learn about accessibility: the first assignments point you to background information, and from there you’ll gradually expand your knowledge day by day.
Although I highly recommend doing the 30-day challenge, I myself took a somewhat different path. I started by following the first days of the challenge to get some background knowledge, and to get started with some resources. I then switched to my own learning path, as described above.
The actual challenge took place in May 2017, but you can start your own ‘30 days’ whenever you want by following the instructions the Ministry of testing’s website: https://dojo.ministryoftesting.com/lessons/30-days-of-accessibility-testing
[Dirk werkt als project en scrum master bij Infi.]