The Case for Software Accessibility.

‍It Began In 1918

Millions of men were disabled because of their service in WWI. It was clear that they needed financial assistance when returning home, but money alone didn’t lead to a fulfilling life. The Soldier’s Rehabilitation Act of 1918 was passed as it became clear that purpose was necessary. And vocational training through the Rehabilitation Act was the answer.

55 years later, the Rehabilitation Act of 1973 provided guidelines for “accessibility of telecommunications equipment.” 17 years after that, the Americans with Disabilities Act of 1990 made it illegal to discriminate based on disability, and only 6 years later in 1996, the Department of Justice mandated that digital content is a public accommodation, and yes, it is required to meet standards set forth in Title III of the ADA. Since then, more specific accessibility standards have been generated, including from the World Wide Web Consortium (W3C) through their WCAG 2.0 web content accessibility guidelines.

Why Does This Matter?

It’s critical to understand why accessibility is important for web, mobile, and all other digital interfaces. Caring about software accessibility simply because “it’s the right thing to do” is a fragile argument, making it easier to cast aside when life gets hard and priorities change.

The Web Accessibility Initiative (W3C) released some great guidance around “The Business Case for Digital Accessibility.” According to the W3C, 

“Businesses that integrate accessibility are more likely to be innovative, inclusive enterprises that reach more people with positive brand messaging that meets emerging global legal requirements.” 

We concur. Driving accessibility is more than just a philanthropic pursuit. It drives innovations and, in the end, creates an intuitive user interface that meets the needs of all users.

Accessibility and Our Neighbors 

Approximately 1 in 4 US adults have a disability in vision, mobility, cognition, independent living, hearing, or self-care. The most pronounced impact is on those with visual disabilities, which is approximately 4.6% of US adults. Combining the numbers from the CDC and US Census, we can approximate the number of visually impaired adults in the US to be between 7mil and 12mil.

That means 7mil to 12mil people can’t use software visually in the United States.

Moreover, according to the World Health Organization, 1 in 6 people in the world will be aged 60 years or over by 2030, reaching a population of 1.4 billion. Twenty years later in 2050, the population aged 60 years and over will reach 2.1 billion. These are substantial markets with high incidences of disabilities.  

The Challenge of Accessibility

Many will come to read this article and immediately think “All software should be accessible from the beginning. We would agree with the operative term “should”. But that just isn’t possible.

Why? “Accessible” doesn’t just mean having some labels in code, a tab order, or other checklist items for developers. “Accessible” means that you have taken the time to evaluate and design the user experience of the accessible interface: audio for example.

This is not trivial. User experience is a complex field of study, and visually based UX is already extremely challenging. Now imagine designing for an interface using a sense that typically takes a back seat in software: sound. Sure, your button has a label or text that makes sense when you have visual context, but does it make sense without that context?

If you can’t see where a button is located on the page, does “Submit” completely and accurately describe what the button does? Accessible software is not built solely from checklists (though they are important). Accessible software is designed.

That’s why it isn’t zero cost, out of the box, or even cheap. To do it right, it is about designing a completely new interface. Just as writing good code doesn’t automatically result in good visual UI/UX design, good visual UI/UX (or semantically correct code) doesn’t automatically result in good audio UI/UX.

A specialist must walk through the complete experience imitating the interface for which they are designing, just as we do with visual design today.

If you get the opportunity, discuss software development with a visually impaired developer who perceives software through sound. You’ll come to appreciate how different the interfaces are as you’re left in the dust while they blaze through the data relationships and hierarchies from memory and you’re struggling to draw a diagram.

So, when we talk about software accessibility, we’re talking about something that is fundamentally hard to do well, just as traditional visual UI/UX is not trivial. There is no current strategy that achieves excellence “out of the box”.

Many libraries UI libraries are doing their best to provide baseline accessible functionality such as  Amplifi UI , Material UI, Bootstrap, Foundation, Semantic UI, etc, and essentially all the major UI/UX specifications, such as Material Design, provide guidelines as well. But we can’t stress this enough: that will only go so far.

Front end visual libraries don’t result in a great visual user experience by default, and the same goes for audio interfaces.

Accessible Design in the Real World

We’ll use a combobox to demonstrate what can happen when you do not intentionally design an accessible user interface. In each of these examples, we’ll let the software environment in which our app runs dictate how focus changes, simulating an app built without accessibility designed from the ground up. Try to predict where the focus (the green highlight) it shifts after making a selection from the combobox.

Note - “Focus” is as foundational to an audio interface as a button is to a visual interface. If you don’t know what “focus” means in terms of accessibility, you now understand how different this interface truly is.

Case 1

We Have 3 input fields:

1. Top Input
2. Countries Combobox
3. Bottom Input

In Case 1, all input fields are present on the screen at once. Can you guess where focus (the green highlight) shifts after making a selection from the combobox?  

Focus is shifted to the top input field. Did you get it right?

Case 2

In Case 2, our Top Input is not visible at the same time as our Countries Combobox and Bottom Input. (Ignore the warning from React Native, it isn’t relevant to the demonstration). What is your guess this time?

Focus is shifted to the bottom input field. Did you correctly predict that?

Case 3

In Case 3, our Top Input and Bottom Input are both too high and too low in the interface (respectively) to be visible when our Countries Combobox is visible. Where will focus go?

Focus is shifted to the label of the Countries Combobox. Did you guess that one?

Shifting focus in a logical and predictable manner is just one piece of accessible interfaces that must be intentionally designed, not an afterthought.  

Amplifi Labs is committed to developing accessible software and helping businesses understand the benefits of doing so. Over the next 2 months, we will be offering insights and points of consideration for your next development project, regardless of your business size and type. This series on accessibility will examine some basic statistics, what software accessibility is, and why accessibility matters to businesses at every stage of their lifecycle:

• startups (<11 employees)
• medium-sized (11 to 100 employees)
• large (100 to 500 employees)
• very large (500+ employees)

‍