Introducing A11y Dialog

Almost all projects involve some form of dialog window at one point or another. However, accessibility is all too often set aside in favor of quick implementation. Truth is, accessible dialog windows are hard. Very hard.

Fortunately, there is a super clever guy named Greg Kraus who implemented an accessible modal dialog a few years ago and open-sourced it on GitHub. Now that’s nice!

However, his version—no matter how good it is—requires jQuery. We try to avoid using jQuery as much as we can here. We realised we did not really need it most of the time. On top of that, his script is not very flexible: only one dialog window per page, hard-coded IDs inside the functions. Not very practical and certainly not a drop-in script for any project.

So I rolled up my sleeves and improved it.


The Reduced Motion Media Query

Sites all too often inundate their audiences with automatically playing, battery-draining, resource-hogging animations. The need for people being able to take back control of animations might be more prevalent than you may initially think.


Remember: we're all just temporarily-abled. Feeling a little dizzy might not seem like that big a deal, but that moment of nausea might be a critical one: losing balance and falling down, a migraine during an interview, nausea-triggered vomiting while working a food service job, passing out while operating a car UI, etc.

So what can we do about it?

Permalink to this heading.Enter a new Media Query

Safari 10.1 introduces the Reduced Motion Media Query. It is a non-vendor-prefixed declaration that allows developers to “create styles that avoid large areas of motion for users that specify a preference for reduced motion in System Preferences.”

The syntax is pretty straightforward:


@media (prefers-reduced-motion) {
  .background {
    animation: none;

Safari will parse this code and apply it to your site, letting you provide an alternative experience for users who have the Reduced Motion option enabled. Think of this new Media Query like @supports: describe the initial appearance, then modify the styles based on capability.


Toggletip widget pattern (tooltip alternative)

A screenshot of the Toggletip demo, with the Toggletip displayed. Please open in the CodePen link below to interact with the demo.

Permalink to this heading.What it does

  • Uses a real button as a control.
  • Places the displayed content next in DOM order after the button.
  • Uses some ARIA magic to augment the semantics and behaviour.
  • Displays or dismisses content on click, press or tap (also dismisses on esc key press).
  • Conveys state (collapsed or expanded) to AT users.
  • When initially displayed content is announced by (most) screen readers that support aria-live.
  • Screen readers users can also virtual cursor through and interact with the displayed content.
  • keyboard only users can interact with controls in the displayed content.

Permalink to this heading.What it does not do

Display content on mouse cursor hover.

View Toggletip demo on CodePen


Using the aria-current attribute

It is common on the web for the current thing in a collection to be highlighted visually, but providing an alternative for screen reader users has often involved something of a hack. The aria-current attribute is intended to solve this problem.


Here’s the official attribute definition:

Indicates the element that represents the current item within a container or set of related elements. The aria-current attribute is an enumerated type. Any value not included in the list of allowed values should be treated by assistive technologies as if the value true had been provided. If the attribute is not present or its value is an empty string, the default value of false applies and the aria-current state must not be exposed by user agents or assistive technologies.

According to the ARIA 1.1 specification, the aria-current attribute can be given one of a predefined set of values (enumerated tokens):

represents the current page within a set of pages;
represents the current step within a process;
represents the current location within an environment or context;
represents the current date within a collection of dates;
represents the current time within a set of times;
represents the current item within a set;
does not represent item within a set.

So the aria-current attribute can be used to solve the first use case in this post like this:


[aria-current] {
  font-weight: bold;
  background-color: #cc33ff;


<li><a href="/" aria-current="page">Home</a></li>
<li><a href="/">About</a></li>
<li><a href="/">Contact</a></li>

When a screen reader encounters the link identified with aria-current, it will announce something like “Home, current page link”.

Whenever aria-current is used with a value other than true, that information is incorporated into the screen reader announcement. For example in this set of steps, a screen reader will announce “Do this, current step link”.


<li><a href="/" aria-current="step">Do this</a></li>
<li><a href="/">Do that</a></li>
<li><a href="/">Do the other</a></li>


The Bias in What We Build

I’ve been thinking a lot lately about our biases and their influence on what we build and how. We’re all biased in some way—it’s an inevitable side-effect of living. We experience certain things, we live in a certain environment, we have certain interactions and over time all of these experiences and factors add up to impact the way we view ourselves and the way we view others.

These biases come into play over and over again in our work, and can have devastating consequences.

There was an interesting post on The Coral Project about anonymity and its impact—or rather, non-impact—on online behavior. A frequent refrain heard when we try to understand why online behavior is so frequently so poor is that the ability to be anonymous is one of the primary reasons for the problem. J. Nathan Matias argues differently, though:

Not only would removing anonymity fail to consistently improve online community behavior – forcing real names in online communities could also increase discrimination and worsen harassment.

We need to change our entire approach to the question. Our concerns about anonymity are overly-simplistic; system design can’t solve social problems without actual social change.

While the article cites a little bit of research questioning our assumptions about anonymity online, the bulk of the article is focused on reframing our perspective of the discussion. We often consider the question of bad behavior online from the perspective of the people misbehaving. What is it that makes them feel free to be so much more vindictive in an online setting? Matias instead builds his case by focusing on the victims of this behavior.

Revealing personal information exposes people to greater levels of harassment and discrimination. While there is no conclusive evidence that displaying names and identities will reliably reduce social problems, many studies have documented the problems it creates. When people’s names and photos are shown on a platform, people who provide a service to them – drivers, hosts, buyers – reject transactions from people of color and charge them more. Revealing marital status on DonorsChoose caused donors give less to students with women teachers, in fields where women were a minority. Gender- and race-based harassment are only possible if people know a person’s gender and/or race, and real names often give strong indications around both of these categories. Requiring people to disclose that information forces those risks upon them.


[O]ne thing we can state about removing anonymity is that it increases the risk for people on the receiving end of online harassment.

Removing anonymity online, then, is yet another example of how we reflect our own biases in the decisions we make and the things we build.

It is our biases that lead us to overlook accessibility or how an application performs on a low-powered device or spotty network.

It is our biases that lead us to develop algorithms that struggle to recognize women’s voices or show more high-paying executive jobs to men than women.

And it is our biases that lead us to frame the problem of online behavior from that of the attacker, leading to solutions that are dangerous for the people on the receiving end of that harassment.

In each of these situations, our biases don’t just lead us to build something that is hard to use; they cause us to actively, if unintentionally, exclude entire groups of people.


Roving tabindex for keyboard navigation around JavaScript widgets

Setting the tabindex of the focused element to "0" ensures that if the user tabs away from the widget and then returns, the selected item within the group retains focus. Note that updating the tabindex to "0" requires also updating the previously selected item to tabindex="-1". This technique involves programmatically moving focus in response to key events and updating the tabindex to reflect the currently focused item. To do this:

Bind a key down handler to each element in the group, and when an arrow key is used to move to another element:

  1. programmatically apply focus to the new element,
  2. update the tabindex of the focused element to "0", and
  3. update the tabindex of the previously focused element to "-1".

Here's an example of a WAI-ARIA tree view using this technique.

For a more visual explanation, see the following video by Rob Dodson: