Inclusive

Every decision we make influences how information is presented in the world. Every presentation adds to the pattern. No matter how innocuous our organization, how lowly our title, how small our user base—every single one of us contributes, a little bit, to the way information is perceived.

Are we changing it for the better?

While it’s always been crucial to act ethically in the building of the web, our cultural climate now requires dedicated, individual conscientiousness. It’s not enough to think ourselves neutral, to dismiss our work as meaningless or apolitical. Everything is political. Every action, and every inaction, has an impact.

This seems like it could be a useful tool:

Increase your form conversions by fixing common usability issues

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.

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?

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:

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.

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.

What it does not do

Display content on mouse cursor hover.

View Toggletip demo on CodePen

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):

page

represents the current page within a set of pages;

step

represents the current step within a process;

location

represents the current location within an environment or context;

date

represents the current date within a collection of dates;

time

represents the current time within a set of times;

true

represents the current item within a set;

false

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:

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”.

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.

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:

This document explains the various ways of hiding things and the implications that come with that.

When we say an element is hidden, we usually mean it is not visible. However, the screen is not the only output mechanism we may need to hide content from. Systems like screen readers and braille displays rely on a document’s representation in the accessibility tree. For disambiguation we’ll use the following terms:

Completely hidden

The element is not rendered on screen, not exposed in the accessibility tree, not accessible to keyboard navigation.

Semantically hidden

The element is rendered on screen, but not exposed in the accessibility tree, and still accessible to keyboard navigation.

Visually hidden

The element is not rendered on screen, but exposed in the accessibility tree, and still accessible to keyboard navigation.

[…]

How to hide elements completely

Completely hiding elements can be done in 3 ways:

• via the CSS property display, e.g. display: none;
• via the CSS property visibility, e.g. visibility: hidden;
• via the HTML5 attribute hidden, e.g. <span hidden>

While each of these techniques has the same end result, i.e. content is not rendered and not exposed in the accessibility tree, they have different behaviors.

[…]

How to hide elements semantically

To hide content from the accessibility tree but retain the content on screen, we may use the attribute aria-hidden="true".

[…]

2016 edition of .visuallyhidden

[…]

• It works in all modern browsers including Internet Explorer 9 - 11.
• It side-steps the need to re-style everything for focusable elements such as skip-links.
• It accounts for the deprecated clip property.

Keyboard navigation

The techniques to hide elements only visually or semantically come with a caveat. Focusable elements like <a href="…"> remain keyboard navigatable, even though the element is not visible on screen or not exposed in the accessibility tree.

To make sure sighted keyboard users do not end up focusing elements they can’t see, and screen reader users not focusing element’s that don’t exist for them, we need to make sure that partially hidden content is not accessible to keyboard navigation using the Tab and Shift Tab keys. To accomplish this, we can add tabindex="-1" to the elements we want to hide from the keyboard.

Recap

• Use the hidden attribute to completely hide an element.
• Use the aria-hidden attribute to hide an element from the accessibility tree.
• Use the .visuallyhidden class to hide an element from the screen.
• Use visibility: inherit; instead of visibility: visible; to avoid accidentally showing content.
• Do not attach any CSS styles to the aria-hidden attribute.
• Take care of keyboard focusable content that is partially hidden by adding tabindex="-1".