Stress cases

The HTML5 specification uses a wonderful set of rules to decide who is correct when there’s a conflict of interest between different stakeholders. This document is for people who come up with new features for the web. This is the hierarchy they use.

  1. End user
  2. Designer
  3. Browser maker
  4. Person who specifies the feature
  5. Theoretical purity

This so called priority of constituencies1 can be used on a smaller level as well. When we look at the end user only — the one who is always right according to the HTML5 spec. That’s not a single person. There’s a wide range of users who sometimes seem to have conflicting interests as well.

Setting priorities

For instance, when you look at the different users who need to get a clear hierarchical overview of a webpage: who will have the most difficulty getting this overview? Let’s make this a simple binary choice between sighted users and people who are blind.

The sighted user can immediately see all kinds of visual clues. Within a fraction of a second things like font size, white space, colour, ratios, gestalt, help in understanding where an article starts, how long it is, and what else is on the page. This doesn’t just help them in understanding the structure of the page, it makes it possible to simply ignore the things that don’t matter, like banners, sidebars and navigations.

There are no visual clues for screen reader users. They have to use tools like reading out all headlines to get an idea of the table of contents of the page.

This is a much more active method of getting a sense of hierarchy. Comparing this to the immediate sense of hierarchy a sighted user gets, we can agree that it’s probably harder for the blind person to get a clear overview of the page. If we use this conclusion for our priority of constituencies, this would mean we should prioritise blind people in this case.

On the other hand, Léonie Watson pointed out to me in an email that this hierarchical overview that screen reader users get by listening to the heading level structure, is something that sighted users do not get.

Perhaps a different question is this: if no-one was ever able to see (if we were all blind), how would we think about accomplishing this goal? One approach we use in print is a table of contents. I don’t actually recommend this so much for websites (though it works for your thesis), but hopefully it illustrates one way in which we give people a holistic sense of a larger thing without actually being able to see it all?

Possible priorities

There are all kinds of different users to consider, and in different situations the order of priorities changes. For instance, keyboard users are not always first priority: Filling in a form is easier for someone who use a keyboard on a desktop computer than for someone who uses a touch device. On a desktop computer there is much more space, so it’s easier to keep a good overview of the context of the form. This is much harder on a small device, so extra attention to this design is needed.

Here are a few possible priorities of constituencies for different types of patterns.

Navigating a webpage
Blind person non blind
Typing something into a textfield
Touch user keyboard user
Controlling an interactive element, like the date picker gantt chart.
Keyboard user Mouse user
Blind user visual user
A Podcast
Deaf person non deaf
An illustrative animation
Blind person non-blind
Reading a long article
Sighted user screen reader user

Setting clear priorities of constituencies could be used as a tool for achieving what Kat Holmes calls the first step in inclusive design: recognise exclusion.

Stress case design

Sara Wachter-Boettcher and Eric Meyer call this type of design stress case design, which they use as an antidote of edge case design.2 They explain that instead of focusing on the imaginary average persona, we should focus on people who will visit your website in stressful situations.

Ironically, working with edge-cases in software engineering is a method where the extremes are actively tested to see. What happens when someone fills in an extremely long name, or an incredibly high number? By testing these edge cases you make sure the application still works in extreme situations.

Somehow in the web design world the term edge case design turned into the exact opposite, and thus became an exclusion habit. Or in the more strong words of Wachter-Boettcher and Meyer:

[Design team:] We’re designing for the 90%, not the 10%. That’s classic edge-case thinking: a shorter way of saying, That’s a difficult use case that I don’t want to think about.

Using a word like stress case instead of edge case may help. You don’t want to let down the people who visit your website under stress. On the contrary, these are the people you want to help in the first place.

If we want to design for stress cases we need to take the second Exclusive Design Principle at heart: ignore conventions, stop copying, and start designing.


  1. Anne van Kesteren, Maciej Stachowiak. HTML Design Principles. 2009. dev.w3.org/html5/html-design-principles/  ↩

  2. Sara Wachter-Boettcher and Eric Meyer, Design for Real Life, A Book Apart Publishers, New York, ePub Edition, 2016  ↩