This past weekend during our most recent Weekend Testing session, we focused on some exercises centered around Accessibility. The experience was both interesting and enlightening. Interesting in the fact that there is always a greater appreciation when confronted with challenges outside of our own, but enlightening in the sense that it can be very difficult to make the mental switch to “think differently” about our experiences.
I’ve been focusing a lot of time and attention this year on Accessibility and Accessible products. Part of this is due to work focus, but part of this is also because of my experiencing the natural aging process. My vision is not what it used to be. At distance, I can see fine, but sitting in front of my monitor without reading glasses is becoming more and more difficult, even when I blow up the font to truly large sizes. Thus, I am one of “those users”. For me, it’s not an abstract future thing, it’s happening now, and though mild, will probably become more pronounced as I get older.
Accessibility is, unfortunately, one of those odd duck initiatives in the sense that it tends to be looked at as either a negative or a necessary evil. Many companies don’t do any Accessibility work at all, and often those who do are doing so because either legal action has been threatened, or they are wooing a customer with deep pockets who has made Accessibility an important measurement. In both cases, they are looking at Accessibility as an afterthought, and often with a need to shoe-horn the functionality into an existing product. Having been on a few projects where that has been needed, let’s just say it’s not the ideal situation.
Lately, I have been paying more attention to the ideas of Inclusive Design. Both words are important. Inclusive meaning to serve the broadest population possible, and Design meaning it’s best to start with the ideas of inclusiveness than to try to push them in later. Have you ever picked up an app or a game where there was little to no explanation made, and the need for instructions was unnecessary? That’s an example of inclusive design.
We focused our session on using a screen reader, which is a device that reads what is displayed on the screen to the user. For those with Macs, you have a robust screen reader built into your Operating System already, VoiceOver (PC users can download NVDA for free). Enable the screen reader, and go to a favorite web page. Load the page, and let the screen reader do the talking do the talking. My guess is that, for most sites, you will hear a lot of strange words coming back at you, and you will have little to no idea what you are hearing. Compare this to a sighted user, who within the first five seconds of viewing a screen can typically determine the point of the page and the objective they can meet. The experiences are far from equal. However, if you find a site that has taken the time to organize their data flow, you get a totally different experience. Programmers use ARIA tags and other options to help screen readers ignore the irrelevant items and get to the main content fast.
Inclusive Design doesn’t mean that Accessibility is front and center. In fact, it means that, from the beginning, the focus is on making sure that the users have a clean and unfettered experience regardless of if they have a physical disability or not. Inclusive Design is clean design. It’s efficient, it’s focused. It allows everyone to do what they need to do with the minimum of fighting with the system possible.
As we move forward, especially into the brae new world of the Internet of Things and the proliferation of Mobile devices, we have a unique opportunity to make a course change. Instead of doing the same thing the way we’ve always done it, let’s take these new devices and capabilities as an opportunity to really think about what is essential, what is extra, and what genuinely gets in the way of people doing what they want their devices to do. Embracing Inclusive Design, and doing so early, can be a winning strategy for everyone.