editione1.0.0
Updated October 9, 2023If you are in the software business, the accessibility of software features won’t be new to you. You may have had to answer support tickets or sales objections that relate to how well your software supports users with different accessibility needs. For the rest of you, you may only be familiar with these issues if it is something that has had a direct impact on you or those close to you.
The Web Accessibility Initiative defines Web accessibility to mean that people with disabilities “can equally perceive, understand, navigate, and interact with websites and tools.” Web usability is about “designing products to be effective, efficient, and satisfying.” These two concepts can be very closely related if usability considers users with disabilities as part of their scope.
Usable security can look like different things for different people. Accessibility breaks down into five categories:
Sight
Hearing
Cognitive
Physical
Speaking
Usable security can also be expanded to be inclusive of other groups, not just those with disabilities but those who are neurodiverse too. It can also include people with age-related disabilities, temporary or permanent damage from accidents, digital accessibility and knowledge gaps, and language barriers.
For those with different technical abilities and needs, a password storage solution could be using a journal that is kept locked up in a drawer at home to house all their account passwords rather than a password manager. For those living in rural locations with no cellular coverage, it could mean never opting in for SMS-based 2FA and always going for a one-time password that can be accessed over the internet (like through Authy or your password manager).
Now that we are clear on the different accessibility and inclusion needs and how that impacts the usability of security features, let’s look at some tips around 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.