Rob Dodson on web.dev

Accessible tap targets

2020-03-31T00:00:00Z

When your design is displayed on a mobile device, you should ensure that interactive elements like buttons or links are large enough, and have enough space around them, to make them easy to press without accidentally overlapping onto other elements. This benefits all users, but is especially helpful for anyone with a motor impairment.

A minimum recommended touch target size is around 48 device independent pixels on a site with a properly set mobile viewport. For example, while an icon may only have a width and height of 24px, you can use additional padding to bring the tap target size up to 48px. The 48x48 pixel area corresponds to around 9mm, which is about the size of a person's finger pad area.

In the demo, I have added padding to all of the links in order to make sure they meet the minimum size.

Touch targets should also be spaced about 8 pixels apart, both horizontally and vertically, so that a user's finger pressing on one tap target does not inadvertently touch another tap target.

Testing your touch targets #

If your target is text and you have used relative values such as em or rem to size the text and any padding, you can use DevTools to check that the computed value of that area is large enough. In the example below I am using em for my text and padding.

Inspect the a of the link, and in Chrome DevTools switch to the Computed pane where you can inspect the various parts of the box and see what pixel size they resolve to. In Firefox DevTools there is a Layout Panel. In that Panel you get the actual size of the inspected element.

Using media queries to detect touchscreen use #

Instead of simply testing for viewport dimensions, and then guessing that small dimensions are likely to be phones or tablets, which in turn use a touchscreen, there are now more robust ways to adapt your design based on actual device capabilities.

One of the media features we can now test for with media queries is whether the user's primary input is a touchscreen (pointer) and whether any of the currently detected inputs is a touchscreen (any-pointer). The pointer and any-pointer features will return fine or coarse. A fine pointer will be someone using a mouse or trackpad, even if that mouse is connected via Bluetooth to a phone. A coarse pointer indicates a touchscreen, which could be a mobile device but may also be a laptop screen or large tablet.

If you are adjusting your CSS within a media query to increase the touch target, testing for a coarse pointer allows you to increase the tap targets for all touchscreen users. This gives the larger tap area whether the device is a phone or larger device.

.container a {
  padding: .2em;
}

@media (any-pointer: coarse) {
  .container a {
    padding: .8em;
  }
}

You can find out more about interaction media features such as pointer in the Responsive web design basics article.

Accessible responsive design

2020-03-31T00:00:00Z

We know that it's a good idea to design responsively to provide the best multi-device experience, but responsive design also yields a win for accessibility.

Consider a site like Udacity:

A low-vision user who has difficulty reading small print might zoom in the page, perhaps as much as 400%. Because the site is designed responsively, the UI will rearrange itself for the "smaller viewport" (actually for the larger page), which is great for desktop users who require screen magnification and for mobile screen reader users as well. It's a win-win. Here's the same page magnified to 400%:

In fact, just by designing responsively, we're meeting rule 1.4.4 of the WebAIM checklist, which states that a page "… should be readable and functional when the text size is doubled."

Going over all of responsive design is outside the scope of this guide, but here are a few important takeaways that will benefit your responsive experience and give your users better access to your content.

Use the viewport meta tag #

<meta name="viewport" content="width=device-width, initial-scale=1.0">

Setting width=device-width will match the screen's width in device-independent pixels, and setting initial-scale=1 establishes a 1:1 relationship between CSS pixels and device-independent pixels. Doing this instructs the browser to fit your content to the screen size, so users don't just see a bunch of scrunched-up text.

See Size content to viewport to learn more.

Allow users to zoom #

It is possible to use the viewport meta tag to prevent zooming, by setting maximum-scale=1 or user-scaleable=no. Avoid doing this, and let your users zoom in if they need to.

Design with flexibility #

Avoid targetting specific screen sizes and instead use a flexible grid, making changes to the layout when the content dictates. As we saw with the Udacity example above, this approach ensures that the design responds whether the reduced space is due to a smaller screen or a higher zoom level.

You can read more about these techniques in the Responsive web design basics article.

Use relative units for text #

To get the best out of your flexible grid use relative units like em or rem for things like text size, instead of pixel values. Some browsers support resizing text only in user preferences, and if you're using a pixel value for text, this setting will not affect your copy. If, however, you've used relative units throughout, then the site copy will update to reflect the user's preference.

This will enable the whole site to reflow as the user zooms, creating the reading experience they need to use your site.

Avoid disconnecting the visual view from the source order #

A visitor who is tabbing through your site with the keyboard will be following the order of the content in the HTML document. When using modern layout methods such as Flexbox and Grid, it is easy to make the visual rendering not match the source order. This can lead to disconcerting jumps around the page for someone using the keyboard to move around.

Make sure to test your design at each breakpoint by tabbing through the content, does the flow through the page still make sense?

Take care with spatial clues #

When writing microcopy avoid using language which indicates the location of an element on the page. For example, referring to navigation "on your left" makes no sense in a mobile version when the navigation is at the top of the screen.

Ensure tap targets are large enough on touchscreen devices #

On touchscreen devices make sure your tap targets are large enough to make them easy to activate without hitting other links. A good size for any tappable element is 48px, read more guidance on tap targets.

Color and contrast accessibility

2020-03-31T00:00:00Z

If you have good vision, it's easy to assume that everyone perceives colors, or text legibility, the same way you do—but of course that's not the case.

As you might imagine, some color combinations that are easy for some people to read are difficult or impossible for others. This usually comes down to color contrast, the relationship between the foreground and background colors' luminance. When the colors are similar, the contrast ratio is low; when they are different, the contrast ratio is high.

The WebAIM guidelines recommend an AA (minimum) contrast ratio of 4.5:1 for all text. An exception is made for very large text (120-150% larger than the default body text), for which the ratio can go down to 3:1. Notice the difference in the contrast ratios shown below.

The contrast ratio of 4.5:1 was chosen for level AA because it compensates for the loss in contrast sensitivity usually experienced by users with vision loss equivalent to approximately 20/40 vision. 20/40 is commonly reported as typical visual acuity of people at about age 80. For users with low vision impairments or color deficiencies, we can increase the contrast up to 7:1 for body text.

You can use the Accessibility Audit in Lighthouse to check your color contrast. Open DevTools, click Audits, and select Accessibility to run the report.

Chrome also includes an experimental feature to help you detect all the low contrast texts of your page. You can also use the accessible color suggestion to fix the low contrast text.

For a more complete report, install the Accessibility Insights Extension. One of the checks in the Fastpass report, is color contrast. You will get a detailed report of any failing elements.

Advanced Perceptual Contrast Algorithm (APCA) #

The Advanced Perceptual Contrast Algorithm (APCA) is a new way to compute contrast based on modern research on color perception.

Compared to AA/AAA guidelines, APCA is more context-dependent.

The contrast is calculated based on the following features:

Spatial properties (font weight and text size)
Text color (perceived lightness difference between text and background)
Context (ambient light, surroundings, and intended purpose of the text)

Chrome includes an experimental feature to replace the AA/AAA contrast ratio guidelines with APCA.

Don't convey information with color alone #

There are roughly 320 million people worldwide with color vision deficiency. About 1 in 12 men and 1 in 200 women have some form of "color blindness"; that means about 1/20th, or 5%, of your users will not experience your site the way you intended. When we rely on color to convey information, we push that number to unacceptable levels.

For example, in an input form, a telephone number might be underlined in red to show that it is invalid. But to a color deficient or screen reader user, that information is not conveyed well, if at all. Thus, you should always try to provide multiple avenues for the user to access critical information.

The WebAIM checklist states in section 1.4.1 that "color should not be used as the sole method of conveying content or distinguishing visual elements." It also notes that "color alone should not be used to distinguish links from surrounding text" unless they meet certain contrast requirements. Instead, the checklist recommends adding an additional indicator such as an underscore (using the CSS text-decoration property) to indicate when the link is active.

An easy way to fix the previous example is to add an additional message to the field, announcing that it is invalid and why.

When you're building an app, keep these sorts of things in mind and watch out for areas where you may be relying too heavily on color to convey important information.

If you're curious about how your site looks to different people, or if you rely heavily on the use of color in your UI, you can use DevTools to simulate various forms of visual impairment, including different types of color blindness. Chrome includes an Emulate Vision Deficiencies feature. To access it open DevTools and then open the Rendering tab in the Drawer, you can then emulate the following color deficiencies.

Protanopia: the inability to perceive any red light.
Deuteranopia: the inability to perceive any green light.
Tritanopia: the inability to perceive any blue light.
Achromatopsia: the inability to perceive any color except for shades of grey (extremely rare).

High contrast mode #

High-contrast mode allows a user to invert foreground and background colors, which often helps text stand out better. For someone with a low vision impairment, high-contrast mode can make it much easier to navigate the content on the page. There are a few ways to get a high-contrast setup on your machine.

Operating systems like Mac OSX and Windows offer high-contrast modes that can be enabled for everything at the system level.

A useful exercise is to turn on high-contrast settings and verify that all of the UI in your application is still visible and usable.

For example, a navigation bar might use a subtle background color to indicate which page is currently selected. If you view it in a high-contrast extension, that subtlety completely disappears, and with it goes the reader's understanding of which page is active.

Similarly, if you consider the example from the previous lesson, the red underline on the invalid phone number field might be displayed in a hard-to-distinguish blue-green color.

If you are meeting the contrast ratios covered earlier you should be fine when it comes to supporting high-contrast mode. But for added peace of mind, consider installing the High Contrast Chrome Extension and giving your page a once-over just to check that everything works, and looks, as expected.

An example blog post used for screenshot testing.

2019-10-31T00:00:00Z

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin dictum a massa sit amet ullamcorper. Suspendisse auctor ultrices ante, nec tempus nibh varius at. Cras ligula lacus, porta vitae maximus a, ultrices a mauris. Vestibulum porta dolor erat, vel molestie dolor posuere in. Nam vel elementum augue. Nam quis enim blandit, posuere justo dignissim, scelerisque diam. Fusce aliquet urna ac blandit ullamcorper. Proin et semper nibh, sit amet imperdiet velit. Morbi at quam sem. Integer et erat ac mi scelerisque suscipit et vitae nulla. Aliquam scelerisque efficitur ante ut facilisis. Aenean et risus fringilla, hendrerit sapien et, tincidunt orci. Aenean sed tellus aliquam, consectetur metus in, tempus enim.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin dictum a massa sit amet ullamcorper. Suspendisse auctor ultrices ante, nec tempus nibh varius at. Cras ligula lacus, porta vitae maximus a, ultrices a mauris. Vestibulum porta dolor erat, vel molestie dolor posuere in. Nam vel elementum augue. Nam quis enim blandit, posuere justo dignissim, scelerisque diam. Fusce aliquet urna ac blandit ullamcorper. Proin et semper nibh, sit amet imperdiet velit. Morbi quam sem. Integer et erat ac mi scelerisque suscipit et vitae nulla. Aliquam scelerisque efficitur ante ut facilisis. Aenean et risus fringilla, hendrerit sapien et, tincidunt orci. Aenean sed tellus aliquam, consectetur metus in, tempus enim.

Large image.

Small image.

Image, Inline #

Inline right, outlined image.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin dictum a massa sit amet ullamcorper. Suspendisse auctor ultrices ante, nec tempus nibh varius at. Cras ligula lacus, porta vitae maximus a, ultrices a mauris. Vestibulum porta dolor erat, vel molestie dolor posuere in. Nam vel elementum augue. Nam quis enim blandit, posuere justo dignissim, scelerisque diam. Fusce aliquet urna ac blandit ullamcorper. Proin et semper nibh, sit amet imperdiet velit. Morbi at quam sem. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin dictum a massa sit amet ullamcorper. Suspendisse auctor ultrices ante, nec tempus nibh varius at. Cras ligula lacus, porta vitae maximus a, ultrices a mauris. Vestibulum porta dolor erat, vel molestie dolor posuere in. Nam vel elementum augue. Nam quis enim blandit, posuere justo dignissim, scelerisque diam. Fusce aliquet urna ac blandit ullamcorper. Proin et semper nibh, sit amet imperdiet velit. Morbi at quam sem.

Inline left, outlined image.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin dictum a massa sit amet ullamcorper. Suspendisse auctor ultrices ante, nec tempus nibh varius at. Cras ligula lacus, porta vitae maximus a, ultrices a mauris. Vestibulum porta dolor erat, vel molestie dolor posuere in. Nam vel elementum augue. Nam quis enim blandit, posuere justo dignissim, scelerisque diam. Fusce aliquet urna ac blandit ullamcorper. Proin et semper nibh, sit amet imperdiet velit. Morbi at quam sem. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin dictum a massa sit amet ullamcorper. Suspendisse auctor ultrices ante, nec tempus nibh varius at. Cras ligula lacus, porta vitae maximus a, ultrices a mauris. Vestibulum porta dolor erat, vel molestie dolor posuere in. Nam vel elementum augue. Nam quis enim blandit, posuere justo dignissim, scelerisque diam. Fusce aliquet urna ac blandit ullamcorper. Proin et semper nibh, sit amet imperdiet velit. Morbi at quam sem.

Filled screenshot.

Table 1 — Imagemin plugins for filetypes.
Image Format	Lossy Plugin(s)	Lossless Plugin(s)
JPEG	imagemin-mozjpeg	imagemin-jpegtran
PNG	imagemin-pngquant	imagemin-optipng
GIF	imagemin-giflossy	imagemin-gifsicle
SVG	Imagemin-svgo
WebP	imagemin-webp

Ordered list #

Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin dictum a massa sit amet ullamcorper.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin dictum a massa sit amet ullamcorper.

Filled screenshot.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin dictum a massa sit amet ullamcorper.

Unordered list #

Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin dictum a massa sit amet ullamcorper.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin dictum a massa sit amet ullamcorper.

Filled screenshot.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin dictum a massa sit amet ullamcorper.

const imagemin = require("imagemin");
const imageminMozjpeg = require("imagemin-mozjpeg");

(async () => {
  const files = await imagemin(
    ["source_dir/*.jpg", "another_dir/*.jpg"],
    "destination_dir",
    { plugins: [imageminMozjpeg({ quality: 50 })] }
  );
  console.log(files);
})();

const imagemin = require('imagemin');
const imageminMozjpeg = require('imagemin-mozjpeg');

(async() => {
  const files = await imagemin(
      ['source_dir/*.jpg', 'another_dir/*.jpg'],
      'destination_dir',
      {plugins: [imageminMozjpeg({quality: 50})]}
  );
  console.log(files);
})();

const imagemin = require('imagemin');
const imageminMozjpeg = require('imagemin-mozjpeg');

(async() => {
  const files = await imagemin(
      ['source_dir/*.jpg', 'another_dir/*.jpg'],
      'destination_dir',
      {plugins: [imageminMozjpeg({quality: 50})]}
  );
  console.log(files);
})();

const imagemin = require('imagemin');
const imageminMozjpeg = require('imagemin-mozjpeg');

(async() => {
  const files = await imagemin(
      ['source_dir/*.jpg'],
      ['source_dir/*.jpg', 'another_dir/*.jpg'],
      'destination_dir',
      {plugins: [imageminMozjpeg({quality: 50})]}
  );
  console.log(files);
})();

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin dictum a massa sit amet ullamcorper.
by Jon Doe

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin dictum a massa sit amet ullamcorper.

by Jon Doe

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin dictum a massa sit amet ullamcorper.

Jon Doe

See the Pen Pen GRroyyX by robdodson on Codepen

Small image.

Don't

Bad code example

Explanation of why example is bad.

Good code example

Explanation of why example is good.

30_%

Lower cost per conversion

13_%

Higher CTR

4_x

Faster load times

Download case study

[No demo found at /demos/url-parts/.]

Details summary

This is an optional preview. Make your preview text match the first paragraph of your panel text.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin dictum a massa sit amet ullamcorper. Suspendisse auctor ultrices ante, nec tempus nibh varius at.

Details summary

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin dictum a massa sit amet ullamcorper. Suspendisse auctor ultrices ante, nec tempus nibh varius at.

Test of Aside nested in an ordered list #

See the underlying issue.

First item. Another line.
Second item.

This is an <aside>, including Markdown.
Third item.

Control focus with tabindex

2018-11-18T00:00:00Z

Standard HTML elements such as <button> or <input> have keyboard accessibility built in for free. If you're building custom interactive components, however, use the tabindex attribute to ensure that they're keyboard accessible.

Check if your controls are keyboard accessible #

A tool like Lighthouse is great at detecting certain accessibility issues, but some things can only be tested by a human.

Try pressing the Tab key to navigate through your site. Are you able to reach all the interactive controls on the page? If not, you may need to use tabindex to improve the focusability of those controls.

Insert an element into the tab order #

Insert an element into the natural tab order using tabindex="0". For example:

<div tabindex="0">Focus me with the TAB key</div>

To focus an element, press the Tab key or call the element's focus() method.

See the Pen Pen XWzzMqp by web-dot-dev on Codepen

Remove an element from the tab order #

Remove an element using tabindex="-1". For example:

<button tabindex="-1">Can't reach me with the TAB key!</button>

This removes an element from the natural tab order, but the element can still be focused by calling its focus() method.

See the Pen Pen BammWGg by web-dot-dev on Codepen

Note that applying tabindex="-1" to an element doesn't affect its children; if they're in the tab order naturally or because of a tabindex value, they'll remain in the tab order. To remove an element and all its children from the tab order, consider using the WICG's inert polyfill. The polyfill emulates the behavior of a proposed inert attribute, which prevents elements from being selected or read by assistive technologies.

Avoid `tabindex > 0` #

Any tabindex greater than 0 jumps the element to the front of the natural tab order. If there are multiple elements with a tabindex greater than 0, the tab order starts from the lowest value greater than zero and works its way up.

Using a tabindex greater than 0 is considered an anti-pattern because screen readers navigate the page in DOM order, not tab order. If you need an element to come sooner in the tab order, it should be moved to an earlier spot in the DOM.

Lighthouse makes it easy to identify elements with a tabindex > 0. Run the Accessibility Audit (Lighthouse > Options > Accessibility) and look for the results of the "No element has a [tabindex] value greater than 0" audit.

Create accessible components with "roving `tabindex`" #

If you're building a complex component, you may need to add additional keyboard support beyond focus. Consider the built-in select element. It is focusable and you can use the arrow keys to expose additional functionality (the selectable options).

To implement similar functionality in your own components, use a technique known as "roving tabindex". Roving tabindex works by setting tabindex to -1 for all children except the currently-active one. The component then uses a keyboard event listener to determine which key the user has pressed.

When this happens, the component sets the previously focused child's tabindex to -1, sets the to-be-focused child's tabindex to 0, and calls the focus() method on it.

Before

<div role="toolbar">
  <button tabindex="-1">Undo</button>
  <button tabindex="0">Redo</button>
  <button tabindex="-1">Cut</button>
</div>

After

<div role="toolbar">
  <button tabindex="-1">Undo</button>
  <button tabindex="-1">Redo</button>
  <button tabindex="0">Cut</button>
</div>

See the Pen Pen LYOOWam by web-dot-dev on Codepen

Test your knowledge of tab order

This HTML renders a modal dialog:

<div role="dialog" aria-labelledby="dialog-header">
  <button aria-label="Close"></button>
  <h2 id="dialog-header">
    Do you want to allow notifications from this website?
  </h2>
  <button>No</button>
  <button>Yes</button>
</div>

What is the tab order for the elements in the sample?

The Close button
The No button
The Yes button

Only the <button> elements are included in the tab order because they're the only standardized HTML form elements. To insert other elements into the tab order, you would add a tabindex attribute.

<section tabindex="-1">
  <h2>Cat facts</h2>
  <ul>
    <li>A group of cats is called a <a href="https://m-w.com/dictionary/clowder">clowder</a>.</li>
    <li>Most cats are <a href="https://www.catfacts.org/catnip.html"> unaffected by catnip</a>.</li>
  </ul>
</section>

Which elements from the sample are included in the tab order?

Only the <a> elements are included in the tab order.

The <section> element is not in the tab order because it has a negative tabindex value. (It can, however, be focused using the focus() method.) The tabindex value for the <section> element doesn't affect its children.

This HTML renders a popup menu followed by a search input:

<div role="menu" tabindex="0">
  <a role="menuitem" href="/learn/" tabindex="-1">Learn</a>
  <a role="menuitem" href="/measure/" tabindex="-1">Measure</a>
  <a role="menuitem" href="/blog/" tabindex="-1">Blog</a>
  <a role="menuitem" href="/about/" tabindex="-1">About</a>
</div>
<input tabindex="1" type="text" role="search" aria-label="Search" placeholder="Search">

Which element in the sample comes first in the tab order?

The Search text input comes first in the tab order. Because it has a tabindex greater than zero, it jumps to the front of the tab order.

(This behavior is likely to cause confusion if the menu is positioned on the page before the search input. This is an example of why having a tabindex value greater than zero is considered an anti-pattern.)

This HTML renders a custom radio group, which should have a roving tabindex. (To keep things simpler, ignore the aria-* attributes for now.)

<div role="radiogroup" aria-labelledby="breed-header">
  <h3 id="breed-header">Your cat's breed</h3>
  <div role="radio" aria-checked="false" tabindex="0">Persian</div>
  <div role="radio" aria-checked="false" tabindex="-1">Bengal</div>
  <div role="radio" aria-checked="false" tabindex="-1">Maine Coon</div>
</div>

When a role="radio" element is focused, what should happen when a user presses the Right arrow key?

Change the tabindex values for all radio elements in the group to -1.
If there's a radio element after the one that's focused, set its tabindex value to 0.
If there's no radio element after the one that's focused, set the tabindex value of the first radio element in the group to 0.
Focus the radio element that now has a tabindex of 0.

That's a lot—and it doesn't even include ARIA attributes! This is an example of why it's easier to use built-in elements with built-in keyboard behavior whenever you can.

Keyboard access recipes #

If you're unsure what level of keyboard support your custom components might need, you can refer to the ARIA Authoring Practices 1.1. This handy guide lists common UI patterns and identifies which keys your components should support.

Headings and landmarks

2018-11-18T00:00:00Z

Screen readers have commands to quickly jump between headings or to specific landmark regions. In fact, a survey of screen reader users found that they most often navigate an unfamiliar page by exploring the headings.

By using correct heading and landmark elements, you can dramatically improve the navigation experience on your site for users of assistive technologies.

Use headings to outline the page #

Use h1-h6 elements to create a structural outline for your page. The goal is to create a skeleton or scaffold of the page such that anyone navigating by headings can form a mental picture.

A common practice is to use a single h1 for the primary headline or logo on a page, h2 elements to designate major sections, and h3 elements in supporting subsections:

<h1>Company name</h1>
<section>
  <h2>Section Heading</h2>
  …
  <h3>Sub-section Heading</h3>
</section>

Don't skip heading levels #

Developers often skip heading levels to use the browser's default styles that closely match their design. This is considered an anti-pattern because it breaks the outline model.

Instead of relying on the browser's default font-sizing for headings, use your own CSS, and don't skip levels.

For example, this site has a section called "IN THE NEWS", followed by two headlines:

The section heading, "IN THE NEWS", could be an h2, and the supporting headlines could both be h3 elements.

Because the font-size for "IN THE NEWS" is smaller than the headline, it may be tempting to make the headline for the first story an h2 and to make "IN THE NEWS" an h3. While that may match the browser's default styling, it would break the outline conveyed to a screen reader user!

You can use Lighthouse to check if your page skips any heading levels. Run the Accessibility audit (Lighthouse > Options > Accessibility) and look for the results of the Headings don't skip levels audit.

HTML5 elements such as main, nav, and aside act as landmarks, or special regions on the page to which a screen reader can jump.

Use landmark tags to define major sections of your page, instead of relying on divs. Be careful not to go overboard because having too many landmarks can be overwhelming. For example, stick to just one main element instead of 3 or 4.

Lighthouse recommends manually auditing your site to check that "HTML5 landmark elements are used to improve navigation." You can use this list of landmark elements to check your page.

Bypass repetitive content with skip links #

Many sites contain repetitive navigation in their headers, which can be annoying to navigate with assistive technology. Use a skip link to let users bypass this content.

A skip link is an offscreen anchor that is always the first focusable item in the DOM. Typically, it contains an in-page link to the main content of the page. Because it is the first element in the DOM, it only takes a single action from assistive technology to focus it and bypass repetitive navigation.

<!-- index.html -->
<a class="skip-link" href="#main">Skip to main</a>
…
<main id="main">
  [Main content]
</main>

/* style.css */
.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  background: #000000;
  color: white;
  padding: 8px;
  z-index: 100;
}

.skip-link:focus {
  top: 0;
}

Many popular sites such as GitHub, The NY Times, and Wikipedia all contain skip links. Try visiting them and pressing the TAB key on your keyboard a few times.

Lighthouse can help you check if your page contains a skip link. Run the Accessibility audit again and look for the results of the The page contains a heading, skip link, or landmark region audit.

Keyboard access fundamentals

2018-11-18T00:00:00Z

Many different users rely on the keyboard to navigate applications—from users with temporary and permanent motor impairments to users who use keyboard shortcuts to be more efficient and productive. Having a good keyboard navigation strategy for your application creates a better experience for everyone.

Focus and the tab order #

At a given moment, focus refers to what element in your application (such as a field, checkbox, button, or link) currently receives input from the keyboard. In addition to receiving keyboard events, the focused element also gets content that is pasted from the clipboard.

To move the focus on a page, use TAB to navigate "forward" and SHIFT + TAB to navigate "backward." The currently focused element is often indicated by a focus ring, and various browsers style their focus rings differently. The order in which focus proceeds forward and backward through interactive elements is called the tab order.

Interactive HTML elements like text fields, buttons, and select lists are implicitly focusable: they are automatically inserted into the tab order based on their position in the DOM. These interactive elements also have built-in keyboard event handling. Elements such as paragraphs and divs are not implicitly focusable because users typically do not need to interact with them.

Implementing a logical tab order is an important part of providing your users with a smooth keyboard navigation experience. There are two main ideas to keep in mind when assessing and adjusting your tab order:

Arrange elements in the DOM to be in logical order
Correctly set the visibility of offscreen content that should not receive focus

Arrange elements in the DOM to be in logical order #

To check if your application's tab order is logical, try tabbing through your page. In general, focus should follow reading order, moving from left to right, from the top to the bottom of your page.

If the focus order seems wrong, you should rearrange the elements in the DOM to make the tab order more natural. If you want something to appear visually earlier on the screen, move it earlier in the DOM.

Try tabbing through the two sets of buttons below to experience a logical tab order versus an illogical tab order:

Logical tab order

Illogical tab order

The code for these two examples is compared below:

Logical tab order

<button>Kiwi</button>
<button>Peach</button>
<button>Coconut</button>

Illogical tab order

<button style="float: right">Kiwi</button>
<button>Peach</button>
<button>Coconut</button>

Be careful when changing the visual position of elements using CSS to avoid creating an illogical tab order. To fix the illogical tab order above, move the floating "Kiwi" button so it comes after the "Coconut" button in the DOM, and remove the inline style.

Correctly set the visibility of offscreen content #

Sometimes offscreen interactive elements need to be in the DOM but should not be in your tab order. For example, if you have a responsive side-nav that opens when you click a button, the user should not be able to focus on the side-nav when it's closed.

To prevent a particular interactive element from receiving focus, you should give the element either of the following CSS properties:

display: none
visibility: hidden

To add the element back into the tab order, for example when the side-nav is opened, replace the above CSS properties respectively with:

display: block
visibility: visible

Next steps #

For users who operate their computer almost entirely with the keyboard or another input device, a logical tab order is essential for making your application accessible and usable. As a good habit for checking your tab order, try tabbing through your application before each publish.

Labels and text alternatives

2018-11-18T00:00:00Z

In order for a screen reader to present a spoken UI to the user, meaningful elements must have proper labels or text alternatives. A label or text alternative gives an element its accessible name, one of the key properties for expressing element semantics in the accessibility tree.

When an element's name is combined with the element's role, it gives the user context so they can understand what type of element they're interacting with and how it is represented on the page. If a name is not present, then a screen reader only announces the element's role. Imagine trying to navigate a page and hearing, "button," "checkbox," "image" without any additional context. This is why labeling and text alternatives are crucial to a good, accessible experience.

Inspect an element's name #

It's easy to check an element's accessible name using Chrome's DevTools:

Right-click on an element and choose Inspect. This opens the DevTools Elements panel.
In the Elements panel, look for the Accessibility pane. It may be hidden behind a » symbol.
In the Computed Properties dropdown, look for the Name property.

DevTools accessibility pane showing the computed name for a button.

Whether you're looking at an img with alt text or an input with a label, all of these scenarios result in the same outcome: giving an element its accessible name.

Check for missing names #

There are different ways to add an accessible name to an element, depending on its type. The following table lists the most common element types that need accessible names and links to explanations for how to add them.

Element type	How to add a name
HTML document	Label documents and frames
`<frame>` or `<iframe>` elements	Label documents and frames
Image elements	Include text alternatives for images and objects
`<input type="image">` elements	Include text alternatives for images and objects
`<object>` elements	Include text alternatives for images and objects
Buttons	Label buttons and links
Links	Label buttons and links
Form elements	Label form elements

Label documents and frames #

Every page should have a title element that briefly explains what the page is about. The title element gives the page its accessible name. When a screen reader enters the page, this is the first text that is announced.

For example, the page below has the title "Mary's Maple Bar Fast-Baking Recipe":

<!doctype html>
  <html lang="en">
    <head>
      <title>Mary's Maple Bar Fast-Baking Recipe</title>
    </head>
  <body>
    …
  </body>
</html>

Similarly, any frame or iframe elements should have title attributes:

<iframe title="An interactive map of San Francisco" src="…"></iframe>

While an iframe's contents may contain their own internal title element, a screen reader usually stops at the frame boundary and announces the element's role—"frame"—and its accessible name, provided by the title attribute. This lets the user decide if they wish to enter the frame or bypass it.

Include text alternatives for images and objects #

An img should always be accompanied by an alt attribute to give the image its accessible name. If the image fails to load, the alt text is used as a placeholder so users have a sense of what the image was trying to convey.

Writing good alt text is a bit of an art, but there are a couple of guidelines you can follow:

Determine if the image provides content that would otherwise be difficult to attain from reading the surrounding text.
If so, convey the content as succinctly as possible.

If the image acts as decoration and does not provide any useful content, you can give it an empty alt="" attribute to remove it from the accessibility tree.

Images as links and inputs #

An image wrapped in a link should use the img's alt attribute to describe where the user will navigate to if they click on the link:

<a href="https://en.wikipedia.org/wiki/Google">
  <img alt="Google's wikipedia page" src="google-logo.jpg">
</a>

Similarly, if an <input type="image"> element is used to create an image button, it should contain alt text that describes the action that occurs when the user clicks on the button:

<form>
  <label>
    Username:
    <input type="text">
  </label>
  <input type="image" alt="Sign in" src="./sign-in-button.png">
</form>

Embedded objects #

<object> elements, which are typically used for embeds like Flash, PDFs, or ActiveX, should also contain alternative text. Similar to images, this text is displayed if the element fails to render. The alternative text goes inside the object element as regular text, like "Annual report" below:

<object type="application/pdf" data="/report.pdf">
Annual report.
</object>

Label buttons and links #

Buttons and links are often crucial to the experience of a site, and it is important that both have good accessible names.

Buttons #

A button element always attempts to compute its accessible name using its text content. For buttons that are not part of a form, writing a clear action as the text content may be all you need to create a good accessible name.

<button>Book Room</button>

One common exception to this rule is icon buttons. An icon button may use an image or an icon font to provide the text content for the button. For example, the buttons used in a What You See Is What You Get (WYSIWYG) editor to format text are typically just graphic symbols:

When working with icon buttons, it can be helpful to give them an explicit accessible name using the aria-label attribute. aria-label overrides any text content inside the button, letting you clearly describe the action to anyone using a screen reader.

<button aria-label="Left align"></button>

Links #

Similar to buttons, links primarily get their accessible name from their text content. A nice trick when creating a link is to put the most meaningful piece of text into the link itself, rather than filler words like "Here" or "Read More."

Not descriptive enough

Check out our guide to web performance <a href="/guide">here</a>.

Useful content!

Check out <a href="/guide">our guide to web performance</a>.

This is especially helpful for screen readers that offer shortcuts to list all of the links on the page. If links are full of repetitive filler text, these shortcuts become much less useful:

Example of VoiceOver, a screen reader for macOS, showing the navigate by links menu.

Label form elements #

There are two ways to associate a label with a form element such as a checkbox. Either of the methods causes the label text to also become a click target for the checkbox, which is also helpful for mouse or touchscreen users. To associate a label with an element, either:

Place the input element inside of a label element

<label>
  <input type="checkbox">Receive promotional offers?</input>
</label>

Or use the label's for attribute and refer to the element's id

<input id="promo" type="checkbox"></input>
<label for="promo">Receive promotional offers?</label>

When the checkbox has been labeled correctly, the screen reader can report that the element has a role of checkbox, is in a checked state, and is named "Receive promotional offers?" like in the VoiceOver example below:

Check whether sample HTML elements have accessible names

Does this image have an accessible name?

Yes. Give an image an accessible name by adding an alt attribute.

<object type="application/pdf" data="/report.pdf" alt="Annual report"></object>

Does this object have an accessible name?

No. Give an <object> element a name by providing text content. (An alt attribute on an object will not be read by assistive technologies.)

This sample renders an icon button:

<button>
  <svg class="icon">
    <use xlink:href="#icon-1" />
  </svg>
</button>

Does this button have an accessible name?

No. Give a button an accessible name by providing text content, an aria-label attribute, or an aria-labelledby attribute.

This sample renders an icon button with a tooltip that appears on hover and focus:

<button>
  <svg class="icon">
    <use xlink:href="#icon-1" />
  </svg>
  <span class="tooltip hidden">Open menu</span>
</button>

Does this button have an accessible name?

Yes. Even if the button's tooltip is visually hidden using CSS, assistive technologies can still read its text content.

Caution: When visually hiding button text, use CSS rather than the hidden attribute. The hidden attribute removes the element from the accessibility tree.

<label>
  <input type="checkbox" value="subscribe"></input>
  Subscribe to the newsletter?
</label>

Does this checkbox have an accessible name?

Yes. The label is associated with the checkbox because the label is the checkbox's parent. So, assistive technologies treat the label's text content as the input's name.

<input type="checkbox" value="subscribe"></input>
<label for="subscribe">Subscribe to the newsletter?</label>

Does this checkbox have an accessible name?

No. The checkbox's value attribute indicates what text will be saved when the form is submitted, but assistive technologies don't read it. To provide an accessible name, add an id attribute with the value subscribe to associate the checkbox with the label.

Semantics and screen readers

2018-11-18T00:00:00Z

Have you ever stopped to wonder how assistive technology, such as a screen reader, knows what to announce to users? The answer is that these technologies rely on developers marking up their pages with semantic HTML. But what are semantics, and how do screen readers use them?

Affordances and semantics #

Before diving into semantics, it's helpful to understand another term: affordances. An affordance is any object that offers, or affords, its user the opportunity to perform an action. A classic example is the teapot:

A teapot's handle is a natural affordance.

This teapot doesn't need an instruction manual; instead, its physical design conveys to the user how it should be operated. It has a handle, and because you've seen other objects in the world with similar handles, you can infer how you should pick it up and operate it.

When we build graphical user interfaces, we use things like CSS to add visual affordances to our UI. For instance, you might give a button a drop shadow and border so that it resembles an actual button in the real world.

But if a user is unable to see the screen, then these visual affordances will not be conveyed to them. Therefore, you need to make sure that your UI is constructed in a way that can convey these same affordances to assistive technology. This non-visual exposure of a UI element's affordances is called its semantics.

Use semantic HTML #

The easiest way of conveying proper semantics is to use semantically rich HTML elements.

Using CSS, it's possible to style the <div> and <button> elements so they convey the same visual affordances, but the two experiences are very different when using a screen reader. A <div> is just a generic grouping element, so a screen reader only announces the text content of the <div>. The <button> is announced as a "button," a much stronger signal to the user that it's something they can interact with.

The simplest and often best solution to this problem is to avoid custom interactive controls altogether. For example, replace a <div> that's acting like a button with an actual <button>.

Semantic properties and the accessibility tree #

Generally speaking, every HTML element will have some of the following semantic properties:

A role or type
A name
A value (optional)
A state (optional)

An element's role describes its type, for example, "button," "input," or even just "group" for things like div and span elements.

An element's name is its computed label. Screen readers typically announce an element's name followed by its role, e.g. "Sign Up, button." The algorithm that determines an element's name factors in things like if there is any text content inside the element, whether or not it has attributes such as title or placeholder, whether or not the element is associated with an actual <label> element, and if the element has any ARIA attributes such as aria-label and aria-labelledby.

Some elements may have a value. For instance, <input type="text"> may have a value that reflects whatever the user has typed into the text field.

Some elements may also have a state, which conveys their current status. For instance, a <select> element can be in either an expanded or a collapsed state, depending on if it's open or closed.

The accessibility tree #

For each node in the DOM, the browser determines if the node is semantically "interesting" and adds it to the accessibility tree. When assistive technology, like a screen reader, is providing an alternative UI to the user, it is often doing so by walking this accessibility tree.

Using Chrome's DevTools you can inspect an element's semantic properties and explore its position in the accessibility tree.

Next steps #

Once you know a bit about semantics and how they aid screen reader navigation, you can't help but look at the pages you build differently. In the next section, we'll take a step back and consider how the entire outline of a page can be conveyed using effective headings and landmarks.

Style focus

2018-11-18T00:00:00Z

The focus indicator (often signified by a "focus ring") identifies the currently focused element on your page. For users who are unable to use a mouse, this indicator is extremely important because it acts as a stand-in for their mouse-pointer.

If the browser's default focus indicator clashes with your design, you can use CSS to restyle it. Just remember to keep your keyboard users in mind!

Use `:focus` to always show a focus indicator #

The :focus pseudo-class is applied any time an element is focused, regardless of the input device (mouse, keyboard, stylus, etc.) or method used to focus it. For example, the <div> below has a tabindex which makes it focusable. It also has a custom style for its :focus state:

div[tabindex="0"]:focus {
  outline: 4px dashed orange;
}

Regardless of whether you use a mouse to click on it or a keyboard to tab to it, the <div> will always look the same.

Unfortunately browsers can be inconsistent with how they apply focus. Whether or not an element receives focus may depend on the browser and the operating system.

For example, the <button> below also has a custom style for its :focus state.

button:focus {
  outline: 4px dashed orange;
}

If you click on the <button> with a mouse in Chrome on macOS you should see its custom focus style. However, you will not see the custom focus style if you click on the <button> in Safari on macOS. This is because in Safari the element does not receive focus when you click on it.

Because the behavior of focus is inconsistent, it may require a bit of testing on different devices to ensure your focus styles are acceptable to your users.

Use `:focus-visible` to selectively show a focus indicator #

The new :focus-visible pseudo-class is applied any time that an element receives focus and the browser determines via heuristics that displaying a focus indicator would be beneficial to the user. In particular, if the most recent user interaction was via the keyboard and the key press did not include a meta, ALT / OPTION, or CONTROL key, then :focus-visible will match.

The button in the example below will selectively show a focus indicator. If you use a mouse to click on it, the results are different than if you first use a keyboard to tab to it.

button:focus-visible {
  outline: 4px dashed orange;
}

Use `:focus-within` to style the parent of a focused element #

The :focus-within pseudo-class is applied to an element either when the element itself receives focus or when another element inside that element receives focus.

It can be used to highlight a region of the page to draw the user's attention to that area. For example, the form below receives focus both when the form itself is selected and also when any of its radio buttons are selected.

form:focus-within {
  background: #ffecb3;
}

When to display a focus indicator #

A good rule of thumb is to ask yourself, "If you clicked on this control while using a mobile device, would you expect it to display a keyboard?"

If the answer is "yes," then the control should probably always show a focus indicator, regardless of the input device used to focus it. A good example is the <input type="text"> element. The user will need to send input to the element via the keyboard regardless of how the input element originally received focus, so it's helpful to always display a focus indicator.

If the answer is "no," then the control may choose to selectively show a focus indicator. A good example is the <button> element. If a user clicks on it with a mouse or touch screen, the action is complete, and a focus indicator may not be necessary. However, if the user is navigating with a keyboard, it's useful to show a focus indicator so the user can decide whether or not they want to click the control using the ENTER or SPACE keys.

Avoid `outline: none` #

The way browsers decide when to draw a focus indicator is, frankly, very confusing. Changing the appearance of a <button> element with CSS or giving an element a tabindex will cause the browser's default focus ring behavior to kick-in.

A very common anti-pattern is to remove the focus indicator using CSS such as:

/* Don't do this!!! */
:focus {
  outline: none;
}

A better way to work around this issue is to use a combination of :focus and the :focus-visible polyfill. The first block of code below demonstrates how the polyfill works, and the sample app beneath it provides an example of using the polyfill to change the focus indicator on a button.

/*
  This will hide the focus indicator if the element receives focus via the
  mouse, but it will still show up on keyboard focus.
*/
.js-focus-visible :focus:not(.focus-visible) {
  outline: none;
}

/*
  Optionally: Define a strong focus indicator for keyboard focus.
  If you choose to skip this step, then the browser's default focus
  indicator will be displayed instead.
*/
.js-focus-visible .focus-visible {
  …
}

Use semantic HTML for easy keyboard wins

2018-11-18T00:00:00Z

By using the correct semantic HTML elements you may be able to meet most or all of your keyboard access needs. That means less time fiddling with tabindex, and more happy users!

Keyboard support for free (and better mobile experiences) #

There are a number of built-in interactive elements with proper semantics and keyboard support. The ones most developers use are:

In addition, elements with the contenteditable attribute are sometimes used for freeform text entry.

It's easy to overlook the built-in keyboard support that these elements offer. Below are some example elements to explore. Instead of using your mouse, try using your keyboard to operate them. You can use TAB (or SHIFT + TAB) to move between controls, and you can use the arrow keys and keys like ENTER and SPACE to manipulate their values.

If you have a phone handy, you can see that many times these built-in elements have unique interactions on mobile. Attempting to reproduce these mobile interactions yourself is a lot of work! It's another good reason to stick to built-in elements whenever possible.

Use `button` instead of `div` #

A common accessibility anti-pattern is to treat a non-interactive element, like a div or a span, as a button by adding a click handler to it.

But to be considered accessible, a button should:

Be focusable via the keyboard
Support being disabled
Support the ENTER or SPACE keys to perform an action
Be announced properly by a screen reader

A div button has none of these things. That means you'll need to write additional code to replicate what the button element gives you for free!

For example, button elements have a neat trick called synthetic click activation. If you add a "click" handler to a button, it will run when the user presses ENTER or SPACE. A div button doesn't have this feature, so you'll need to write additional code to listen for the keydown event, check that the keycode is ENTER or SPACE, and then run your click handler. Ouch! That's a lot of extra work!

Compare the difference in this example. TAB to either control, and use ENTER and SPACE to attempt to click on them.

If you have div buttons in your existing site or application, consider swapping them out for button elements. button is easy to style and full of accessibility wins!

Links versus buttons #

Another common anti-pattern is to treat links as buttons by attaching JavaScript behavior to them.

<a href="#" onclick="// perform some action">

Both buttons and links support some form of synthetic click activation. So which should you choose?

If clicking on the element will perform an action on the page, use <button>.
If clicking on the element will navigate the user to a new page then use <a>. This includes single page web apps that load new content and update the URL using the History API.

The reason for this is that buttons and links are announced differently by screen readers. Using the correct element helps screen reader users know which outcome to expect.

Check whether code samples should use buttons or links

See <a href="https://webaim.org/intro/" rel="noopener">WebAIM's Introduction to Web Accessibility</a> for more information.

Should this sample use a button or a link?

This sample should use a link. The sample is correct.

When selected, the element navigates the user to another page on a different domain, so a link is semantic.

See the <a href="/semantics-and-screen-readers">Semantics and screen readers page</a> for more information.

Should this sample use a button or a link?

This sample should use a link. The sample is correct.

When selected, the element navigates the user to a different page on the same domain. No matter where a resource is located, use a link to semantically indicate navigation.

When selected, this element opens a modal dialog:

<a href="#" onclick="openDialog()">

Should this sample use a button or a link?

This sample should use a button. The sample is incorrect.

When selected, the element runs a function that opens a modal dialog on the same page; since the element isn't navigating the user to a separate page, a button is semantic.

When selected, this element opens a navigation menu:

<a href="#" onclick="openNavMenu()">

Should this sample use a button or a link?

This sample should use a button. The sample is incorrect.

When selected, the element runs a function that opens a navigation menu on the same page. Opening the menu is an action, so a button is semantic.

This code renders a horizontal navigation menu at the top of a website:

<nav>
  <button>About</button>
  <button>Services</button>
  <button>Work</button>
  <button>Contact</button>
</nav>

Should this sample use buttons or links?

This sample should use links. The sample is incorrect.

The elements in the <nav> menu navigate the user to other pages. Those pages may be separate resources in a static site, or they may be views in a single-page application. Either way, since the user is navigating somewhere else, links are semantic.

Styling #

Some built-in elements, in particular <input>, can be difficult to style. With a bit of clever CSS you may be able to work around some of these limitations. The (hilariously named) WTFForms project contains an example stylesheet that demonstrates a number of techniques for styling some of the tougher built-in elements.

Next steps #

Using built-in HTML elements can greatly improve the accessibility of your site, and significantly cut down on your workload. Try tabbing through your site and look for any controls which lack keyboard support. If possible, switch them out for standardized HTML alternatives.

Sometimes you may find an element that doesn't have a counterpart in HTML. That's okay! Read on to learn how to add keyboard support to custom interactive controls using tabindex.

What is accessibility?

2018-11-18T00:00:00Z

An accessible site is one whose content can be accessed regardless of any user's impairments and whose functionality can also be operated by the most diverse range of users possible.

As developers, it's easy to assume that all users can see and use a keyboard, mouse, or touch screen to interact with your page. This can lead to an experience that works well for some people but creates issues for others that range from simple annoyances to complete blockers.

Understanding the diverse needs of your users #

When learning about accessibility, it helps to have an understanding of the diverse range of users in the world and the kinds of accessibility topics that affect them. To explain further, here's an informative video from Victor Tsaran, a Technical Program Manager at Google.

Generally speaking, accessibility concerns can be split into four broad categories:

Vision
Motor/dexterity
Auditory
Cognitive

Planning for accessibility means thinking about users who are experiencing some type of impairment or disability in one or more of these categories. Bear in mind that that experience might be non-physical or temporary—for instance, trying to read a screen outside during a bright, sunny day or operating a device one-handed while carrying a cup of coffee.

When you plan for these situations upfront, you end up with an experience that is more robust and works for more users regardless of their ability or context.

Vision #

Vision impairments range from limited or low vision to complete blindness. Users with low vision may use a combination of screen magnification, high contrast themes, and text-to-speech to access content. Some users may rely on a screen reader or braille display to navigate a page, perform actions, and read descriptions of content and controls.

Motor/dexterity #

Motor and dexterity impairments may affect a user's ability to use a mouse, touchscreen, or other pointing device. Some users may rely on alternative input devices to access content. These devices might include a keyboard, head- or eye-tracking software, switch devices, sip-and-puff devices, or voice access.

Auditory #

Auditory impairments range from difficulty hearing certain frequencies, to speech processing issues, to a total inability to hear sound. Users experiencing an auditory impairment may rely on captions or transcripts to provide an alternative to sound in an interface.

Cognitive #

Cognitive impairment is a broad category, encompassing topics such as ADHD, dyslexia, and autism, just to name a few. The accommodations for these users are quite diverse, but generally speaking, users may seek to minimize distractions, flashing, heavy animations, and anything which shifts the user's context around the page in an unexpected way. Users may also use custom colors and styles to improve readability or prevent headaches.

Next steps #

Now that you have a high level understanding of accessibility, it's time to dive in to more specific details, starting with keyboard access.

Replace GIFs with video

2018-11-05T00:00:00Z

In this codelab, improve performance by replacing an animated GIF with a video.

Measure first #

First measure how the website performs:

To preview the site, press View App. Then press Fullscreen .
Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Lighthouse tab.
Make sure the Performance checkbox is selected in the Categories list.
Click the Generate report button.

When you're finished, you should see that Lighthouse has flagged the GIF as an issue in its "Use video formats for animated content" audit.

Get FFmpeg #

There are a number of ways you can convert GIFs to video; this guide uses FFmpeg. It's already installed in the Glitch VM, and, if you want, you can follow these instructions to install it on your local machine as well.

Open the console #

Double-check that FFmpeg is installed and working:

Click Remix to Edit to make the project editable.
Click Terminal (note: if the Terminal button does not show you may need to use the Fullscreen option).
In the console, run:

which ffmpeg

You should get a file path back:

/usr/bin/ffmpeg

Change GIF to video #

In the console, run cd images to enter the images directory.
Run ls to see the contents.

You should see something like this:

$ ls
cat-herd.gif

In the console, run:

ffmpeg -i cat-herd.gif -b:v 0 -crf 25 -f mp4 -vcodec libx264 -pix_fmt yuv420p cat-herd.mp4

This tells FFmpeg to take the input, signified by the -i flag, of cat-herd.gif and convert it to a video called cat-herd.mp4. This should take a second to run. When the command finishes, you should be able to type ls again and see two files:

$ ls
cat-herd.gif  cat-herd.mp4

Create WebM videos #

While MP4 has been around since 1999, WebM is a relative newcomer having been initially released in 2010. WebM videos can be much smaller than MP4 videos, so it makes sense to generate both. Thankfully the <video> element will let you add multiple sources, so if a browser doesn't support WebM, it can fallback to MP4.

In the console, run:

ffmpeg -i cat-herd.gif -c vp9 -b:v 0 -crf 41 cat-herd.webm

To check the file sizes run:

ls -lh

You should have one GIF, and two videos:

$ ls -lh
total 4.5M
-rw-r--r-- 1 app app 3.7M May 26 00:02 cat-herd.gif
-rw-r--r-- 1 app app 551K May 31 17:45 cat-herd.mp4
-rw-r--r-- 1 app app 341K May 31 17:44 cat-herd.webm

Notice that the original GIF is 3.7M, whereas the MP4 version is 551K, and the WebM version is only 341K. That's a huge savings!

Update HTML to recreate GIF effect #

Animated GIFs have three key traits that videos need to replicate:

They play automatically.
They loop continuously (usually, but it is possible to prevent looping).
They're silent.

Luckily, you can recreate these behaviors using the <video> element.

In the index.html file, replace the line with the <img> with:

<img src="/images/cat-herd.gif" alt="Cowboys herding cats.">
<video autoplay loop muted playsinline></video>

A <video> element using these attributes will play automatically, loop endlessly, play no audio, and play inline (that is, not fullscreen), all the behaviors expected of animated GIFs! 🎉

Specify your sources #

All that's left to do is specify your video sources. The <video> element requires one or more <source> child elements pointing to different video files the browser can choose from, depending on format support. Update the <video> with <source> elements that link to your cat-herd videos:

<video autoplay loop muted playsinline>
  <source src="/images/cat-herd.webm" type="video/webm">
  <source src="/images/cat-herd.mp4" type="video/mp4">
</video>

Preview #

To preview the site, press View App. Then press Fullscreen .

The experience should look the same. So far so good.

Verify with Lighthouse #

With the live site open:

Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Lighthouse tab.
Make sure the Performance checkbox is selected in the Categories list.
Click the Generate report button.

You should see that the "Use video formats for animated content" audit is now passing! Woohoo! 💪

HowTo Components – howto-checkbox

2017-10-02T00:00:00Z

Summary #

A <howto-checkbox> represents a boolean option in a form. The most common type of checkbox is a dual-type which allows the user to toggle between two choices -- checked and unchecked.

The element attempts to self apply the attributes role="checkbox" and tabindex="0" when it is first created. The role attribute helps assistive technology like a screen reader tell the user what kind of control this is. The tabindex attribute opts the element into the tab order, making it keyboard focusable and operable. To learn more about these two topics, check out What can ARIA do? and Using tabindex.

When the checkbox is checked, it adds a checked boolean attribute, and sets a corresponding checked property to true. In addition, the element sets an aria-checked attribute to either "true" or "false", depending on its state. Clicking on the checkbox with a mouse, or space bar, toggles these checked states.

The checkbox also supports a disabled state. If either the disabled property is set to true or the disabled attribute is applied, the checkbox sets aria-disabled="true", removes the tabindex attribute, and returns focus to the document if the checkbox is the current activeElement.

The checkbox is paired with a howto-label element to ensure it has an accessible name.

Reference #

Demo #

View live demo on GitHub

Example usage #

<style>
  howto-checkbox {
    vertical-align: middle;
  }
  howto-label {
    vertical-align: middle;
    display: inline-block;
    font-weight: bold;
    font-family: sans-serif;
    font-size: 20px;
    margin-left: 8px;
  }
</style>

<howto-checkbox id="join-checkbox"></howto-checkbox>
<howto-label for="join-checkbox">Join Newsletter</howto-label>

Code #

(function() {

Define key codes to help with handling keyboard events.

  const KEYCODE = {
    SPACE: 32,
  };

Cloning contents from a <template> element is more performant than using innerHTML because it avoids additional HTML parse costs.

  const template = document.createElement('template');

  template.innerHTML = `
    <style>
      :host {
        display: inline-block;
        background: url('../images/unchecked-checkbox.svg') no-repeat;
        background-size: contain;
        width: 24px;
        height: 24px;
      }
      :host([hidden]) {
        display: none;
      }
      :host([checked]) {
        background: url('../images/checked-checkbox.svg') no-repeat;
        background-size: contain;
      }
      :host([disabled]) {
        background:
          url('../images/unchecked-checkbox-disabled.svg') no-repeat;
        background-size: contain;
      }
      :host([checked][disabled]) {
        background:
          url('../images/checked-checkbox-disabled.svg') no-repeat;
        background-size: contain;
      }
    </style>
  `;


  class HowToCheckbox extends HTMLElement {
    static get observedAttributes() {
      return ['checked', 'disabled'];
    }

The element's constructor is run anytime a new instance is created. Instances are created either by parsing HTML, calling document.createElement('howto-checkbox'), or calling new HowToCheckbox(); The constructor is a good place to create shadow DOM, though you should avoid touching any attributes or light DOM children as they may not be available yet.

    constructor() {
      super();
      this.attachShadow({mode: 'open'});
      this.shadowRoot.appendChild(template.content.cloneNode(true));
    }

connectedCallback() fires when the element is inserted into the DOM. It's a good place to set the initial role, tabindex, internal state, and install event listeners.

    connectedCallback() {
      if (!this.hasAttribute('role'))
        this.setAttribute('role', 'checkbox');
      if (!this.hasAttribute('tabindex'))
        this.setAttribute('tabindex', 0);

A user may set a property on an instance of an element, before its prototype has been connected to this class. The _upgradeProperty() method will check for any instance properties and run them through the proper class setters. See the lazy properties section for more details.

      this._upgradeProperty('checked');
      this._upgradeProperty('disabled');

      this.addEventListener('keyup', this._onKeyUp);
      this.addEventListener('click', this._onClick);
    }

    _upgradeProperty(prop) {
      if (this.hasOwnProperty(prop)) {
        let value = this[prop];
        delete this[prop];
        this[prop] = value;
      }
    }

disconnectedCallback() fires when the element is removed from the DOM. It's a good place to do clean up work like releasing references and removing event listeners.

    disconnectedCallback() {
      this.removeEventListener('keyup', this._onKeyUp);
      this.removeEventListener('click', this._onClick);
    }

Properties and their corresponding attributes should mirror one another. The property setter for checked handles truthy/falsy values and reflects those to the state of the attribute. See the avoid reentrancy section for more details.

    set checked(value) {
      const isChecked = Boolean(value);
      if (isChecked)
        this.setAttribute('checked', '');
      else
        this.removeAttribute('checked');
    }

    get checked() {
      return this.hasAttribute('checked');
    }

    set disabled(value) {
      const isDisabled = Boolean(value);
      if (isDisabled)
        this.setAttribute('disabled', '');
      else
        this.removeAttribute('disabled');
    }

    get disabled() {
      return this.hasAttribute('disabled');
    }

attributeChangedCallback() is called when any of the attributes in the observedAttributes array are changed. It's a good place to handle side effects, like setting ARIA attributes.

    attributeChangedCallback(name, oldValue, newValue) {
      const hasValue = newValue !== null;
      switch (name) {
        case 'checked':
          this.setAttribute('aria-checked', hasValue);
          break;
        case 'disabled':
          this.setAttribute('aria-disabled', hasValue);

The tabindex attribute does not provide a way to fully remove focusability from an element. Elements with tabindex=-1 can still be focused with a mouse or by calling focus(). To make sure an element is disabled and not focusable, remove the tabindex attribute.

          if (hasValue) {
            this.removeAttribute('tabindex');

If the focus is currently on this element, unfocus it by calling the HTMLElement.blur() method

            this.blur();
          } else {
            this.setAttribute('tabindex', '0');
          }
          break;
      }
    }

    _onKeyUp(event) {

Don’t handle modifier shortcuts typically used by assistive technology.

      if (event.altKey)
        return;

      switch (event.keyCode) {
        case KEYCODE.SPACE:
          event.preventDefault();
          this._toggleChecked();
          break;

Any other key press is ignored and passed back to the browser.

        default:
          return;
      }
    }

    _onClick(event) {
      this._toggleChecked();
    }

_toggleChecked() calls the checked setter and flips its state. Because _toggleChecked() is only caused by a user action, it will also dispatch a change event. This event bubbles in order to mimic the native behavior of <input type=checkbox>.

    _toggleChecked() {
      if (this.disabled)
        return;
      this.checked = !this.checked;
      this.dispatchEvent(new CustomEvent('change', {
        detail: {
          checked: this.checked,
        },
        bubbles: true,
      }));
    }
  }

  customElements.define('howto-checkbox', HowToCheckbox);
})();

Accessibility for teams

2017-08-01T00:00:00Z

Making your site more accessible can be a daunting task. If you are approaching accessibility for the first time, the sheer breadth of the topic can leave you wondering where to start. After all, working to accommodate a diverse range of abilities means there are a correspondingly diverse range of issues to consider.

Remember, accessibility is a team effort. Every person has a role to play. This article outlines criteria for each of the major disciplines (project manager, UX designer, and developer) so that they can work to incorporate accessibility best practices into their process.

Project manager #

An overriding goal for any project manager is to try to include accessibility work in every milestone; making sure it’s just as much a priority as other topics like performance, and user experience. Below are a few checklist items to keep in mind when working through your process.

Make accessibility training available to the team.
Identify critical user journeys in the site or application.
Try to incorporate an accessibility checklist into the team process.
Where possible, evaluate the site or application with user studies.

Accessibility training #

There are a number of great free resources for learning about web accessibility. Setting aside time for your team to study the topic can make it easier to include accessibility early in the process.

Some resources provided by Google include:

Web Accessibility by Google — a multi-week interactive training course.

Accessibility Fundamentals — written accessibility guides and best practices.

Material Guidelines: Accessibility — a set of UX best practices for inclusive design.

Identifying critical user journeys #

Every application has some primary action that the user needs to take. For example, if you're building an e-commerce app, then every user will need to be able to add an item to their shopping cart.

Some actions may be of secondary importance, and perhaps only performed occasionally. For example, changing your avatar photo is a nice feature, but may not be critical for every experience.

Identifying the primary and secondary actions in your application will help you prioritize the accessibility work ahead. Later, you can combine these actions with an accessibility checklist to keep track of your progress and avoid regressions.

Incorporating an accessibility checklist #

The topic of accessibility is quite broad, so having a checklist of important areas to consider can help you make sure you're covering all of your bases.

There are a number of accessibility checklists out there, a few industry examples include:

WebAIM WCAG Checklist Vox Accessibility Guidelines

With a checklist in hand, you can look over your primary and secondary actions to start to triage what work still needs to be done. You can get pretty tactical about this process and even build a matrix of primary and secondary actions and determine for each step in those processes, whether there are any missing accessibility bits.

Evaluating with user studies #

Nothing beats sitting down with actual users and observing them as they try to use your app. If you're retrofitting accessibility into an existing experience, this process can help you quickly identify areas that need improvement. And if you're starting a new project, early user studies can help you avoid spending too much time developing a feature that is difficult to use.

Aim to incorporate feedback from as diverse of a user population as possible. Consider users who primarily navigate with the keyboard, or rely on assistive technology like screen readers or screen magnifiers.

UX designer #

Because people tend to design using their own biases, if you don't have a disability and don't have colleagues with disabilities, you might be unintentionally designing for only some of your users. As you work, ask yourself "what are all the types of users who might rely on this design?" Here are some techniques you can try to make your process more inclusive.

Content has sufficient color contrast.
The tab order is defined.
Controls have accessible labels.
There are multiple ways to interact with the UI.

Content has good color contrast #

The primary goal of most sites is to convey some information to the user, either through written text or images. However, if this content is low contrast, it may be difficult for some users (particularly those with a vision impairment) to read. This may negatively affect their user experience. To address this concern, aim for all text and images to have sufficient color contrast.

Contrast is measured by comparing the luminance of a foreground and background color. For smaller text (anything below 18pt or 14pt bold) a minimum ratio of 4.5:1 is recommended. For larger text, this ratio can be adjusted to 3:1.

In the image below, the text on the left hand side meets these contrast minimums, whereas the text on right hand side is low contrast.

There are a number of tools for measuring color contrast, such as Google’s Material Color Tool, Lea Verou's Contrast Ratio app, and Deque’s aXe.

Tab order is defined #

The tab order is the order in which elements receive focus as the user presses the tab key. For users who navigate primarily with a keyboard, the tab key is their primary means of reaching everything on screen. Think of it like their mouse cursor.

Ideally the tab order should follow the reading order and flow from the top of the page to the bottom, with more important items appearing higher up in the order. This makes it more efficient for anyone using a keyboard to quickly reach these items.

The mock interface above is numbered to show the tab order. Creating a mock like this can help by identifying the intended tab order. This can then be shared with the developers and QA testers to make sure it is properly implemented and tested.

Controls have accessible labels #

For users of assistive technology like screen readers, labels provide information that would otherwise be visual only. For example a search button that's just a magnifying glass icon can have an accessible label of "Search" to help fill in the missing visual affordance.

Here are a few simple suggestions to follow when designing accessible labels:

Be succinct - It can be tedious to listen to long descriptions.
Try not to include control type or state - If the control is coded properly then a screen reader will announce this automatically.
Focus on action verbs - Use "search" not "magnifying glass".

You might consider creating a mock with all of your controls labeled. This can be shared with your development team and QA team for implementation and testing.

Multiple ways to interact with and understand UI #

It's easy to assume that all users interact with the page primarily using a mouse. When designing, consider how someone will interact with a control using a keyboard instead.

Plan your focus states! This means determining what a control will look like when the user focuses it with tab or presses the arrow keys. It's useful to have these states planned early, rather than trying to shoehorn them into the design later.

Finally, for any point of interaction, you want to make sure that the user has multiple ways of understanding the content. Try not to use color alone to convey information, as these subtle cues may be missed by a user with a color vision deficiency. A classic example is an invalid text field. Instead of just a red underline to signify a problem, also consider adding some helper text. That way you're covering more bases and increasing the likelihood that a user will notice the issue.

Developer #

The developer's role is where focus management and semantics combine to form a robust user experience. Below are a few items a developers can keep in mind as they're working on their site or application:

The tab order is logical.
Focus is properly managed and visible.
Interactive elements have keyboard support.
ARIA roles and attributes are applied as needed.
Elements are properly labeled.
Testing is automated.

Logical tab order #

Native elements like input, button, and select get opted into the tab order for free and are automatically focusable with the keyboard. But not all elements receive this same behavior! In particular, generic elements like div, and span, are not opted into the tab order. This means if you use a div to create an interactive control, you'll need to do additional work to make it keyboard accessible.

Two options are:

Give the control a tabindex="0". This will at least make it focusable, though you'll likely need to do additional work to add support for keypresses.
Where possible, consider using a button instead of a div or span for any button-like control. The native button element is very easy to style and gets keyboard support for free.

Managing focus #

When you change the content of the page, it's important to direct the user's attention by moving focus. A classic example of when this technique is useful is when opening a modal dialog. If a user relying on a keyboard presses a button to open a dialog and their focus is not moved into the dialog element, then their only course of action is to tab through the entire site until they eventually find the new control. By moving focus into the new content as soon as it appears, you can improve the efficiency of these users’ experiences.

Keyboard support for interactive elements #

If you're building a custom control like a carousel or dropdown, then you'll need to do some additional work to add keyboard support. The ARIA Authoring Practices Guide is a useful resource which identifies various UI patterns and the kinds of keyboard actions they are expected to support.

To learn more about adding keyboard support to an element, take a look at the roving tabindex section in Google’s Accessibility Fundamentals docs.

ARIA roles and attributes are applied as needed #

Not only do custom controls need proper keyboard support, they also need proper semantics. After all, a div, semantically, is just a generic grouping container. If you're using a div as the basis for your dropdown menu, you'll need to rely on ARIA to layer in additional semantics so the control type can be conveyed to assistive technology. Here again the ARIA Authoring Practices Guide can help by identifying which roles, states, and properties you should be using. As an added bonus, many of the explanations in the ARIA guide also come with sample code!

Labeling elements #

For labeling native inputs, you can use the built-in <label> element as described on MDN. Not only will this help you create an onscreen visual affordance, but it also gives the input an accessible name in the accessibility tree. This name is then picked up by assistive technology (like a screen reader) and announced to the user.

Unfortunately <label> does not support giving an accessible name to custom controls (like ones created using Custom Elements or out of simple divs and spans). For these kinds of controls you'll need to use the aria-label and aria-labelledby attributes.

Automated testing #

Being lazy can be good, especially when it comes to testing. Wherever possible seek to automate your accessibility tests so you don't have to do everything manually. There are a number of great industry testing tools that exist today to make it easy and fast to check for common accessibility issues:

aXe, created by Deque systems, is available as a Chrome extension and a Node module (good for continuous integration environments). This short A11ycast explains a few different ways to incorporate aXe into your development process.

Lighthouse is Google’s open source project for auditing the performance of your Progressive Web Apps. In addition to checking if your PWA has support for things like Service Worker and a Web App Manifest, Lighthouse will also run a series of best practice tests, including tests for accessibility issues.

Conclusion #

Accessibility is a team effort. Everyone has a role to play. This guide has laid out a few key items that each team member can use to quickly ramp up on the subject and hopefully improve the overall experience of their app.

To learn more about accessibility, be sure to check out our free Udacity course and browse the accessibility docs available here on web.dev.

HowTo Components – howto-tabs

2017-04-06T00:00:00Z

Summary #

<howto-tabs> limit visible content by separating it into multiple panels. Only one panel is visible at a time, while all corresponding tabs are always visible. To switch from one panel to another, the corresponding tab has to be selected.

By either clicking or by using the arrow keys the user can change the selection of the active tab.

If JavaScript is disabled, all panels are shown interleaved with the respective tabs. The tabs now function as headings.

Reference #

Demo #

View live demo on GitHub

Example usage #

<style>
  howto-tab {
    border: 1px solid black;
    padding: 20px;
  }
  howto-panel {
    padding: 20px;
    background-color: lightgray;
  }
  howto-tab[selected] {
    background-color: bisque;
  }

If JavaScript does not run, the element will not match :defined. In that case this style adds spacing between tabs and previous panel.

  howto-tabs:not(:defined), howto-tab:not(:defined), howto-panel:not(:defined) {
    display: block;
  }
</style>

<howto-tabs>
  <howto-tab role="heading" slot="tab">Tab 1</howto-tab>
  <howto-panel role="region" slot="panel">Content 1</howto-panel>
  <howto-tab role="heading" slot="tab">Tab 2</howto-tab>
  <howto-panel role="region" slot="panel">Content 2</howto-panel>
  <howto-tab role="heading" slot="tab">Tab 3</howto-tab>
  <howto-panel role="region" slot="panel">Content 3</howto-panel>
</howto-tabs>

Code #

(function() {

Define key codes to help with handling keyboard events.

  const KEYCODE = {
    DOWN: 40,
    LEFT: 37,
    RIGHT: 39,
    UP: 38,
    HOME: 36,
    END: 35,
  };

To avoid invoking the parser with .innerHTML for every new instance, a template for the contents of the shadow DOM is shared by all <howto-tabs> instances.

  const template = document.createElement('template');
  template.innerHTML = `
    <style>
      :host {
        display: flex;
        flex-wrap: wrap;
      }
      ::slotted(howto-panel) {
        flex-basis: 100%;
      }
    </style>
    <slot name="tab"></slot>
    <slot name="panel"></slot>
  `;

HowtoTabs is a container element for tabs and panels.

All children of <howto-tabs> should be either <howto-tab> or <howto-tabpanel>. This element is stateless, meaning that no values are cached and therefore, changes during runtime work.

  class HowtoTabs extends HTMLElement {
    constructor() {
      super();

Event handlers that are not attached to this element need to be bound if they need access to this.

      this._onSlotChange = this._onSlotChange.bind(this);

For progressive enhancement, the markup should alternate between tabs and panels. Elements that reorder their children tend to not work well with frameworks. Instead shadow DOM is used to reorder the elements by using slots.

      this.attachShadow({ mode: 'open' });

Import the shared template to create the slots for tabs and panels.

      this.shadowRoot.appendChild(template.content.cloneNode(true));

      this._tabSlot = this.shadowRoot.querySelector('slot[name=tab]');
      this._panelSlot = this.shadowRoot.querySelector('slot[name=panel]');

This element needs to react to new children as it links up tabs and panel semantically using aria-labelledby and aria-controls. New children will get slotted automatically and cause slotchange to fire, so not MutationObserver is needed.

      this._tabSlot.addEventListener('slotchange', this._onSlotChange);
      this._panelSlot.addEventListener('slotchange', this._onSlotChange);
    }

connectedCallback() groups tabs and panels by reordering and makes sure exactly one tab is active.

    connectedCallback() {

The element needs to do some manual input event handling to allow switching with arrow keys and Home / End.

      this.addEventListener('keydown', this._onKeyDown);
      this.addEventListener('click', this._onClick);

      if (!this.hasAttribute('role'))
        this.setAttribute('role', 'tablist');

Up until recently, slotchange events did not fire when an element was upgraded by the parser. For this reason, the element invokes the handler manually. Once the new behavior lands in all browsers, the code below can be removed.

      Promise.all([
        customElements.whenDefined('howto-tab'),
        customElements.whenDefined('howto-panel'),
      ])
        .then(() => this._linkPanels());
    }

disconnectedCallback() removes the event listeners that connectedCallback() added.

    disconnectedCallback() {
      this.removeEventListener('keydown', this._onKeyDown);
      this.removeEventListener('click', this._onClick);
    }

_onSlotChange() is called whenever an element is added or removed from one of the shadow DOM slots.

    _onSlotChange() {
      this._linkPanels();
    }

_linkPanels() links up tabs with their adjacent panels using aria-controls and aria-labelledby. Additionally, the method makes sure only one tab is active.

    _linkPanels() {
      const tabs = this._allTabs();

Give each panel a aria-labelledby attribute that refers to the tab that controls it.

      tabs.forEach((tab) => {
        const panel = tab.nextElementSibling;
        if (panel.tagName.toLowerCase() !== 'howto-panel') {
          console.error(`Tab #${tab.id} is not a` +
            `sibling of a <howto-panel>`);
          return;
        }

        tab.setAttribute('aria-controls', panel.id);
        panel.setAttribute('aria-labelledby', tab.id);
      });

The element checks if any of the tabs have been marked as selected. If not, the first tab is now selected.

      const selectedTab =
        tabs.find((tab) => tab.selected) || tabs[0];

Next, switch to the selected tab. _selectTab() takes care of marking all other tabs as deselected and hiding all other panels.

      this._selectTab(selectedTab);
    }

_allPanels() returns all the panels in the tab panel. This function could memorize the result if the DOM queries ever become a performance issue. The downside of memorization is that dynamically added tabs and panels will not be handled.

This is a method and not a getter, because a getter implies that it is cheap to read.

    _allPanels() {
      return Array.from(this.querySelectorAll('howto-panel'));
    }

_allTabs() returns all the tabs in the tab panel.

    _allTabs() {
      return Array.from(this.querySelectorAll('howto-tab'));
    }

_panelForTab() returns the panel that the given tab controls.

    _panelForTab(tab) {
      const panelId = tab.getAttribute('aria-controls');
      return this.querySelector(`#${panelId}`);
    }

_prevTab() returns the tab that comes before the currently selected one, wrapping around when reaching the first one.

    _prevTab() {
      const tabs = this._allTabs();

Use findIndex() to find the index of the currently selected element and subtracts one to get the index of the previous element.

      let newIdx = tabs.findIndex((tab) => tab.selected) - 1;

Add tabs.length to make sure the index is a positive number and get the modulus to wrap around if necessary.

      return tabs[(newIdx + tabs.length) % tabs.length];
    }

_firstTab() returns the first tab.

    _firstTab() {
      const tabs = this._allTabs();
      return tabs[0];
    }

_lastTab() returns the last tab.

    _lastTab() {
      const tabs = this._allTabs();
      return tabs[tabs.length - 1];
    }

_nextTab() gets the tab that comes after the currently selected one, wrapping around when reaching the last tab.

    _nextTab() {
      const tabs = this._allTabs();
      let newIdx = tabs.findIndex((tab) => tab.selected) + 1;
      return tabs[newIdx % tabs.length];
    }

reset() marks all tabs as deselected and hides all the panels.

    reset() {
      const tabs = this._allTabs();
      const panels = this._allPanels();

      tabs.forEach((tab) => tab.selected = false);
      panels.forEach((panel) => panel.hidden = true);
    }

_selectTab() marks the given tab as selected. Additionally, it unhides the panel corresponding to the given tab.

    _selectTab(newTab) {

Deselect all tabs and hide all panels.

      this.reset();

Get the panel that the newTab is associated with.

      const newPanel = this._panelForTab(newTab);

If that panel doesn’t exist, abort.

      if (!newPanel)
        throw new Error(`No panel with id ${newPanelId}`);
      newTab.selected = true;
      newPanel.hidden = false;
      newTab.focus();
    }

_onKeyDown() handles key presses inside the tab panel.

    _onKeyDown(event) {

If the keypress did not originate from a tab element itself, it was a keypress inside the a panel or on empty space. Nothing to do.

      if (event.target.getAttribute('role') !== 'tab')
        return;

Don’t handle modifier shortcuts typically used by assistive technology.

      if (event.altKey)
        return;

The switch-case will determine which tab should be marked as active depending on the key that was pressed.

      let newTab;
      switch (event.keyCode) {
        case KEYCODE.LEFT:
        case KEYCODE.UP:
          newTab = this._prevTab();
          break;

        case KEYCODE.RIGHT:
        case KEYCODE.DOWN:
          newTab = this._nextTab();
          break;

        case KEYCODE.HOME:
          newTab = this._firstTab();
          break;

        case KEYCODE.END:
          newTab = this._lastTab();
          break;

Any other key press is ignored and passed back to the browser.

        default:
          return;
      }

The browser might have some native functionality bound to the arrow keys, home or end. The element calls preventDefault() to prevent the browser from taking any actions.

      event.preventDefault();

Select the new tab, that has been determined in the switch-case.

      this._selectTab(newTab);
    }

_onClick() handles clicks inside the tab panel.

    _onClick(event) {

If the click was not targeted on a tab element itself, it was a click inside the a panel or on empty space. Nothing to do.

      if (event.target.getAttribute('role') !== 'tab')
        return;

If it was on a tab element, though, select that tab.

      this._selectTab(event.target);
    }
  }

  customElements.define('howto-tabs', HowtoTabs);

howtoTabCounter counts the number of <howto-tab> instances created. The number is used to generated new, unique IDs.

  let howtoTabCounter = 0;

HowtoTab is a tab for a <howto-tabs> tab panel. <howto-tab> should always be used with role="heading" in the markup so that the semantics remain useable when JavaScript is failing.

A <howto-tab> declares which <howto-panel> it belongs to by using that panel’s ID as the value for the aria-controls attribute.

A <howto-tab> will automatically generate a unique ID if none is specified.

  class HowtoTab extends HTMLElement {

    static get observedAttributes() {
      return ['selected'];
    }

    constructor() {
      super();
    }

    connectedCallback() {

If this is executed, JavaScript is working and the element changes its role to tab.

      this.setAttribute('role', 'tab');
      if (!this.id)
        this.id = `howto-tab-generated-${howtoTabCounter++}`;

Set a well-defined initial state.

      this.setAttribute('aria-selected', 'false');
      this.setAttribute('tabindex', -1);
      this._upgradeProperty('selected');
    }

Check if a property has an instance value. If so, copy the value, and delete the instance property so it doesn't shadow the class property setter. Finally, pass the value to the class property setter so it can trigger any side effects. This is to safe guard against cases where, for instance, a framework may have added the element to the page and set a value on one of its properties, but lazy loaded its definition. Without this guard, the upgraded element would miss that property and the instance property would prevent the class property setter from ever being called.

    _upgradeProperty(prop) {
      if (this.hasOwnProperty(prop)) {
        let value = this[prop];
        delete this[prop];
        this[prop] = value;
      }
    }

Properties and their corresponding attributes should mirror one another. To this effect, the property setter for selected handles truthy/falsy values and reflects those to the state of the attribute. It’s important to note that there are no side effects taking place in the property setter. For example, the setter does not set aria-selected. Instead, that work happens in the attributeChangedCallback. As a general rule, make property setters very dumb, and if setting a property or attribute should cause a side effect (like setting a corresponding ARIA attribute) do that work in the attributeChangedCallback(). This will avoid having to manage complex attribute/property reentrancy scenarios.

    attributeChangedCallback() {
      const value = this.hasAttribute('selected');
      this.setAttribute('aria-selected', value);
      this.setAttribute('tabindex', value ? 0 : -1);
    }

    set selected(value) {
      value = Boolean(value);
      if (value)
        this.setAttribute('selected', '');
      else
        this.removeAttribute('selected');
    }

    get selected() {
      return this.hasAttribute('selected');
    }
  }

  customElements.define('howto-tab', HowtoTab);

  let howtoPanelCounter = 0;

HowtoPanel is a panel for a <howto-tabs> tab panel.

class HowtoPanel extends HTMLElement {

  constructor() {
    super();
  }

  connectedCallback() {
    this.setAttribute('role', 'tabpanel');
    if (!this.id)
      this.id = `howto-panel-generated-${howtoPanelCounter++}`;
  }
}

customElements.define('howto-panel', HowtoPanel);
})();

HowTo Components – howto-tooltip

2017-04-06T00:00:00Z

Summary #

A <howto-tooltip> is a popup that displays information related to an element when the element receives keyboard focus or the mouse hovers over it. The element that triggers the tooltip references the tooltip element with aria-describedby.

The element self-applies the role tooltip and sets tabindex to -1, as the tooltip itself can never be focused.

Reference #

Demo #

View live demo on GitHub

Example usage #

<div class="text">
<label for="name">Your name:</label>
<input id="name" aria-describedby="tp1"/>
<howto-tooltip id="tp1">Ideally your name is Batman</howto-tooltip>
<br>
<label for="cheese">Favourite type of cheese: </label>
<input id="cheese" aria-describedby="tp2"/>
<howto-tooltip id="tp2">Help I am trapped inside a tooltip message</howto-tooltip>

Code #

class HowtoTooltip extends HTMLElement {

The constructor does work that needs to be executed exactly once.

  constructor() {
    super();

These functions are used in a bunch of places, and always need to bind the correct this reference, so do it once.

    this._show = this._show.bind(this);
    this._hide = this._hide.bind(this);
}

connectedCallback() fires when the element is inserted into the DOM. It's a good place to set the initial role, tabindex, internal state, and install event listeners.

  connectedCallback() {
    if (!this.hasAttribute('role'))
      this.setAttribute('role', 'tooltip');

    if (!this.hasAttribute('tabindex'))
      this.setAttribute('tabindex', -1);

    this._hide();

The element that triggers the tooltip references the tooltip element with aria-describedby.

    this._target = document.querySelector('[aria-describedby=' + this.id + ']');
    if (!this._target)
      return;

The tooltip needs to listen to focus/blur events from the target, as well as hover events over the target.

    this._target.addEventListener('focus', this._show);
    this._target.addEventListener('blur', this._hide);
    this._target.addEventListener('mouseenter', this._show);
    this._target.addEventListener('mouseleave', this._hide);
  }

disconnectedCallback() unregisters the event listeners that were set up in connectedCallback().

  disconnectedCallback() {
    if (!this._target)
      return;

Remove the existing listeners, so that they don't trigger even though there's no tooltip to show.

    this._target.removeEventListener('focus', this._show);
    this._target.removeEventListener('blur', this._hide);
    this._target.removeEventListener('mouseenter', this._show);
    this._target.removeEventListener('mouseleave', this._hide);
    this._target = null;
  }

  _show() {
    this.hidden = false;
  }

  _hide() {
    this.hidden = true;
  }
}

customElements.define('howto-tooltip', HowtoTooltip);

HowTo Components – Overview

2017-04-06T00:00:00Z

"HowTo: Components" are a collection of web components that implement common UI patterns. The purpose of these implementations is to be an educational resource. You can read through the densely commented implementation of different components and hopefully learn from them. Note that they are explicitly NOT a UI library and should NOT be used in production.

Components #

<howto-checkbox>: represents a boolean option in a form. The most common type of checkbox is a dual-type which allows the user to toggle between two choices—checked and unchecked.
<howto-tabs>: limits visible content by separating it into multiple panels.
<howto-tooltip>: a popup that displays information related to an element when the element receives keyboard focus or the mouse hovers over it.

Goals #

Our aim is to demonstrate best practices for writing robust components that are accessible, performant, maintainable, and easy to style. Each component is completely self-contained so it can serve as a reference implementation.

Accessibility #

The components closely follow the WAI ARIA Authoring Practices, which is a guide to explain and show ARIA, the Accessible Rich Internet Application standard. If you are unfamiliar with ARIA, check out our introduction on WebFundamentals. Each component links to the relevant section of the Authoring Practices. While not strictly necessary, we do recommend reading the section of the Authoring Practices before diving into the code.

Performance #

In web development the term "performance" can be applied to a multitude of things. In the context of <howto>, performance mostly refers to animations consistently running at 60fps, even on mobile devices.

Visual Flexibility #

As much as possible, components are not styled, except for layout or to indicate a selected or active state. This is to keep the implementation visually flexible and focused. By not spending time on decoration, we limit the code to only what is absolutely necessary to make the component function. If any style is required for the component to function, the style will be marked with a comment explaining why that is.

Maintainable code #

As HowTo: Components is a reference implementation, we spent extra time on writing readable and easily comprehensible code that is densely commented.

Non-Goals #

Be a library / framework / toolkit #

<howto> components are not published on npm, bower or any other platform because they are not meant to be used in production. For the sake of terse, readable code, we are using modern JavaScript APIs and are supporting modern browsers which implement the Web Components standards. You will be able to adapt the code to fit your own needs after reading these implementations.

Be backwards compatible #

The code should not be relied on directly. We might, and very likely will, drastically change the implementation and API of any element if a better implementation is discovered. This is a living resource where we can share, explore, and discuss best practices for building web UIs.

Be complete #

We currently don't (and probably won't) implement *all *components that can be found in the WAI ARIA Authoring Practices. However, re-using the principles used in other <howto> components should enable readers to implement any components that are missing.

How To Do an Accessibility Review

2017-03-12T00:00:00Z

Determining if your web site or application is accessible can seem like an overwhelming task. If you are approaching accessibility for the first time, the sheer breadth of the topic can leave you wondering where to start - after all, working to accommodate a diverse range of abilities means there are a correspondingly diverse range of issues to consider.

In this post, I'm going to break down these issues into a logical, step by step process for reviewing an existing site for accessibility.

Start with the keyboard #

For users who either cannot or choose not to use a mouse, keyboard navigation is their primary means of reaching everything on screen. This audience includes users with motor impairments, such as Repetitive Stress Injury (RSI) or paralysis, as well as screen reader users. For a good keyboarding experience aim to have a logical tab order and easily discernable focus styles.

Key points #

Start by tabbing through your site. The order in which elements are focused should aim to follow the DOM order. If you’re unsure which elements should receive focus, see Focus Fundamentals for a refresher. The general rule of thumb is that any control a user can interact with or provide input to should aim to be focusable and display a focus indicator (e.g., a focus ring). It’s common practice to disable focus styles without providing an alternative by using outline: none in CSS, but this is an anti-pattern. If a keyboard user can’t see what’s focused, they have no way of interacting with the page. If you need to differentiate between mouse and keyboard focus for styling, consider adding a library like what-input.
Custom interactive controls should aim to be focusable. If you use JavaScript to turn a <div> into a fancy dropdown, it will not automatically be inserted into the tab order. To make a custom control focusable, give it a tabindex="0".
Avoid controls with a tabindex > 0. These controls will jump ahead of everything else in the tab order, regardless of their position in the DOM. This can be confusing for screen reader users as they tend to navigate the DOM in a linear fashion.
Non-interactive content (e.g., headings) should avoid being focusable. Sometimes developers add a tabindex to headings because they think they’re important. This is also an anti-pattern because it makes keyboard users who can see the screen less efficient. For screen reader users, the screen reader will already announce these headings, so there’s no need to make them focusable.
If new content is added to the page, try to make sure that the user’s focus is directed to that content so they can take action on it. See Managing Focus at the Page Level for examples.
Beware of completely trapping focus at any point. Watch out for autocomplete widgets, where keyboard focus may get stuck. Focus can be temporarily trapped in specific situations, such as displaying a modal, when you don't want the user interacting with the rest of the page - but you should aim to provide a keyboard-accessible method of escaping the modal as well. See the guide on Modals and Keyboard Traps for an example.

Just because something is focusable doesn’t mean it’s usable #

If you’ve built a custom control, then aim for a user to be able to reach all of its functionality using only the keyboard. See Managing Focus In Components for techniques on improving keyboard access.

Don’t forget offscreen content #

Many sites have offscreen content that is present in the DOM but not visible, for example, links inside a responsive drawer menu or a button inside a modal window that has yet to be displayed. Leaving these elements in the DOM can lead to a confusing keyboarding experience, especially for screen readers which will announce the offscreen content as if it’s part of the page. See Handling Offscreen Content for tips on how to deal with these elements.

Improving general keyboard support lays some groundwork for the next step, which is to check the page for proper labeling and semantics and any obstructions to screen reader navigation. If you’re unfamiliar with how semantic markup gets interpreted by assistive technology, see the Introduction to Semantics for a refresher.

Key points #

Check all images for proper alt text. The exception to this practice is when images are primarily for presentation purposes and are not essential pieces of content. To signify that an image should be skipped by a screen reader, set the value of the alt attribute to an empty string, e.g., alt="".
Check all controls for a label. For custom controls this may require the use of aria-label or aria-labelledby. See ARIA Labels and Relationships for examples.
Check all custom controls for an appropriate role and any required ARIA attributes that confer their state. For example, a custom checkbox will need a role="checkbox" and aria-checked="true|false" to properly convey its state. See the Introduction to ARIA for a general overview of how ARIA can provide missing semantics for custom controls.
The flow of information should make sense. Because screen readers navigate the page in DOM order, if you’ve used CSS to visually reposition elements, they may be announced in a nonsensical sequence. If you need something to appear earlier in the page, try to physically move it earlier in the DOM.
Aim to support a screen reader’s navigation to all content on the page. Avoid letting any sections of the site be permanently hidden or blocked from screen reader access.
If content should be hidden from a screen reader, for instance, if it’s offscreen or just presentational, make sure that content is set to aria-hidden="true". Take a look at the guide on Hiding content for further explanation.

Though it might seem daunting to learn a screen reader, they’re actually pretty easy to pick up. In general, most developers can get by with just a few simple key commands.

If you’re on a Mac check out this video on using VoiceOver, the screen reader that comes with Mac OS. If you’re on a PC check out this video on using NVDA, a donation supported, open source screen reader for Windows.

`aria-hidden` does not prevent keyboard focus #

It’s important to understand that ARIA can only affect the semantics of an element; it has no effect on the behavior of the element. While you can make an element hidden to screen readers with aria-hidden="true", that does not change the focus behavior for that element. For offscreen interactive content, you will often need to combine aria-hidden="true" and tabindex="-1" to make sure it’s truly removed from the keyboard flow. The proposed inert attribute aims to make this easier by combining the behavior of both attributes.

Interactive elements like links and buttons should indicate their purpose and state #

Providing visual hints about what a control will do helps people operate and navigate your site. These hints are called affordances. Providing affordances makes it possible for people to use your site on a wide variety of devices.

Key points #

Interactive elements, like links and buttons, should be distinguishable from non-interactive elements. It is difficult for users to navigate a site or app when they cannot tell if an element is clickable. There are many valid methods to accomplish this goal. One common practice is underlining links to differentiate them from their surrounding text.
Similar to the focus requirement, interactive elements like links and buttons require a hover state for mouse users so they know if they are hovering over something clickable. However, the interactive element still must be distinguishable on its own. Relying on a hover state alone to indicate clickable elements does not help touch screen devices.

Take advantage of headings and landmarks #

Headings and landmark elements imbue your page with semantic structure, and greatly increase the navigating efficiency of assistive technology users. Many screen reader users report that, when they first land on an unfamiliar page, they typically try to navigate by headings. Similarly, screen readers also offer the ability to jump to important landmarks like <main> and <nav>. For these reasons it’s important to consider how the structure of your page can be used to guide the user’s experience.

Key points #

Make proper use of h1-h6 hierarchy. Think of headings as tools to create an outline for your page. Don’t rely on the built-in styling of headings; instead, consider all headings as if they were the same size and use the semantically appropriate level for primary, secondary, and tertiary content. Then use CSS to make the headings match your design.
Use landmark elements and roles so users can bypass repetitive content. Many assistive technologies provide shortcuts to jump to specific parts of the page, such as those defined by <main> or <nav> elements. These elements have implicit landmark roles. You can also use the ARIA role attribute to explicitly define regions on the page, e.g., <div role="search">. See the guide on headings and landmarks for more examples.
Avoid role="application" unless you have prior experience working with it. The application landmark role will tell assistive technology to disable its shortcuts and pass through all key presses to the page. This means that the keys screen reader users typically use to move around the page will no longer work, and you will need to implement all keyboard handling yourself.

Screen readers like VoiceOver and NVDA provide a context menu for skipping to important regions on the page. If you’re doing an accessibility check, you can use these menus to get a quick overview of the page and determine if heading levels are appropriate and which landmarks are in use. To learn more check out these instructional videos on the basics of VoiceOver and NVDA.

Automate the process #

Manually testing a site for accessibility can be tedious and error prone. Eventually you’ll want to automate the process as much as possible. This can be done through the use of browser extensions, and command line accessibility test suites.

Key points #

Does the page pass all the tests from either the aXe or WAVE browser extensions? These extensions are just two available options and can be a useful addition to any manual test process as they can quickly pick up on subtle issues like failing contrast ratios and missing ARIA attributes. If you prefer to do things from the command line, axe-cli provides the same functionality as the aXe browser extension, but can be easily run from your terminal.
To avoid regressions, especially in a continuous integration environment, incorporate a library like axe-core into your automated test suite. axe-core is the same engine that powers the aXe chrome extension, but in an easy-to-run command line utility.
If you’re using a framework or library, does it provide its own accessibility tools? Some examples include protractor-accessibility-plugin for Angular, and a11ysuite for Polymer and Web Components. Take advantage of available tools whenever possible to avoid reinventing the wheel.

If you’re building a Progressive Web App consider giving Lighthouse a shot #

Lighthouse is a tool to help measure the performance of your progressive web app, but it also uses the axe-core library to power a set of accessibility tests. If you’re already using Lighthouse, keep an eye out for failing accessibility tests in your report. Fixing these will help improve the overall user experience of your site.

Wrapping Up #

Making accessibility reviews a regular part of your team process, and doing these checks early and often, can help improve the overall experience of using your site. Remember, good accessibility equals good UX!

Additional Resources #

DOM Order Matters

2016-10-04T00:00:00Z

Working with native elements is a great way to learn about focus behavior because they are automatically inserted into the tab order based on their position in the DOM.

For example, you might have three button elements, one after the other in the DOM. Pressing Tab focuses each button in order. Try clicking the code block below to move the focus navigation start point, then press Tab to move focus through the buttons.

<button>I Should</button>
<button>Be Focused</button>
<button>Last!</button>

However, it's important to note that, using CSS, it's possible to have things exist in one order in the DOM but appear in a different order on screen. For example, if you use a CSS property like float to move one button to the right, the buttons appear in a different order on screen. But, because their order in the DOM remains the same, so does their tab order. When the user tabs through the page, the buttons gain focus in a non-intuitive order. Try clicking on the code block below to move the focus navigation start point, then press Tab to move focus through the buttons.

<button style="float: right">I Should</button>
<button>Be Focused</button>
<button>Last!</button>

Be careful when changing the visual position of elements on screen using CSS. This can cause the tab order to jump around, seemingly at random, confusing users who rely on the keyboard. For this reason, the Web AIM checklist states in section 1.3.2 that the reading and navigation order, as determined by code order, should be logical and intuitive.

As a rule, try tabbing through your pages every so often just to make sure you haven't accidentally messed up the tab order. It's a good habit to adopt, and one that doesn't require much effort.

Offscreen content #

What if you have content that isn't currently displayed, yet still needs to be in the DOM, such as a responsive side-nav? When you have elements like this that receive focus when they're off screen, it can seem as if the focus is disappearing and reappearing as the user tabs through the page — clearly an undesirable effect. Ideally, we should prevent the panel from gaining focus when it's off screen, and only allow it to be focused when the user can interact with it.

Sometimes you need to do a bit of detective work to figure out where focus has gone. You can use document.activeElement from the console to figure out which element is currently focused.

Once you know which off screen element is being focused, you can set it to display: none or visibility: hidden, and then set it back to display: block or visibility: visible before showing it to the user.

In general, we encourage developers to tab through their sites before each publish to see that the tab order doesn't disappear or jump out of a logical sequence. If it does, you should make sure you are appropriately hiding offscreen content with display: none or visibility: hidden, or that you rearrange elements' physical positions in the DOM so they are in a logical order.

Introduction to Focus

2016-10-04T00:00:00Z

In this lesson we'll talk about focus and how you can manage it in your application. Focus refers to which control on the screen (an input item such as a field, checkbox, button, or link) currently receives input from the keyboard, and from the clipboard when you paste content.

This is a great place to start learning about accessibility because we all know how to use a keyboard, it's easy to relate to and test, and it benefits virtually all users.

Users with motor impairments, which could be anything from permanent paralysis to a sprained wrist, may rely on a keyboard or switch device to navigate your page, so a good focus strategy is critical to providing a good experience for them.

And for the power users who know every keyboard shortcut on their machine, being able to quickly navigate your site with the keyboard alone will certainly make them more productive.

Thus, a well implemented focus strategy ensures that everyone using your application has a better experience. We'll see in the upcoming lessons that the effort you put into focus is an important basis for supporting assistive technology users and, indeed, all users.

What is focus? #

Focus determines where keyboard events go in the page at any given moment. For instance, if you focus a text input field and begin typing, the input field receives the keyboard events and displays the characters you type. While it has focus, it will also receive pasted input from the clipboard.

The currently focused item is often indicated by a focus ring, the style of which depends on both the browser and on any styling the page author has applied. Chrome, for instance, typically highlights focused elements with a blue border, whereas Firefox uses a dashed border.

Some users operate their computer almost entirely with the keyboard or other input device. For those users, focus is critical; it's their primary means of reaching everything on the screen. For that reason, the Web AIM checklist states in section 2.1.1 that all page functionality should be available using the keyboard, unless it's something you cannot do with a keyboard, such as freehand drawing.

As a user, you can control which element is currently focused using Tab, Shift+Tab, or the arrow keys. On Mac OSX this works a little differently: while Chrome always lets you navigate with Tab, you need to press Option+Tab to change focus in other browsers like Safari. (You can change this setting in the Keyboard section of System Preferences.)

The order in which focus proceeds forward and backward through interactive elements via Tab is called, not surprisingly, the tab order. Ensuring that you design your page with a logical tab order is an important step that we'll cover later.

What is focusable? #

Built-in interactive HTML elements like text fields, buttons, and select lists are implicitly focusable, meaning they are automatically inserted into the tab order and have built-in keyboard event handling without developer intervention.

But not all elements are focusable; paragraphs, divs, and various other page elements are not focused as you tab through the page, and that's by design. There's generally no need to focus something if the user can't interact with it.

Experiencing focus #

Let's try some of the focus techniques we just discussed. Using Chrome, go to this airline site mockup page and search for a specific ticket using only keyboard input. The page doesn't accept mouse input, so you can't fudge the exercise (not that we don't trust you ;-).

The ticket parameters you should specify are:

one way
to Melbourne
leaving on 12 October 2017 (10/12/2017)
returning on 23 October 2017 (10/23/2017)
window seat
do not want to receive promotional offers

When you successfully complete the form with no input errors and activate the Search button, the form will simply clear and reset. Go ahead and complete the form, then come back.

Let's examine how the form uses your keyboard input. Starting with your first few Tab presses, the browser highlights the navigation items for Flights, Hotels, and Rental Cars. As you continue to press Tab you proceed to the radiobutton group where you can choose from Round Trip, One Way, or Multi City using the arrow keys.

Continue through the name and address fields, filling in the required information. When you arrive at the destination select element, you can use the arrow keys to choose a city, or you can start typing to autocomplete the field. Similarly, in the date fields, you can use the arrow keys or just type a date.

Selecting a seat type also relies on the arrow keys, or you can type "w", "a", or "n" to jump to a seat option. Then you can disable the promotional offers default by pressing the spacebar while the checkbox is focused. Finally, focus the Search button and press Enter to submit the form.

It's very handy to interact with a form using just the keyboard and to not have to switch to the mouse and back to complete a task. Because all of the elements used in the form are native HTML tags with implicit focus, the form works fine with the keyboard, and you don't have to write any code to add or manage focus behavior.

Using tabindex

2016-10-04T00:00:00Z

The default tab order provided by the DOM position of native elements is convenient, but there are times when you'll want to modify the tab order, and physically moving elements in the HTML isn't always an optimal, or even a feasible, solution. For these cases you can use the tabindex HTML attribute to explicitly set an element's tab position.

Browser support

Chrome 1, Supported 1
Firefox 1.5, Supported 1.5
Edge 12, Supported 12
Safari ≤4, Supported ≤4

Source

tabindex can be applied to any element - although it is not necessarily useful on every element - and takes a range of integer values. Using tabindex, you can specify an explicit order for focusable page elements, insert an otherwise unfocusable element into the tab order, and remove elements from the tab order. For example:

tabindex="0": Inserts an element into the natural tab order. The element can be focused by pressing the Tab key, and the element can be focused by calling its focus() method

<custom-button tabindex="0">Press Tab to Focus Me!</custom-button>

Press Tab to Focus Me!

tabindex="-1": Removes an element from the natural tab order, but the element can still be focused by calling its focus() method

<button id="foo" tabindex="-1">I'm not keyboard focusable</button>
<button onclick="foo.focus();">Focus my sibling</button>

tabindex="5": Any tabindex greater than 0 jumps the element to the front of the natural tab order. If there are multiple elements with a tabindex greater than 0, the tab order starts from the lowest value that is greater than zero and works its way up. Using a tabindex greater than 0 is considered an anti-pattern.

<button>I should be first</button>
<button>And I should be second</button>
<button tabindex="5">But I jumped to the front!</button>

This is particularly true of non-input elements like headers, images, or article titles. Adding tabindex to those kinds of elements is counter-productive. If possible, it's best to arrange your source code so the DOM sequence provides a logical tab order. If you do use tabindex, restrict it to custom interactive controls like buttons, tabs, dropdowns, and text fields; that is, elements the user might expect to provide input to.

Don't worry about screen reader users missing important content because it doesn't have a tabindex. Even if the content is very important, like an image, if it's not something the user can interact with, there's no reason to make it focusable. Screen reader users can still understand the content of the image so long as you provide proper alt attribute support, which we'll cover shortly.

Managing focus at the page level #

Here's a scenario where tabindex is not only useful, but necessary. You might be building a robust single page with different content sections, not all of which are simultaneously visible. In this kind of page, clicking a navigation link might change the visible content without doing a page refresh.

When this happens, you would probably identify the selected content area, give it a tabindex of -1 so that it doesn't appear in the natural tab order, and call its focus method. This technique, called managing focus, keeps the user's perceived context in sync with the site's visual content.

Managing focus in components #

Managing focus when you change something on the page is important, but sometimes you need to manage focus at the control level — for example, if you're building a custom component.

Consider the native select element. It can receive basic focus but, once there, you can use the arrow keys to expose additional functionality (the selectable options). If you were building a custom select element, you would want to expose these same kinds of behaviors so that users who rely primarily on the keyboard could still interact with your control.

<!-- Focus the element using Tab and use the up/down arrow keys to navigate -->
<select>
    <option>Aisle seat</option>
    <option>Window seat</option>
    <option>No preference</option>
</select>

Knowing which keyboard behaviors to implement can be difficult, but there is a helpful document you can refer to. The Accessible Rich Internet Applications (ARIA) Authoring Practices guide lists types of components and what kinds of keyboard actions they support. We will cover ARIA in more detail later, but for now let's use the guide to help us add keyboard support to a new component.

Perhaps you're working on some new Custom Elements that resemble a set of radio buttons, but with your unique take on appearance and behavior.

<radio-group>
    <radio-button>Water</radio-button>
    <radio-button>Coffee</radio-button>
    <radio-button>Tea</radio-button>
    <radio-button>Cola</radio-button>
    <radio-button>Ginger Ale</radio-button>
</radio-group>

To determine what kind of keyboard support they need, you would check the ARIA Authoring Practices guide. Section 2 contains a list of design patterns, and in that list is a characteristics table for radio groups, the existing component that most closely matches your new element.

As you can see in the table, one of the common keyboard behaviors that should be supported is the up/down/left/right arrow keys. To add this behavior to the new component, we'll use a technique called roving tabindex.

Roving tabindex works by setting tabindex to -1 for all children except the currently-active one.

<radio-group>
    <radio-button tabindex="0">Water</radio-button>
    <radio-button tabindex="-1">Coffee</radio-button>
    <radio-button tabindex="-1">Tea</radio-button>
    <radio-button tabindex="-1">Cola</radio-button>
    <radio-button tabindex="-1">Ginger Ale</radio-button>
</radio-group>

The component then uses a keyboard event listener to determine which key the user presses; when this happens, it sets the previously focused child's tabindex to -1, sets the to-be-focused child's tabindex to 0, and calls the focus method on it.

<radio-group>
    // Assuming the user pressed the down arrow, we'll focus the next available child
    <radio-button tabindex="-1">Water</radio-button>
    <radio-button tabindex="0">Coffee</radio-button> // call .focus() on this element
    <radio-button tabindex="-1">Tea</radio-button>
    <radio-button tabindex="-1">Cola</radio-button>
    <radio-button tabindex="-1">Ginger Ale</radio-button>
</radio-group>

When the user reaches the last (or first, depending on the direction they're moving the focus) child, you will loop around and focus the first (or last) child again.

You can give the completed example a try down below. Inspect the element in the DevTools to observe the tabindex moving from one radio to the next.

Water

Coffee

Tea

Cola

Ginger Ale

You can view the complete source for this element over on GitHub.

Modals and keyboard traps #

Sometimes when you're managing focus you can get into a situation you can't get out of. Consider an autocomplete widget that tries to manage focus and captures the tab behavior, but prevents the user from leaving it until it's complete. This is called a keyboard trap, and it can be very frustrating for the user. Section 2.1.2 of the Web AIM checklist addresses this issue, stating that keyboard focus should never be locked or trapped at one particular page element. The user should be able to navigate to and from all page elements using only the keyboard.

Oddly, there are times when this behavior is actually desirable, like in a modal window. Normally, when the modal is displayed, you don't want the user to access the content behind it. You might add an overlay to cover the page visually, but that doesn't stop keyboard focus from accidentally traveling outside the modal.

In instances like this you can implement a temporary keyboard trap to ensure that you trap focus only while the modal is displayed and then restore focus to the previously-focused item when the modal is closed.

There are some proposals on how to make this easier for developers, including the <dialog> element, but they don't yet have widespread browser support.

See this MDN article for more information on <dialog>, and this modal example for more information on modal windows.

Consider a modal dialog represented by a div that contains a few elements, and another div that represents a background overlay. Let's walk through the basic steps needed to implement a temporary keyboard trap in this situation.

Using document.querySelector, select the modal and overlay divs and store their references.
As the modal opens, store a reference to the element that was focused when the modal was opened so you can return focus to that element.
Use a keydown listener to grab keys as they are pressed while the modal is open. You could also listen for a click on the background overlay, and close the modal if the user clicks it.
Next, get the collection of focusable elements within the modal. The first and last focusable elements will act as "sentinels" to let you know when to loop focus forward or backward to stay inside the modal.
Display the modal window and focus the first focusable element.
As the user presses Tab or Shift+Tab, move focus forward or backward, looping at the last or first elements as appropriate.
If the user presses Esc, close the modal. This is very helpful because it allows the user to close the modal without searching for a specific close button, and it benefits even users who are using a mouse.
When the modal is closed, hide it and the background overlay, and restore focus to the previously-focused element saved earlier.

This procedure gives you a usable, non-frustrating modal window that everyone can use effectively.

For more details, you can examine this sample code, and view a live example from a completed page.

Accessibility

2016-06-26T00:00:00Z

This document set is a text-based version of part of the content covered in the Udacity course on Accessibility. Rather than a direct transcription of the video course, it is meant to be a more concise treatment of accessibility principles and practices, using the course's original content as a base.

Summary #

Learn what accessibility means and how it applies to web development.
Learn how to make websites accessible and usable for everyone.
Learn how to include basic accessibility with minimal development impact.
Learn what HTML features are available and how to use them to improve accessibility.
Learn about advanced accessibility techniques for creating polished accessibility experiences.

Understanding accessibility, its scope, and its impact can make you a better web developer. This guide is intended to help you understand how you can make your websites accessible and usable for everyone.

"Accessibility" can be difficult to spell, but it doesn't have to be difficult to accomplish. In this guide, you will see how to get some easy wins to help improve accessibility with minimal effort, how you can use what's built in to HTML to create more accessible and robust interfaces, and how to leverage some advanced techniques for creating polished accessible experiences.

You'll also find that many of these techniques will help you create interfaces that are more pleasant and easy to use for all users, not just for those with disabilities.

Of course, many developers have only a hazy understanding of what accessibility means - something to do with government contracts, checklists, and screen readers, right? - and there are plenty of misconceptions floating around. For example, many developers feel that addressing accessibility will force them to choose between creating a delightful and attractive experience, and one that is clunky and ugly but accessible.

That is, of course, not the case at all, so let's clear that up before we get into anything else. What do we mean by accessibility, and what are we here to learn about?

What is accessibility? #

Broadly speaking, when we say a site is accessible, we mean that the site's content is available, and its functionality can be operated, by literally anyone. As developers, it's easy to assume that all users can see and use a keyboard, mouse, or touch screen, and can interact with your page content the same way you do. This can lead to an experience that works well for some people, but creates issues that range from simple annoyances to show-stoppers for others.

Accessibility, then, refers to the experience of users who might be outside the narrow range of the "typical" user, who might access or interact with things differently than you expect. Specifically, it concerns users who are experiencing some type of impairment or disability - and bear in mind that that experience might be non-physical or temporary.

For example, although we tend to center our discussion of accessibility on users with physical impairments, we can all relate to the experience of using an interface that is not accessible to us for other reasons. Have you ever had a problem using a desktop site on a mobile phone, or seen the message "This content is not available in your area", or been unable to find a familiar menu on a tablet? Those are all accessibility issues.

As you learn more, you'll find that addressing accessibility issues in this broader, more general sense almost always improves the user experience for everyone. Let's look at an example:

This form has several accessibility issues.

The text is low contrast, which is hard for low-vision users to read.
Having labels on the left and fields on the right makes it hard for many people to associate them, and almost impossible for someone who needs to zoom in to use the page; imagine looking at this on a phone and having to pan around to figure out what goes with what.
The "Remember details?" label isn't associated with the checkbox, so you have to tap or click only on the tiny square rather than just clicking the label; also, someone using a screen reader would have trouble figuring out the association.

Now let's wave our accessibility wand and see the form with those issues fixed. We're going to make the text darker, modify the design so that the labels are close to the things they're labeling, and fix the label to be associated with the checkbox so you can toggle it by clicking the label as well.

Which would you rather use? If you said "the accessible version", you're on your way to understanding a main premise of this guide. Often, something that's a complete blocker for a few users is also a pain point for many others, so by fixing the accessibility issue you improve the experience for everyone.

Web Content Accessibility Guidelines #

Throughout this guide we'll refer to the Web Content Accessibility Guidelines (WCAG) 2.0, a set of guidelines and best practices put together by accessibility experts to address what "accessibility" means in a methodical way.

WCAG is organized around four principles often called by the acronym POUR:

Perceivable: Can users perceive the content? This helps us keep in mind that just because something is perceivable with one sense, such as sight, that doesn't mean that all users can perceive it.
Operable: Can users use UI components and navigate the content? For example, something that requires a hover interaction cannot be operated by someone who can't use a mouse or touch screen.
Understandable: Can users understand the content? Can users understand the interface and is it consistent enough to avoid confusion?
Robust: Can the content be consumed by a wide variety of user agents (browsers)? Does it work with assistive technology?

While WCAG provides a comprehensive overview of what it means for content to be accessible, it can also be a bit overwhelming. To help mitigate this, the WebAIM(Web Accessibility in Mind) group has distilled the WCAG guidelines into an easy-to-follow checklist, targeted specifically for web content.

The WebAIM checklist can give you a short, high-level summary of what you need to implement, while also linking to the underlying WCAG specification if you need an expanded definition.

With this tool in hand, you can chart a direction for your accessibility work and be confident that, as long as your project meets the outlined criteria, your users should have a positive experience accessing your content.

Understanding users' diversity #

When learning about accessibility, it helps to have an understanding of the diverse range of users in the world and the kinds of accessibility topics that affect them. To explain further, here's an informative question/answer session with Victor Tsaran, a Technical Program Manager at Google, who is totally blind.

Victor Tsaran

What do you work on at Google?

Here at Google my job is to help ensure that our products work for all of our diverse users, regardless of impairment or ability.

What kinds of impairments do users have?

When we think about the kinds of impairments which would make it difficult for someone to access our content, many people will immediately picture a blind user like me. And it's true, this impairment can really make it frustrating or even impossible to use a lot of web sites.

A lot of modern web techniques have the unfortunate side effect of creating sites which don't work well with the tools used by blind users to access the web. However, there is actually more to accessibility than that. We find it useful think of impairments falling into four broad buckets: visual, motor, hearing, and cognitive.

Let's go through those one at a time. Can you give some examples of visual impairments?

Visual impairments can be split into a few categories: Users with no vision, like me, might use a screen reader, braille, or combination of the two.

A braille reader

Now, it's actually pretty unusual to have literally no vision, but still, there's a good chance you know or have met at least one person who can't see at all. However there are also a much larger number of what we call low-vision users.

This is a broad range, from someone like my wife, who doesn't have any corneas - so while she can basically see things she has a hard time reading print and is considered legally blind - to someone who might have just poor vision and needs to wear very strong prescription glasses.

There's a huge range, and so naturally there's a big range of accommodations that people in this category use: some do use a screen reader or a braille display (I've even heard of one woman who reads braille displayed on-screen because it's easier to see than printed text), or they might use text-to-speech technology without the full screen reader functionality, or they might use a screen magnifier which zooms in on part of the screen, or they might just use their browser zoom to make all the fonts bigger. They might also use high-contrast options like an operating system high-contrast mode, a high-contrast browser extension or a high-contrast theme for a website.

High-contrast mode

A lot of users even use a combination of these, like my friend Laura who uses a combination of high-contrast mode, browser zoom and text-to-speech.

Low vision is something a lot of people can relate to. For a start, we all experience deteriorating vision as we age, so even if you haven't experienced it there's a good chance you've heard your parents complain about it. But a lot of people experience the frustration of taking their laptop out by a sunny window only to find they suddenly can't read anything! Or anyone who's had laser surgery or maybe just has to read something from across the room might have used one of those accommodations I mentioned. So I think it's pretty easy for developers to have some empathy for low-vision users.

Oh, and I shouldn't forget to mention people with poor color vision - about 9% of males have some form of color vision deficiency! Plus about 1% of females. They may have trouble distinguishing red and green, or yellow and blue. Think about that the next time you design form validation.

What about motor impairments?

Yes, motor impairments, or dexterity impairments. This group ranges all the way from those who would prefer not to use a mouse, because perhaps they've had some RSI or something and find it painful, to someone who may be physically paralyzed and have limited range of motion for certain parts of their body.

An eye tracking device

Motor impaired users may use a keyboard, switch device, voice control, or even an eye-tracking device to interact with their computer.

Similar to vision impairments, mobility can also be a temporary or situational issue: Maybe you have a broken wrist on your mouse hand. Maybe the trackpad is broken on your laptop, or you're just riding on a shaky train. There can be a lot of situations where a user's mobility is impeded, and by making sure we cater for them we improve the experience overall, both for anyone with a permanent impairment but also for anyone who temporarily finds that they can't use a pointer-based UI.

Great, let's talk about hearing impairments.

This group can range from the profoundly deaf through to hard-of-hearing. And much like eyesight, our hearing tends to degrade with age. Many of us use common affordances like hearing aids to help us.

Screen captions

For hearing-impaired users we need to make sure that we're not relying on sound, so making sure to use things like video captions and transcripts, and providing some kind of alternative, if sound is part of the interface.

And like we saw with vision and motor impairments, it's really easy to imagine a situation where someone whose ears work fine would benefit from these accommodations as well. A lot of my friends say they love it when videos have captions and transcripts because it means that if they're in an open plan office and didn't bring their headphones, they can still watch the video!

All right, can you tell us a bit about cognitive impairments?

There's a range of cognitive conditions like ADD, Dyslexia, and Autism, which can mean that people want or need to access things differently. The accommodations for these groups are naturally extremely diverse, but we definitely find some overlap with other areas, like using zoom functionality to make reading or concentrating easier. Also, these users may find that really minimal design works best because it minimizes distraction and cognitive load.

I think everyone can relate to the stress of cognitive overload, so it's obvious that if we create something that works well for someone with a cognitive impairment, we're going to be creating something which is going to be a pleasant experience for everyone.

So, how would you summarize how you think about accessibility?

When you look at the broad range of abilities and disabilities that people might have, you can see that designing and building products only for people who have perfect vision, hearing, dexterity, and cognition seems incredibly narrow. It's almost self-defeating, because we're creating a more stressful and less usable experience for everyone, and for some users creating an experience which actually excludes them altogether.

In this interview, Victor identified a range of impairments, and placed them into four broad categories: visual, motor, hearing, and cognitive. He also pointed out that each type of impairment might be situational, temporary, or permanent.

Let's take a look at some real-world examples of access impairments and see where they fall within those categories and types. Note that some impairments may fall into more than one category or type.

	Situational	Temporary	Permanent
Visual		concussion	blindness
Motor	holding a baby	broken arm, RSI*	RSI*
Hearing	noisy office
Cognitive		concussion

Repetitive Strain Injury: e.g., carpal tunnel syndrome, tennis elbow, trigger finger

Next steps #

We've covered quite a bit of ground already! You have read about

what accessibility is and why it matters for everyone
the WCAG and the WebAIM accessibility checklist
different types of impairments you should consider

For the rest of the guide, we'll dive into the practical aspects of creating accessible web sites. We'll organize this effort around three main subject areas:

Focus: We'll look at how to build things that can be operated with a keyboard instead of a mouse. This is important for users with motor impairments, of course, but it also ensures that your UI is in good shape for all users.
Semantics: We'll make sure that we express our user interface in a robust way that works with a variety of assistive technologies.
Styling: We'll consider visual design and look at some techniques for making the visual elements of the interface as flexible and usable as possible.

Each of those subjects could fill a whole course, so we won't cover every aspect of creating accessible web sites. However, we'll give you enough information to get started, and point you to some good places where you can learn more about each topic.

Rob Dodson on web.dev

Accessible tap targets

Testing your touch targets #

Using media queries to detect touchscreen use #

Accessible responsive design

Use the viewport meta tag #

Allow users to zoom #

Design with flexibility #

Use relative units for text #

Avoid disconnecting the visual view from the source order #

Take care with spatial clues #

Ensure tap targets are large enough on touchscreen devices #

Color and contrast accessibility

Advanced Perceptual Contrast Algorithm (APCA) #

Don't convey information with color alone #

High contrast mode #

An example blog post used for screenshot testing.

Image, Inline #

Ordered list #

Unordered list #

Widget #

Test of Aside nested in an ordered list #

Control focus with tabindex

Check if your controls are keyboard accessible #

Insert an element into the tab order #

Remove an element from the tab order #

Avoid tabindex > 0 #

Create accessible components with "roving tabindex" #

Keyboard access recipes #

Headings and landmarks

Use headings to outline the page #

Don't skip heading levels #

Use landmarks to aid navigation #

Bypass repetitive content with skip links #

Keyboard access fundamentals

Focus and the tab order #

Arrange elements in the DOM to be in logical order #

Correctly set the visibility of offscreen content #

Next steps #

Labels and text alternatives

Inspect an element's name #

Check for missing names #

Label documents and frames #

Include text alternatives for images and objects #

Images as links and inputs #

Embedded objects #

Label buttons and links #

Buttons #

Links #

Label form elements #

Semantics and screen readers

Affordances and semantics #

Use semantic HTML #

Semantic properties and the accessibility tree #

The accessibility tree #

Next steps #

Style focus

Use :focus to always show a focus indicator #

Use :focus-visible to selectively show a focus indicator #

Use :focus-within to style the parent of a focused element #

When to display a focus indicator #

Avoid outline: none #

Use semantic HTML for easy keyboard wins

Keyboard support for free (and better mobile experiences) #

Use button instead of div #

Links versus buttons #

Styling #

Next steps #

What is accessibility?

Understanding the diverse needs of your users #

Vision #

Motor/dexterity #

Auditory #

Cognitive #

Next steps #

Replace GIFs with video

Measure first #

Get FFmpeg #

Open the console #

Change GIF to video #

Avoid `tabindex > 0` #

Create accessible components with "roving `tabindex`" #

Use `:focus` to always show a focus indicator #

Use `:focus-visible` to selectively show a focus indicator #

Use `:focus-within` to style the parent of a focused element #

Avoid `outline: none` #

Use `button` instead of `div` #

`aria-hidden` does not prevent keyboard focus #