Why Your User Experience Must Include Design for Accessibility
Too often, usability and accessibility are confused with each other by our clients (stakeholders). They shouldn’t be, because while they are related, they are very different. So, how do you bring these two concepts together? They should really be working side-by-side throughout the ENTIRE process. This might seem like a no-brainer but it can be a challenge.
First things first, Section 508 of the U.S. Rehabilitation Act is a LAW. It has teeth. Agencies and organizations have been sued because of it. Section 508 exists for a very good reason: it states that electronic and information technology developed, procured, maintained, or used by the federal government be accessible to people with disabilities. Find a definitive source and refer to it. Consistency in interpretation here is very important. Usability, on the other hand doesn’t have this legal threat, but it does carry the possibility of bad press—a bad reputation tends to hang overhead like a storm cloud. It can be hard to shake—ask any school kid. Interpretation of what is “usable” can be a moving target. It is often contextual, and can be hard to nail down. Again, having a consistent and reliable resource you can refer to is vital. An agency style guide or design (pattern) library can be really helpful.
So, how do you bring usability and accessibility together? Communication and collaboration.
At the very beginning, both groups (or concepts really) need to be involved. I would suggest getting or feedback/input from both areas from the very start and throughout the design process. That includes finding out what doesn’t work, as well as what is considered essential (“first, do no harm”). Knowing who needs to be involved (throughout the process), what they need to do, and when they need to do it is key.
User experience design is a PROCESS—and in my opinion, accessibility should be part of that. Let me be very clear for a second, no two individuals use assistive technology (AT) in the same way. In the federal government, we support JAWS, Dragon Naturally Speaking, and MAGIC (screen magnifier)—there are others, and the three mentioned may be used in combination or alone, but we need to keep those systems in mind when we design. Each set-up is unique. So, how do you make every person happy? You can’t. But you CAN design (or redesign) intelligently from the very beginning…and this will go a long way toward user satisfaction.
Keeping the concept of usability and accessibility in mind throughout the entire process is also important. Knowing what designs fall in to patterns can help you determine design standards. Accessible code can be “baked-in.” Of course, anything you make still has to be evaluated, but by increasing consistency—life gets easier. You don’t have to re-create the wheel every time you design something.
If you are the “lone-wolf” (the only person responsible for accessibility AND usability), you need a plan. It can be easy (and appealing) to rely on automated tools to see if something “passes” 508. While using these tools might seem to be a fix/solution—it really isn’t. This is where things often get tricky. Using a computer to help you identify WHERE a problem may be is one thing, but understanding WHY it is an issue is another. Remember—a PERSON is using a service, you have to make sure that the PERSON can use it. Too often, accessibility is sacrificed for usability, or vice-versa—this doesn’t need to happen. If you are alone coming up with a plan is really important. The thing I have learned I have learned is that working out a plan at the beginning and then getting feedback along the way from others is key. Working alone can be a challenge—reach out to others. Document EVERYTHING. Having documented designs and patterns that you know have accessible code is VERY helpful.
If you are fortunate to be part of a team, and/or have separate groups (like we do at SSA), communication and collaboration is vital. Since we are co-located, it is easier to work together –this may not always be the case. Let me be very clear on this: what works for us here may not be an EXACT match for your organization—but everyone needs to work together. It can be easy to end up isolated from other groups—but once you have identified whoever else is involved, it can be just as easily remedied. It is like identifying stakeholders and usergroups—you may not know at first who is involved, but you can be fairly certain that AT users will be among them. Knowing when and at what point another person or group should become involved in design or evaluation can be unique for every project you face, but knowing that other parties will make that call is fairly consistent. That is, not every project will start from scratch, but knowing that groups need to work in unison as part of evaluation is consistent. Both groups need to communicate in order to work together. Having documentation or proven (compatible) designs help to smooth this process.
So, how exactly do you make that happen? I wish there was an answer I could point you to, but there doesn’t seem to be one I have found yet. I do know there is no “quick fix.” Simply knowing that the two things are unique (but related) is a really important thing to communicate to stakeholders. Just because something is “compliant” doesn’t mean it is usable. Just the same as if something “passes” a usability evaluation does not mean that it is compliant. There MUST be separate evaluations. Following design guidelines and using industry standards can save you heart—and headaches.
Making sure this process is transparent is also important. Being able to point back at what you did and why you did it helps everyone—especially those people who might join you or your team.
Lastly, and perhaps most importantly, understanding whom you are trying to serve is really important. Veterans may have different needs from someone applying for SSI, or they may be the same. We need to design to match the need. Designing intelligently can help. We have to remember whom we are serving and why.
