Creating Accessible and Usable Software

Those of us who build software have a responsibility to our customers to create accessible and usable software. This includes any security features or flows that we build—like the flow users take to log in, the masking of data entered into sensitive fields, the use of CAPTCHA to stop automated bots, the 2FA options we have available, or the third-party overlay software we allow interactions with. We know our customers best, and it is up to us to make sure it is inclusive and usable by all of them.

Including accessibility as part of your engineering practices is not just important, but also beneficial. When providing customers security features, your aim is to reduce the amount of incidents or negative security impacts your customers face and to ultimately help them feel like their data and account with your software is safe. If those features can’t be used by a part of your customer base because their needs and abilities were not considered, there will be a high barrier to entry and a low uptake of those features. So while you can pat yourself on the back for finally launching 2FA, the value you and your customers get from it will be lower. You can’t be surprised when you still have a high number of support tickets asking about 2FA or account takeover when the options provided are not usable.

The Web Content Accessibility Guidelines (WCAG) by W3C is the main international standard when it comes to accessibility. It covers guidelines for the four key principles of web accessibility: making your software perceivable, operable, understandable, and robust for people with different abilities. These guidelines are a great place to start, and the W3C website is chock-full of other supporting guides and resources to start learning more about improving the accessibility of your software. Another great source of information is section508.gov, which stems from Section 508 of the US’s Rehabilitation Act. It was made to provide guidance to those who are responsible for technology accessibility and is full of lots of advice, even outside of just pure software development.

Next, we will want to assess where your software is at when compared against guidelines like WCAG. The A11Y Project is a community-run, open-source effort to make web accessibility easier for software development teams. They provide checklists to help organizations assess their own WCAG compliance, as well as a list of resources if you want some additional or professional support. Their resource list also includes some tools you can use to automate your self-assessment, but we highly recommend getting help from a professional who can provide an in-depth human assessment and can consider the context and details of your customer personas.

It can be overwhelming to read through the recommendations from WCAG and figure out what needs to be done and what is most important. Getting professional support means having someone help you sort through all the advice and redesign your software development roadmap in a way that considers your goals and your users’ accessibility needs.

It can help to also be transparent about how you and your organization handle the accessibility of your software. For example, Duo, who provide a popular multi-factor authentication software product, have an accessibility page that outlines what they have done and the best products or configurations to use depending on the user’s needs. Similar to how we should strive to be transparent in how we handle data in our privacy policy, an accessibility page can help your customers understand that you aim to make an accessible and inclusive product, and will be transparent about what steps you have taken.

Let’s now look at different resources that can help you or your team build a strong accessibility foundation.