Latest

Behind the Code — Google Slash Design Accessibility

We at Instrument recently helped Google design and develop a new iteration of the Google Design website. One of the biggest challenges in this project was making sure both the design and development met the WCAG 2.0 AA level of accessibility for people with low vision or those using any assistive technology.

Where do we start?

While this was not our first project with strong accessibility considerations, we're still fairly new to making accessibility a primary focus of design and development. We decided to take an iterative approach that would allow us to refine our design and code over time. On-going reviews with our external accessibility experts allowed our designers and developers to continue learning and improving throughout the process. This also helped ensure we were catching potentially negative side effects as new code and design were added.

Starting at design

During the initial design phase we repeatedly checked to make sure our color contrast ratio was at least 3:1 across the site. This is the minimum recommended level by the W3C Working Group. Due to this site's purpose being a source for visual design reference and inspiration, we felt it was acceptable not to target a stronger color contrast level.

During the design process, development was involved in calling out any proposed features that would either require too much time or wouldn't be possible to make accessible. Modal interface elements are notoriously bad for accessibility because of how easily it can confuse a screen reader about the current state of a page. Someone using a screen reader may not realize a modal has been activated and not see any additional information, or they could be locked into the modal with no easy or clear way to return to the rest of the page's content. Whenever we encountered a design element that was problematic like this, we either removed or redesigned it.

What's nice about filtering out inaccessible design elements is you end up improving your design for visually-abled users as well. You'll often find this removes unimportant and superfluous elements that make it more difficult to engage with your content.

Accessible development

Visual accessibility is a fairly straightforward concept to grasp. What does the design look like when someone is color blind? What about to someone who can't read smaller text easily? There are a variety of tools to assist in measuring this kind of information including in-browser plugins. Just search for "color contrast tools" for your browser of choice.

What happens when you begin to account for screen reader technology? Screen readers were our other primary focus when building google.com/design to be accessible. Thankfully, there's already an established spec for building accessible web content called Accessible Rich Internet Applications, commonly referred to as ARIA. Modern browsers widely support functionality provided by ARIA so polyfills generally are not necessary.

Digging in with ARIA

Development for screen readers is deceptively complex. On its surface, you may just assume that the contents of your page will be spoken aloud and the key checkboxes to tick off include making sure that all `<img>` tags have alt text. What happens when you add interactive elements with multiple states? What about more complicated design that doesn't read well outside of a visual context?

That context is an important factor. Visually, content may have an immediately apparent purpose but it may not be apparent when it's just words being spoken. A perfect example of this is on the home page of Google Design. The visual layout is a collection of content blocks. They could be an article, a video, or a social media post. When seeing it, it's understandable as a collection of a variety of content types. When reading through the page linearly, more context is needed. If you choose to look in the source, you'll see something similar to the following:

Some markup and classes have been removed for this example in order to call out some specific details that target screen readers. We chose to wrap each content block in a list item inside an unordered list. This establishes that the context is a single item in a list of content where the hierarchy and order the content is not critical. Inside each list item, preceding each piece of content, is a `<span>` with text that identifies the type of content to follow.

A `<span>` was chosen because it implies no semantic meaning like a heading, and you'll notice that this `<span>` has an id of `type-41` as well as a class of `-off-screen`. First, I'll call out the class name. In a visual context, this description of 'Article' is unnecessary to display and we hide it off screen, but it will still be able to be read by a screen reader. As for the id, that ties into the fact that the whole block of content is wrapped in an `<a>` tag.

Because the content of this anchor is a nested set of markup, we have to provide context about this content to the screen reader. The anchor tag has multiple ARIA attributes to assist with this. The first is `aria-labelledby`, which associates it with any ids containing text about the title and other relevant meta-data for the content. In this case, it references our `<span>` that says it's an article as well as the title of the content block. The second aria attribute used here is `aria-describedby`, which tells the screen reader the description of the link's content.

You will also notice a couple tags that have an attribute of `aria-hidden="true"`. Tags with this attribute will not be read by screen readers which lets us hide content or visuals that are purely aesthetic and don't provide any critical information. The paragraph that says "Article / Tutorial" is used as a design element rather than informational, and because we already provide an accessible content label of "Article", leaving it available for screen readers causes confusion.

The end result of all of this structure is when a screen reader reaches this piece of content in the page, it reports that it's a list item containing a linked article with a title of "Design from iOS to Android (and Back Again)" and diving in deeper will provide a description of "A quick and easy guide to designing between platforms and staying sane."

Without this accessible structure, someone may have no easy way to know what's linked prior to visiting the linked URL.

Accessible interaction

Another complex part of developing for accessibility is interaction that causes UI and/or content to change state on the current page. An example could be a drop-down menu or a slideshow. With these kinds of interactions, it's important to let screen readers know both when something has changed and which part has changed. Depending on the type of UI involved, you may also need to put in restrictions on what content is available to read depending on the state of the UI. For instance, you may not want someone to be able to read through all available slides of a slideshow when only the currently active slide should be available. The solution is to prevent keyboard access on and to prevent a screen reader from reading any elements that are hidden visually and should not currently be presented to a user.

To provide more detail on these kinds of accessible interactions we'll reference the social share menu functionality from the detail pages on google.com/design. You can see this in use as a floating action button [FAB] on http://www.google.com/design/articles/welcome-to-the-new-google-design/. The visual interaction is basic: click the button and a menu expands. Click it again and it collapses.

Let's first take a look at a simplified version of the markup involved with the share FAB:

It's important to note that we are using a `<button>` as the element to trigger opening the FAB menu. In the past, this kind of control was most often an anchor link since that's what is usually associated with a clickable element. However, we're not sending anyone to a new page or otherwise updating the URL or history stack which makes `<button>` the appropriate element for this interactive control. Buttons are also great because they come with ARIA features already built-in. Notice we have an attribute of `aria-controls` set to `fab-content`. This lets screen readers know the element with the id of `fab-content` is what the button affects when activated. Because the appearance of the button involves using iconography and no text, we've included another `<span>` with an `-off-screen` class to make sure screen readers can interpret its purpose.

The other key attribute used on the button is `aria-expanded`. By default it is set to `false` which indicates that the element the button controls is not currently expanded. Using JavaScript, when the button is clicked, tapped, or activated via a keystroke we set this attribute to `true`. Now a screen reader will know that the `fab-content` element is expanded and intended to be read and can inform the user of this updated state. To make sure that reading the content is possible, we set the `aria-hidden` attribute on the content to be `false`. If the button is activated again we change `aria-expanded` on the button back to `false` to indicate the menu is collapsed again and set `aria-hidden` back to `true` to prevent reading the content out of context.

For the anchor links inside of the content element, we have `tabindex="-1"` applied as the default state. Setting `tabindex` to a negative value prevents the links from being focusable by keyboard tabbing through content. Because we want these links to be tabbable while the menu is active, we remove the `tabindex` attribute entirely when the menu expands, and re-apply it again on collapsing.

Following up

We're still not experts on accessible design and development, but we're getting better. We spent a lot of time consulting our accessibility experts to make sure that we built our components correctly and confirm they worked as intended. The design and development efforts are definitely higher when adding accessibility to the plate, but this increased time budget will likely reduce as we continue to improve our knowledge base and develop reusable components.

The first step you can take in making your site more accessible is to empathize and attempt to mentally put yourself into the position of a lesser-abled user. What happens if you can't see? What happens if you have no mouse available? Think outside the bounds of the standard interaction and design models. Pew Research reported in 2011 that Fifty-four percent of adults living with a disability use the internet and I would not be surprised if that number continues to grow with the ever-increasing access to technology and the Internet. It's easy to forget that not everyone can use the same tools to browse online, but they can be a huge part of your audience.

The code examples provided only illustrate a small piece of what's required for building accessible sites and there's lots of information available online. If you'd like to learn more about how to use ARIA features, Mozilla's developer docs are a very helpful starting point.

 

Written by Brian Hefter, Senior Developer

Related