Making Accessibility a Team Standard
As a UX-focused software tester who is passionate about the usability of software, accessibility has been of particular interest to me. People accept technology into their life because of an unspoken promise. They want a better life and hope that allowing some bit of software into their routine will give that to them. Software is for people, and that shouldn’t just be people exactly like the ones who built it.
When I talk about accessibility, I refer to a broad spectrum of the human condition where we deviate from what is commonly accepted as standard issue. Not everyone has eyeballs or has arms or can read or can speak or can hear. So many people have some sort of trait that would be considered a disability, including ones not governmentally classified as such including common learning and reading issues. From people with paraplegia to dyslexics. From the deaf to the hard of hearing. We are different.
Attending the Accessibility focused talk is something I have unwaveringly done at every conference I’ve been to, from WWDC to MobileUXCamp, Xcoders, and well beyond. I’ve also delved deep into resources and articles out there focusing on various aspects of the challenge of accessibility support in software.
A recurring issue I hear from people on the ground floor who care, and want to move toward more accessible software, is concern about how they can convince others in their department or team to allow for it. They need help getting Buy-In. They want approval and permission.
That’s the wrong approach. You’re not going to ask for permission or later, forgiveness. You’re just going to do it because it’s the right thing to do. You never need permission to do your job.
Find ways of including people with varying abilities in your Usability Testing design phase. Many colleges have centers that you can reach out to, to help connect you with people willing to participate and bring their unique perspective. If your Design department starts solving problems that include everyone, you are baking in support from the get-go that will flow through the entire project.
Your programmers want to do that whole “surprise and delight” thing even if they groan at the phrase. They want their work to shine and be usable by all. They want to participate in design when and where they can, and they want to implement the intent of the Design just as beautifully and intensely as the UX team does. They also love puzzles and challenges, and sometimes implementing support for accessible features is just that.
They don’t see themselves merely as implementors (even if sometimes their managers do) and that means they stand by what they produce, to put out something not fully usable into the world makes them itchy at best. They want their work to last.
Encourage the team to seek out experts and deputize someone to be your team’s expert. Enable that person to delve deeply into implementation and be a resource for the team.
When conducting code reviews and merging in those feature branches, check that everyone is on the same page, headed toward the same goal. Likewise, if you notice a tester hasn’t covered something or a designer hasn’t accounted for a use case, raise that flag high.
Ensure your testers have heuristics and test cases that address your application's functionality and usability when using available assistive settings. They should be using state models for each applicable setting. Yes, each one. Your test coverage should be multi-pronged, and you should be able to ask external testers to focus on areas of coverage during Beta testing. Have your QA folk gather the ideation cruft from Design to help inform test coverage. If you’re on iOS having accessible UI elements means your project can delve into UIAutomation too.
The attention and care you give toward accessibility must be so embedded into your design, development and test structures that to have it as a SOW line item would be laughable. Try telling your programmers that to cut down on time & budget they can no longer put comments on their code and see what happens. If you survive the tidal wave of laughter, sobbing and eye rolling, perhaps a compassionate soul will explain to you that it’s an ingrained and compulsory part of their trade and practice.
Creating software for humans with their various variants in mind is simply part of the art of making great software. If you are called to defend your accessibility support to stakeholders, gently explain to them that their software is meant for customers and 100% of them are human beings, unless your stakeholders have commissioned a shell script to live on a server or something. To press on further point them to ADA and 508 and various lawsuits and class action settlements out there. More attention paid from the design, development and test teams is far cheaper than a lawsuit, let alone lawyers fees.
A typical user of your application might not think of themselves as needing an assistance. Consider your user, however. How deeply does a user pay attention to your application? Have you noticed people with their chin to their chest and a device in hand wandering around your city or town? I know, it seems like they aren’t paying attention to their surroundings but they are. They are apportioning their attention to an application, their immediate surroundings and whatever is floating through their beautiful mind.
Sometimes this means they will use VoiceOver to help them read an ebook, and sometimes it’s using Zoom so they can better see a website. Maybe they have a headache and are using inverted colors to ease the pain. Maybe they just like a large or bold text better aesthetically. Maybe they are trying to get better at another language and using VoiceOver better enforces their usage. Consider what your eyesight was like when you were 15, then 35? People decline. All of us.
I promise you that these features are in use by people you wouldn’t usually think of when implementing support specifically for “accessibility”.
These users don’t need convincing now, do they? This is their daily life and they want to accept the promise too. Putting in the time and attention for assistive features is non-negotiable to those who require it.
There are communities out there like AppleVis who are primarily dedicated to weeding out the muck and shining a light on accessibility-friendly applications. How many simply bounce your app directly into the bin if they can’t achieve the necessary functionality? How many simply do not tolerate anything less than a stellar experience? We don’t know. Why not just stop putting them in that position?
Can you imagine buying a product to solve a problem and when you tried to use it you figured out it could only be used if you didn’t have sight, hearing, vision, etc? Ridiculous. Why wouldn’t you take the opportunity to include communities who have been largely ignored?
The gains here are incalculable and unknowable.
May 15th was Global Accessibility Awareness Day and you missed it. That’s OK. There are things you can do outside of your project or company to help raise awareness and help in general.
When you see an Accessibility or Universal Design talk at a conference, attend and ask your colleagues to as well. Most are full of attendees who need help and you’re an expert they can confer with and the presenter usually will have some keen insights you may have overlooked.
Another way to show you care and demonstrate that these issues are important is to give direct feedback to developers of apps you use. File a bug report or enhancement request, show a use case and the business value. Let them know this is important to you as a user of the app, regardless if you are “disabled” or not.
If you are in a position of leadership in your group, allow your team members to use you as a resource for guidance and implementation. Show them how by a job well done.
If empathy is what drives you to create useful bits of technology, craft your software for all, and champion others to do so as well. Be a promise keeper.