A team of engineers is making a new service. One of them submits a peer review for a new web UI, just some boilerplate React to get things started. A few weeks later most of the team has touched the UI, and it is still rough around the edges, but it works fine when anyone on the team uses it. That is until one person on the team notices something off. Maybe some buttons are unlabeled vague icons, a popup menu requires high dexterity to navigate, or the site cannot be navigated via keyboard. This engineer may be quietly hiding their own disability that is now making it nearly impossible for them to use their own team's UI. So they create a backlog task to make the UI easier to use, and raise the issue to whoever is managing this project.

"Our customers are not disabled. We don't have to worry about that."

Most digital ableism, like this, comes from engineers themselves and their leadership being relatively well off people. Relatively minimal disability is quietly selected for in the hiring process where more disabled candidates may have been quietly abandoned, and in the school system companies are hiring fresh grads out of. A sufficiently ignorant team will assume that their customers, whoever that ends up being, will be looking at roughly the same screen as them with roughly the same quality of internet, the same input methods, the same vision, etc.

Obviously if your service is aimed at the general public, it will have disabled users, since you cannot possibly avoid the 28% of your potential customer base with at least one disability. But even if your customers are only corporate employees, companies grossly underestimate how many disabled employees they have. Corporate customers may try to hide their disabilities, but will run into a wall trying to use your service. Even if your customers are other teams of software engineers, you are wrong to think they are not disabled too. In all likelihood, they are hiding it as much as they can and quietly struggling to protect their career.

Even if you somehow personally know every last customer who will use your service, at best they are not yet disabled, since everyone will be eventually, therefore your inaccessible design will not stand the test of time.

"Accessibility will take too long. We can't afford it; we have to move fast."

If accessibility is time consuming, it means the engineers who built the UI were foolishly building an inaccessible UI from the beginning of design. This means they are not ready to be even competent junior UI/UX engineers. This is a foundational part of the skillset for this work that in my opinion should be checked for during hiring. If accessibility was baked into the initial design, the total added time would be trivial enough that there is no excuse for it pushing back project deadlines.

Even when accessibility is a backlog item on an established UI, the hesitance to pull that out of the backlog is more about devaluing disabled users than it is maximizing business value. The cost is far overestimated, there is fear that the UI will somehow get worse for everyone else, and underneath it all a discomfort at acknowledging this problem, or acknowledging disabled people themselves. I think sometimes nobody wants to be the first and only person in an office to raise the alarm on this issue. If you are surrounded by sufficient ableism, you will be preaching to a wall.

In Amazon terms, this situation is about balancing bias for action against customer obsession and insisting on highest standards, i.e. is it more important to build faster or make the customer experience better. In startup terms, it's about whether the MVP really needs this, and how much it will be delayed. There are plenty of articles out there about the business case for accessible software. In virtually all cases, the benefits should outweigh the costs. Startups can live or die off of an MVP being rejected by users who can't navigate it. New products can be delayed by customer rejection after invested time.

I experienced this situation when we were informed that the customer had employees with lower resolution monitors than ours and worse vision than any of us. The project manager had pushed development so fast that peer reviews were disabled, and testing was minimized. A little more verification of the design would have solved this. Accessibility did not take too much time; the lack of it did.

Even Google in its efforts to chase profits at scale veered towards inclusive by design as a standard. In other words, your company is not too big for this issue to still be relevant either.

What your customers' abilities look like

I don't think I can make an all encompassing list, but I can list out many of the most crucial problems customers with disabilities will encounter to keep in mind when working on UIs

Visual disabilities

• Your customers may rely on screen readers, or magnification features.

• Your customers may not be able to read text on colourful backgrounds.

• Your customers might not perceive the difference in colours between elements.

• Your customers might see alt text instead of images.

Hearing disabilities

• Your customers may not be able to hear audio context.

• Your customers may need to adjust audio volume.

• Your customers might be harmed by high-frequency sounds.

Neurological disabilities

• Your customers might be harmed by rapidly flashing colours.

• Your customers might not be able to read fancy serif fonts.

• Your customers might not be able to read justified text.

• Your customers might be using third-party tools to adjust colour and font family.

• Your customers might be distracted, or confused by complex content layouts.

Motor disabilities

• Your customers may struggle to navigate through floating menu windows, or navigation requiring several clicks.

• Your customers might not be able to click your tiny button.

• Your customers might be stressing over time-limited interactions.

• Your customers might be struggling to close popup elements blocking them from your content.

• Your customers may rely on tabbing to navigate rather than scrolling.

Mental disabilities

• Your customers may be harmed by exposure to intense emotional content without proper warning.

• Your customers may be anxious and overwhelmed by unclear direction.

• Your customers may not be able to mentally track where they are on a large form.

• Your customers may be panicking over trying to submit a form and not being shown what the error is.

Accidental benefits for people who are not yet disabled

The most fascinating and exciting part of accessible design, to me, is that it almost always improves the user experience for literally everyone else. Let me list some benefits experienced by the not yet disabled when using an accessible UI:

• They may see alt text instead of images when their connection is poor.

• They will read and understand your text faster.

• They can use subtitles to make sure they heard correctly, or just to take in the information in more ways to solidify learning.

• They were not liking high-frequency sounds anyway.

• They were not liking rapidly flickering colours anyway.

• They were not liking needlessly complex layouts and navigation anyway.

• They wanted to use their keyboard as a power user anyway.

• They wanted clear instructions and navigation anyway.

• They wanted clarity on form submission errors anyway.

Notice how in the prior section I did not list disabilities, but I did list problems that disabled customers have. That is because experiencing these issues is not specific to people having a specific condition. These are problems that negatively impact every customer to some extent, even if those not yet disabled are too stubborn or accustomed to non-accessible UIs to realize this.

My experiences as a disabled software engineer

I got into computers in 2009 after Windows 7 came out. I taught myself enough programming on the side of my last two years of high school via online tutorials. I built a scientific calculator and got the point where I could breeze through the first two coding classes. Before this, I believe I had only known Windows XP. I don't remember much, but I do remember accomplishing next to nothing on those computers. I could not reach software via the Start menu. I had to rely on file explorer and desktop icons. I wonder why I didn't like computers so much at first.

Because of my lacking motor skills, I have only used laptop touchpads, not a mouse, in the past 15 years since I started uni. This has hardly held me back, but it has raised eyebrows from many peers, even though they acknowledge my touchpad speed is unreal to them. My problem with using a mouse is that my hand twitches enough to throw me off too often, and it would slow me down in ways a properly configred touchpad forgives.

In the office, I show up wearing a back brace to be physically capable of getting through a day at a computer desk. I also have to work around audio processing disorder. I have to be vocal about requiring writing to come out of meetings, especially action items, and I do not accept verbal instructions without writing. This usually does not slow me down at all other than situations where this is pointlessly refused.

I have struggled with overly complicated sites with too many disparate things going on to be able to focus on anything long enough to meaningfully use the site. This was more of a problem back in the '00s. Modern material and simplistic design virtually eliminated this, but I have seen internal tools at software companies being drastically outdated 90's designs. There was an internal tool for working with a database at my first office that was barely legible and navigable to me, and I am lucky I was able to get around needing to use it.

I have permanently left sites, including certain social media websites, due to triggering content that genuinely destroyed my ability to focus and function for hours or days. It is understandable when it is user posted content that is not feasible to automate warnings for, but unforgivable when it is content the site hired or commissioned for or wrote themselves.

When I first joined AWS, I heard about Jeff Bezos having insisted on an empty chair in meetings to represent the customer, but in 4 years there I never once saw this done. The idea is sound to me: Better decisions will be made if the people in the room are aware of the needs of the customers they are building for. In order to do that, you must have a realistic and not ableist view of your customer needs.

Responsibilities

Technical leaders proposing or reviewing any design should be proactively resolving accessibility misses. Business leaders are being paid to optimize revenue and longevity, therefore making them responsible for pushing accessibility standards that will inevitably benefit their business. Product managers are responsible for making sure accessibility issues are prioritized appropriately rather than thrown out due to bias. UI/UX builders and testers are responsible for making sure every UI is also accessible, as a basic practice even juniors should have received education on. Customer support engineers and their leaders are responsible for raising the alarm on accessibility issues raised by customers. Not having learned this in bootcamp/uni is not an excuse. Your customer is disabled.