If somebody can use it, somebody can misuse it

Software development and the “doctrine of foreseeable misuse.”

There is a portion of the American legal system under the category of negligence called “strict product liability,” also referred to as SPL. Under SPL, anyone in the product chain (seller, distributor, or manufacturer) of a defective product can be liable to anyone injured by that product, regardless of whether the defendant did everything possible to make sure the defect didn’t occur.

SPL applies both to regular use and reasonably foreseeable misuse.

Under the “reasonable foreseeability standard,” a manufacturer may be held liable for injuries caused by a product even when a consumer misused the product.

These doctrines got drummed into my head in law school and immediately popped into my head when my colleagues shared the following “Developer/QA” meme where a developer breaks down into tears as they watch a person testing the product use it in a way that she did not intend during testing.

Devs watching QA test the product pic.twitter.com/uuLTButB3x
— zakovska 🌻 (@sanjazakovska) January 22, 2021

TikTok Video showing a parody of a developer watching a QA engineer test a ‘product’ where all the blocks in the shape sorting bucket go into the same hole

This article’s point isn’t that software should come under a strict product liability analysis in the US legal system. The point of this article is if you perform a strict product liability analysis on software, which would include ideating on what mistakes could occur, you will be able to answer the following two questions and make your product more accessible and more usable:

In what ways can users screw up when using my product?
In what ways can the system crater when running my product?

Use the broadest definition of “system” possible for the second question — browser, OS, hardware, network, database, server, timeouts, updates. If something behind the scenes can mess with the user’s experience, it needs to be identified.

The answer to these two questions will inform what steps to take in the future to help your users prevent or, at a minimum, recover easily from said screwups because they are inevitable.

I usually write about accessibility, and there will be some of that later in this article. People with disabilities who use assistive technology are about 5X as likely to make a mistake in filling out a form. They need to recover from those errors without being forced to spend 15 minutes figuring out what they did wrong and what steps they need to make to fix the error. That is a form of foreseeable misuse that comes squarely under WCAG.

Before I began my career in the accessibility field about ten years ago, I was a software QA director at a large tech company and, before that, a large financial institution. I see accessibility, at an abstract level, as another form of specialized regulatory QA, where what is “correct” is based on whether the software complies with applicable regulations and best practices. Of course, you can always do better than the minimums required. That makes accessibility in my consideration a close-cousin to privacy and security.

How to prevent (or account for) foreseeable misuse in software

Developers, program managers, and QA engineers can do several things to prevent or account for foreseeable software misuse.

Developers must put themselves in their users’ place when analyzing whether software behavior is “good enough.”

You have to know who your users are and how they might try to do things wrong, for starters. Personas are a great way to do this. You should make sure at least some of your personas have disabilities!

This approach requires some method acting skills. The people pretending to be users need to forget everything *they* know about the product and don the persona’s character. When the developer (in character) uses the software, they can only make assumptions that the individual in the persona would make. When in character, the developer should also think about things that might be in the persona’s environment that might interfere with product use. For example:

If the persona is a mother of two children aged five and eight, the environment might include noise, interruptions, and multitasking.
If the persona is a person with a disability, they might be in a lower socioeconomic strata and not have the latest devices or 5G internet.

If a product is far enough along in development, this is a great place to bring in real users, do structured UX research, and get feedback from them on what they like and what they don’t like.

You need to identify all the places the system can go wrong (even if the user isn’t responsible)

No one benefits from seeing unformatted SQL or network errors spewed all over the screen. This is especially difficult for screen reader users to recover from since code doesn’t announce well, and they will have no idea what is going on. To account for an eventual system failure somewhere along the chain, you need to trap all of your system error conditions and put a nice error on the screen telling people what happened and why.

Good error “We are down for maintenance. System access should be restored by 9 am PST Saturday, January 30.”
Bad error: org.springframework.jdbc.BadSqlGrammarException: PreparedStatementCallback; bad SQL grammar [select cid, clinician-code, password, first-name, last-name from Clinician where clinician-code= ?]; nested exception is om.mysql.jdbc.exceptions.jdbc4. MySQLSyntaxErrorException: Unknown column ‘clinician’ in ‘field list’

Good documentation / Context-sensitive help

Nothing beats good documentation or context-sensitive help that is easy to find. Those tools help prevent errors, which is the ultimate goal, not account for them once they occur.

Conspicuous error message placement

Making an error message stand out is a good way of helping users recover from misuse. You can do this any number of ways, including:

Modal dialogs
Patterns
Colors
Larger / bolded text
Small amounts of movement (under 5 seconds)

Each approach listed above has accessibility considerations. Modal dialogs are preferred because, without focus management, screen reader users can quickly fall off a non-modal dialog without warning and not realize it. It is also important to note that if designers decide to place the error message next to the field that triggered the error, the field whose bad content caused the error can’t be covered.

Clear and straightforward error text copy

Error message text is not the place to get cute. “Oops, something went wrong” is not as nearly as useful as “Please enter a phone number.” Consider the two following error messages:

Material 3000078 mainly procured internally. Please check your purchase order and use code ME21N for internal procurement.
You asked to buy more paper, but we have it in stock. Click “OK” to continue with your order or “Cancel” if you want to use the paper we have. After canceling, re-enter the purchase order using code ME21N.

Note the plain language choices in the second example:

More straightforward language — “buy” instead of “procure.”
Using product names rather than requiring people to remember what codes correspond to what product.
Clear instructions — The second error tells the user what the OK and Cancel actions will do and how they can modify their order if they want to.

Could the error have been avoided altogether?

I hate entering a phone number, birthdate, or SSN and having the webpage give me an error, informing me it is in the wrong format. There are ZERO valid excuses for this. Fields with fixed formats should accept any input, as long as the number of digits and the range is correct. Do any necessary reformatting on the server side.

One of the things I hate more than that scenario is if I enter a phone number without the dashes, and not only does it give me an error, but it also wipes out all the rest of the data that was *correctly* entered on the form. That will hopefully no longer be considered compliant behavior in WCAG 3.0

Why is accounting for foreseeable misuse so essential for people with disabilities?

Now on to the accessibility part of this article.

People with disabilities make more mistakes.

The increased rate of mistakes happen for two reasons:

There is a middle layer between the user and the end product.

The user with a disability interacts with the assistive technology, and then the AT interacts with the software. That doubles the number of places things can go wrong.

2. Users’ disabilities may interfere with software interaction.

For example, a user might have a language-based disability, a memory problem, or fine motor skills issues that frequently cause them to enter incorrect data. Any of these can lead to an increased error rate.

OK, I get it, this is important. What WCAG guidelines pertain to error handling?

In addition to the general WCAG guidelines that apply to pretty much anything (colors, alt-text, keyboard behavior, sequence), the following WCAG 2.1 Level AA guidelines pertain to errors:

But, like bugs, the best error is the one that never occurs. Paying particular attention to these forms-related guidelines will help you prevent errors as well.