How business FOMO is the enemy of good accessibility

Fear Of Missing Out is very present in the business world, not just personal social media. And it is very bad for PwDs and accessibility

FOMO is defined as:

Pervasive apprehension that an exciting or interesting event may currently be happening elsewhere that one is missing.

FOMO is often exacerbated by posts seen by individuals on their friend’s social media feeds.

Business FOMO is a thing. The business spin on the classic personal FOMO definition above would be:

when business leaders are afraid of missing out on something, not being where things are really happening, or being one step behind on the latest and greatest feature that they think all the customers want.

Business FOMO is exacerbated by disruptive business models.The faster an industry moves, the more likely that business leaders in that industry take the “blink and it’s gone” approach to managing projects within that business.

Business FOMO is characterized by:

• Lack of structured design processes such as inclusive / universal design or design thinking
• Sudden shifts in requirements, both in the adding and deleting of features
• Compressed QA cycles
• Release of products “not ready for prime time” to beat the competitor to the market.
• Failure to pay sufficient attention to integrated non-product components

Lack of structured design processes

• Good, accessible products start with accessible design.
• The lack of structured design processes inevitably results in inaccessible design.
• It is estimated that a 5 % (or possibly less) of designers have read the WCAG guidelines.

If your organization doesn’t design with accessibility in mind, they can do EVERYTHING else right and still end up with a completely inaccessible product.

Scope Creep

Scope creep is the hallmark of a FOMO development plan.

1. Someone hears about Cool Feature X that Competitor Y is working on
2. Cool Feature X is added to the product scope
3. Sometimes, another feature is dumped to make room for Cool Feature X

Any accessibility work that went into the dumped feature is wasted

Cool Feature X usually faces development time constraints because it was late to the product party, so corners are cut.

When this happens repeatedly, people working on the development team start to cut corners on all features. It is effectively scope creep fatigue — since the developers don’t know what will end up on the cutting room floor and what will be in the end product, they don’t invest fully in anything. And the first corners that get cut are frequently QA and accessibility.

Compressed QA

Compressed QA cycles come in two forms:

1. Where one or more QA cycles are shortened to an arbitrary number of days. QA cycles should only be closed when a particular level of quality is reached or Definition Of Done is achieved. When an arbitrary number of days is used for QA, bug-riddled releases are usually the result.
2. Where the accessibility QA cycle overlaps the functional QA cycle to shorten the total amount of time in testing. This is an incredibly poor practice because: a) to do manual accessibility testing (especially with users with disabilities) you need a certain level of functional quality present and b) if you substantially change UI code to fix functional bugs after you start manual accessibility testing, all of the manual accessibility testing results will be invalidated and the tests will need to be repeated

Premature releases

Premature releases kill people. Uber’s self-driving car fiasco in Arizona is the classic definition of that, where the software was programmed to not recognize pedestrians outside of crosswalks. What Uber and Boeing did was WORSE than putting a gun to someone’s head and pulling the trigger. They put entire populations in danger, and in the case of Boeing, killed hundreds of people. Even the smallest thing way down the supply chain like a small O-ring can end up causing catastrophic deadly results (Challenger explosion anyone?).

There is never time to do it right, but there is always time to do it over — Jack Bergman

The companies that “do it over” rarely did accessibility right in the first place.

Ignoring integrated services

Customers don’t buy products. Customers buy product experiences.

And their product experiences include the product as well as anything necessary to use the product or get help with the product. Integrated product services that are essential to the product experience include:

• surveys
• analytics
• documentation
• user research
• training
• customer support

When a quick and dirty job is being done in these six areas, chances are even if the product is nominally accessible, the full product experience won’t be. And that’s not enough.