Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Over 1.3 billion people live with some form of disability. This accounts for almost 20% of today’s workforce in the U.S. While great strides have been made in closing the disability inclusion gap in the workforce, more needs to be done.
As the popularity of hybrid and remote work continues to grow, workers who live with a disability and work from home increasingly need accessible collaboration tools made available to them.
To meet this demand, developers need to build with accessibility in mind. By doing so, they can create more accessible software to help workers with disabilities overcome any unique challenges they may find when interacting with technology while creating an enjoyable working environment for everyone.
There are many ways to do this, however, here are some best practices and key learnings to help developers build with an accessibility-first mindset.
Challenge the Status Quo
Innovation is always about challenging the norm, and this is especially the case when it comes to developing more equitable products. There are many ways to do this, depending on what processes are already in place. Still, one area that I believe can always be adapted is the way accessibility is thought of and managed internally, especially with regard to product design.
While the vast majority of companies today prioritize accessibility in some way or another, often it’s done by having a team—or, in the case of smaller departments, an ambassador—tasked with managing this work. This approach often leads to accessibility being seen as an add-on to design, something that happens at the end of the process. In reality, it’s better for developers and DevOps teams to take a hub-and-spoke approach to accessibility. In this model, there is one central source of expertise that people can go to for advice, but individual teams also are tasked with working on and being mindful of accessibility at the same time. The results as a collective would be far more collaborative and impactful.
Likewise, challenging the status quo could be as simple as encouraging conversations about accessibility with your team. If accessibility is a subject you want to discuss with your team but don’t know how to bring it up, remember that most accessibility problems stem from a lack of awareness. It’s usually an oversight, and ideas begin to flow once the conversation starts. So why not kickstart the conversation? Come prepared with user stories and potential solutions and your team will immediately start seeing all the appropriate changes that need to be made.
Work Directly With People With Disabilities
When building any software, it’s important to gather feedback from all kinds of people so you can be sure you’re building the features and experiences people need.
When we begin a project or an update, we strive to understand how current functions or other similar products are (or are not) accessible so we can better understand our customers’ expectations or frustrations. There are a number of ways to do this, but perhaps the most broadly impactful is hiring people with disabilities and having an open discussion with them about the product. Along with hiring, it’s also valuable to contract specific companies that employ people with disabilities to test products and give their feedback.
Receiving this feedback is key to developing a successful product and usually results in a more flexible and well-rounded user experience. For example, a text-based app with extensive text scalability designed for people who are blind or low-vision will be equally as useful to a user who prefers their text to be small or uses the product in a language requiring different string lengths. Similarly, captions designed for people who are deaf or hard of hearing can be useful to anyone who might be in a noisy environment or who prefers to consume written rather than audio content. When you make a product work really well for a particular group, you inherently create a better and more adaptable experience for everyone; you are meeting users where they are.
Don’t Make Assumptions
It’s incredibly important when you’re having conversations with people with disabilities or when designing a new product to not make assumptions. For example, early in my career, I would have assumed that an image-based program would be completely uninteresting to someone who is blind; I now understand that is categorically not true. By integrating interesting and vivid descriptions of images into the product, an image-based program can become accessible and engaging to all.
By avoiding assumptions about what someone can or cannot do based on their abilities, we open ourselves up to a world of creative solutions and possibilities that we might have otherwise not considered.
While people with disabilities ultimately provide the best feedback, don’t forget to spend time on your own or as a team actively challenging your design and looking for ways to improve its accessibility. Spend an hour or two as a team using your product with a screen reader such as VoiceOver or TalkBack or use your application using only the keyboard but no mouse. By constantly engaging with and testing your own design, you will better understand the user experience and may catch bugs or accessibility issues on your own.
Be Prepared for Trial and Error and Share What you Learn
Twelve years ago when I first started to focus on prioritizing developing for accessibility, there was very little documentation on accessibility in this space–especially when designing for mobile technology. This caused a great deal of frustration and often slowed our work down as we tried (and failed) to get it right. Sometimes this involves a delicate balance of adhering to your product’s established standards (i.e. how things should be labeled or how things should look) while solving for accessibility and efficiency in tandem.
Since then, things have changed a lot in the developer space. Today, there is a lot more material out there about the topic as well as industry standards to abide by. Universities are now offering more accessibility training within computer science courses, content creators with disabilities share more of their experiences, and companies are more open about sharing accessibility resources.
However, trial and error is still vital to building with an accessibility-first mindset, especially as we continue to innovate in this sector. So be patient and trust the process.
Inclusive design results in better products for everyone and, in particular, for all the people around the world experiencing some form of disability. Make sure you are a part of the solution and share your learnings with your developer community to continue this movement.
As a developer, the more time you spend learning and listening to your community and making them your number-one resource the more understanding you will be of their needs and how you can create the ultimate user experience. In turn, this empowers users to do their best work regardless of their abilities or circumstances.
