Accessibility

Users Don't Hate Change. They Hate Our Design Choices.

For years, we studied teams rolling out new designs, to see if we could mitigate negative reaction to new releases and design changes. We studied hundreds of product and service rollouts. We watched and learned from the reactions of thousands of users.

When we dug into what those users’ reactions, patterns emerged. The users told us the changes inconvenienced them. They had no idea the change was coming and suddenly it was in their face. Users were upset because they were surprised.

They also told us the old version worked fine. Even when it took a while to get comfortable, they learned it. Many users mastered difficult-to-use designs.

Everything was different when the new version arrived. What they’d mastered before didn’t help them now. The company said it was an improved design, but they couldn’t see the improvements. Why should these users learn something new that doesn’t help them? Users were upset because they couldn’t see the value.

We also saw many instances where users didn’t react negatively to changes. Often, they didn’t react at all. We saw new designs that didn’t affect the users’ behaviors and they didn’t pay attention to it.

In these cases, the changes were often not noticeable. Sometimes the changes were small and isolated. Yet, we also saw users seemingly not notice several updates with extensive changes. (In more than one instance, an entire application’s infrastructure had been rewritten without a single user noticing.)

In cases when the design changes were noticeable, the designers gave the users control to switch when they wanted. The designers showed why the change was valuable to the users. And the designers made the transition easy by taking the knowledge and experience their users already had with the product into account.

Designing Accessible Content: Typography, Font Styling, and Structure

There are many design considerations for making your content more accessible to all. Some things to think about and build into your design workflow include:

  • Choose a common font that most users have encountered before.
  • The “serif vs. sans-serif debate” is not a huge deal if you choose a common font family or one that has unique characters.
  • Avoid specialty display fonts or font families that are not unique (ex. letters or numbers that could mirror each other).
  • Your fonts should have a minimum size of 14px (ideally more) and when coded should use relative values.
  • Pay attention to color and contrast! Use tools to check the ratio between the text and background and be wary of gray.
  • Don’t rely on color alone to signify information (ex. “click on the red button”).
  • Clearly define paragraph and letter spacing.
  • Do not let the overall width of the content exceed 80 characters (40 characters for logograms).
  • Avoid paragraph alignment (such as justified) which creates whitespace within the content.

Not Your Father's Navigation Strategy: There's More Than Just the TAB Key

As a blind screen reader user, and in my career educating designers, developers, and testers on accessibility issues, I have had the opportunity to observe the techniques used by various users to understand the layout and operation of web pages and applications. I have also seen well-intentioned sighted testers believe that components or entire sites are not accessible because they were unfamiliar with the techniques of navigating the web without sight.

In this article, I will walk you through the ways a blind screen reader user can navigate a web page, gather information about its layout and organization, and use that knowledge to efficiently and rapidly navigate a site or application. I hope to convey the importance of using techniques other than the TAB key as a primary means of navigating a website and illustrate the power you provide to a screen reader user by following semantic HTML markup and the principles of the Web Content Accessibility Guidelines.

Revisiting prefers-reduced-motion, the reduced motion media query

Two years ago, I wrote about prefers-reduced-motion, a media query introduced into Safari 10.1 to help people with vestibular and seizure disorders use the web. The article provided some background about the media query, why it was needed, and how to work with it to avoid creating disability-triggering visual effects.

The article was informed by other people’s excellent work, namely Orde Saunders’ post about user queries, and Val Head’s article on web animation motion sensitivity.

We’re now four months into 2019, and it makes me happy to report that we have support for the feature in all major desktop browsers! Safari was first, with Firefox being a close second. Chrome was a little late to the party, but introduced it as of version 74.

[…]

Reduce isn’t necessarily remove

We may not need to throw the baby out with the bathwater when it comes to using animation. Remember, it’s prefers-reduced-motion, not prefers-no-motion.

[…]

If the meaning of a component is diminished by removing its animation altogether, we could slow down and simplify the component’s animation to the point where the concept can be communicated without potentially being an accessibility trigger.

Reader Mode: The Button to Beat

A reminder of why reader modes exist in browsers and to embrace them as a user’s right:

Good design isn’t about forcing someone to walk a tightrope across your carefully manicured lawn. Nor is it a puzzle box casually tossed to the user, hoping they’ll unlock it to reveal a hidden treasure. Good design is about doing the hard work to accommodate the different ways people access a solution to an identified problem.

For reading articles, the core problem is turning my ignorance about an issue into understanding (the funding model for this is a whole other complicated concern). The more obstructions you throw in my way to achieve this goal, the more I am inclined to leave and get my understanding elsewhere—all I’ll remember is how poor a time I had while trying to access your content. What is the value of an ad impression if it ultimately leads to that user never returning?

Accessible websites are awesome websites

Today is Global Accessibility Awareness Day - a great day to be talking about accessibility.

[…]

Accessibility is for everyone, it’s not an edge case.

Accessibility is cumulative not binary, the more you do for accessibility the more accessible your site is.

Use semantic HTML, browsers have a lot of accessibility built in.

Make things keyboard operable by using the keyboard from time to time when you’re developing.

Finally, you don’t have to ask permission to make things accessible.

Allow Ctrl- and Shift-clicking links in event handlers

I just recently updated a bunch of my click handlers to not act when the Ctrl or Shift keys are pressed during the click, so that links can be opened in new tabs or windows by the user if so wanted:

Code language: JavaScript

// Don't do anything and defer to the default action if a modifier key
// was pressed during the click (to open the link in a new tab, window,
// etc.) - note that this is a truthy check rather than a strict check
// for the existence of and boolean true value of the various event
// properties:
// * https://ambientimpact.com/web/snippets/conditional-statements-and-truthy-values-robust-client-side-javascript
// * https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/ctrlKey
// * https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/shiftKey
if (event.ctrlKey || event.shiftKey) {
  return;
}

The Accessibility of Styled Form Controls & Friends

A repository of styled and “styled” form control patterns, and how they are announced by screen readers.

Why?

Form controls are necessary in many interfaces, but are often considered annoying, if not downright difficult, to style. Many of the markup patterns presented here can serve as a baseline for building more attractive form controls without having to exclude users who may rely on assistive technology to get things done.