Too many people leave out the process of accessibility in their design phase or early development cycles. As obvious as it sounds, I still need to say that the sooner you start implementing accessibility in your projects, the less work is needed. At every phase of a project, there are many things that can be done to enhance the accessibility of the final product, and taking care at every point is easier, faster, and more affordable than the alternatives. Many projects leave accessibility out and then end up paying the price later on.
Start with the User in Mind
The cornerstone of creating a successful feature begins with understanding the user and their needs. Engaging with disabled users at the early stages of development can provide invaluable insights into how they want to, and will, use the feature. This step not only helps in shaping the feature to be more user-centric but also paves the way for a more inclusive product.
Four Example
Let’s imagine we have been asked to create a new widget to request event accommodations. Okay, we need to make sure that there is a list of available accommodations and that this list works with a screen reader and with voice input. That is obvious, but is it? Let’s imagine you’re the developer who has been given this task. However, you have never worked with people who have disabilities, and you do not know any thing about what accommodations are. Of course, the manager who gave you the task left for a month-long vacation and will not be back before the widget is expected. So now what do you do? Sadly, many developers will start creating the tool before even taking the first critical steps.
Most developers would think that the information about accommodations provided in the task description was all they needed to add. Accessibility-minded developers who are savvy already know that they need to find a few disabled people and ask them what kind of accommodations they might be requesting. Maybe they would go over the list in the task description with a person and ask: Is that list complete? Do they understand what the items on the list are? One other key question is: Are the accommodations listed in the task description using terms that any one would understand.
For example
maybe one of the accommodations was for CART services. Now, in the disability industry—especially those of us working in education—we know that CART stands for Communication Access Realtime Translation. However, many people do not know what that means, and even if it’s spelled out, how many of you, my readers, know what it is? The developer who has no disability background might end up only saying “CART” to the list of services and then moving on. However, if the developer spends time talking to users, they will learn that CART refers to what might be more commonly known as captioning or live captioning. Now our savvy developer will Better be able to describe what the accommodation is: “CART (Communication Access Realtime Translation); live captions.”
Let’s look at another accommodation that might be misunderstood. Maybe the user needs early access to documents, and the task list refers to this as “digital access.” If the developer does not check on this, they might just put “digital access”. Now the user does not get to indicate that they need early access before the event they’re requesting the service for because, “digital access”could mean anything.
So now What
Okay, so now we have two services that will be added to our form that could both be included in an incomplete or vague way. Our developer has spoken to real users and found out what to actually add to the form, and that they might need to present some of the options on their list differently for better comprehension. So, if all you have as a developer is the list you were first given, you might add to the list of choices: “CART services” and “digital copies of documents and forms.” The developer who has checked in with disabled users actually now adds the items somewhat differently. They may ask: “Do you need CART services (Communication Access Realtime Translation), i.e., live captions?” Then the developer might also add: “Do you need any of the documents being used in an accessible format?” and then ask the user to indicate what format they need and by when they would need it.
So on to the next faze
Accessibility is not this simple, but these two examples show how even a simple form can be more accessible and clearer to the audience. Also, the developer may even add a free-form field for the user to add things that may not have been thought of as part of the process. After all, we don’t all know what everyone needs, and everyone needs different things. Let’s take this project to the next phase.
So, we now know what content we really need on the form; it’s time to decide how to present it. Most of the time, this kind of form is pretty easy. We might just create the widget and be done. But making choices that affect the user should not be decided in haste. We need to understand how the widget is related to our other content.
For example
maybe we have the ability to make these requests on a large company website, and the only place we can put the widget is not easy to get to as a screen reader user. Maybe the developer ends up thinking that the best answer is to make the widget create a downloadable PDF that has to be filled in on paper—don’t laugh, this happens all the time. And yes, the PDF is more often than not inaccessible, and more and more people don’t have access to a printer. Screen reader users may not ever be able to fill in this form without help.
So go back to your users and ask them how they would want to fill in this form, and how they would want to find this form. Our developer, once again using input from people with disabilities, makes excellent choices. They create an HTML form that has proper semantic structures and good labels for all form fields. They also offer an accessible PDF version so that, if the person wants to, they can fill it in offline. Then they provide many ways to submit the form, i.e., email to a person or, hey, maybe even snail mail. With many choices like this, people with disabilities can make the request in one of many ways and pick a way that works best for them.
Again, this small example is not very realistic, but it illustrates the idea of adding people with disabilities to the process in all phases of the project. Because, of course, our developer who did reach out asked their users again to test the form a few times to make sure they made the right choices. Sadly, many projects end up going through the whole process and then learning of the different ways the widget does not meet people’s needs and end up having to scrap the work already done or try to fix the widget. Fixing the widget might not be easy if the website that was hosting the form was not built in a way that supports HTML forms. Or maybe the platform that is being used is so badly designed that users can never find the form. Maybe no one will tell people with disabilities that the form even exists.
Again, this example may be a bit simplistic, but it highlights an important idea: involving people with disabilities at every phase of the project. Our savvy developer, who reached out initially, of course asked their users to test the form a few times to ensure the right choices were made.
in conclusion
Unfortunately, many projects go through the entire process only to discover that the widget fails to meet people’s needs. This often results in scrapping the work or making difficult fixes. Picture this: if the website hosting the form wasn’t designed to support HTML forms, or if the platform was so poorly designed that users couldn’t find the form—well, that’s a recipe for frustration. And let’s not forget, without proper communication, people with disabilities might not even know the form exists!
So, my friends, let’s keep accessibility at the forefront and enjoy the benefits of inclusive design.
I have oversimplified this idea, but it’s key not to forget that the more you think through things like accessibility and users’ workflows, the better outcomes you have. In the worst case, the bad outcomes of not taking the care and steps needed may lead to people being left out and having no benefit from your tool, service, or events. And the worst thing for you is that you may end up with very unhappy users or users who never return to your services because they did not get what they needed.
So, take the time needed and make sure to think through what everyone needs, especially people with disabilities. Always be ready to take feedback and act on it. The sooner you act on the feedback, the less you need to pay out over time in hours spent fixing or supporting people, and the more people will want to use your services. After all, if you don’t make things accessible, you are not allowing over 25 percent of the population to enjoy your service.