Meggin Kearney on web.dev

Save Credentials from Forms

2022-02-24T00:00:00Z

Save Credentials from sign-in forms

Keep your registration and sign-in forms as simple as possible.

Save credentials from sign-in forms so users won't have to sign in again when they return.

To store user credentials from forms:

Include autocomplete in the form.
Prevent the form from submitting.
Authenticate by sending a request.
Store the credential.
Update the UI or proceed to the personalized page.

Include `autocomplete` in the form #

Before moving forward, check if your form includes autocomplete attributes. This helps the Credential Management API find the id and password from the form and construct a credential object.

This also helps browsers not supporting the Credential Management API to understand its semantics. Learn more about autofill in this article by Jason Grigsby.

<form id="signup" method="post">
  <input name="email" type="text" autocomplete="username email" />
  <input name="display-name" type="text" autocomplete="name" />
  <input name="password" type="password" autocomplete="new-password" />
  <input type="submit" value="Sign Up!" />
</form>

Prevent the form from submitting #

When the user presses the submit button, prevent the form from submitting, which would otherwise result in a page transition:

    var f = document.querySelector('#signup');
    f.addEventListener('submit', e => {
      e.preventDefault();

By preventing a page transition, you can retain the credential information while verifying its authenticity.

Authenticate by sending a request #

To authenticate the user, deliver credential information to your server using AJAX.

On the server side, create an endpoint (or simply alter an existing endpoint) that responds with HTTP code 200 or 401, so that it’s clear to the browser whether the sign-up/sign-in/change password is successful or not.

For example:

// Try sign-in with AJAX
fetch('/signin', {
  method: 'POST',
  body: new FormData(e.target),
  credentials: 'include',
});

Store the credential #

To store a credential, first check if the API is available, then instantiate a PasswordCredential with the form element as an argument either synchronously or asynchronously. Call navigator.credentials.store(). If the API is not available, you can simply forward the profile information to the next step.

Synchronous example:

if (window.PasswordCredential) {
  var c = new PasswordCredential(e.target);
  return navigator.credentials.store(c);
} else {
  return Promise.resolve(profile);
}

Asynchronous example:

if (window.PasswordCredential) {
  var c = await navigator.credentials.create({password: e.target});
  return navigator.credentials.store(c);
} else {
  return Promise.resolve(profile);
}

Once the request succeeds, store the credential information. (Don't store the credentials information if the request failed as doing so confuses returning users.)

When the Chrome browser obtains credential information, a notification pops up asking to store a credential (or federation provider).

Notification for an auto signed-in user

Update the UI #

If everything went well, update the UI using the profile information, or proceed to the personalized page.

     }).then(profile => {
       if (profile) {
         updateUI(profile);
       }
     }).catch(error => {
       showError('Sign-in Failed');
     });
    });

Full code example #

// Get form's DOM object
var f = document.querySelector('#signup');
f.addEventListener('submit', (e) => {
  // Stop submitting form by itself
  e.preventDefault();

  // Try sign-in with AJAX
  fetch('/signin', {
    method: 'POST',
    body: new FormData(e.target),
    credentials: 'include',
  })
    .then((res) => {
      if (res.status == 200) {
        return Promise.resolve();
      } else {
        return Promise.reject('Sign-in failed');
      }
    })
    .then((profile) => {
      // Instantiate PasswordCredential with the form
      if (window.PasswordCredential) {
        var c = new PasswordCredential(e.target);
        return navigator.credentials.store(c);
      } else {
        return Promise.resolve(profile);
      }
    })
    .then((profile) => {
      // Successful sign-in
      if (profile) {
        updateUI(profile);
      }
    })
    .catch((error) => {
      // Sign-in failed
      showError('Sign-in Failed');
    });
});

Browser compatibility #

`PasswordCredential` #

Browser support

Chrome 51, Supported 51
Firefox, Not supported
Edge 79, Supported 79
Safari, Not supported

Source

`navigator.credentials.store()` #

Browser support

Chrome 51, Supported 51
Firefox 60, Supported 60
Edge 79, Supported 79
Safari 13, Supported 13

Source

Feedback #

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.

Sign in Users

2016-11-08T00:00:00Z

To sign in users, retrieve the credentials from the browser's password manager and use those to automatically log in users. For users with multiple accounts, let them select the account with just one tap using the account chooser.

Auto sign-in can happen anywhere on your website; not only the top page but other leaf pages too. This is useful when users reach various pages in your website, via a search engine.

To enable auto sign-in:

Get credential information.
Authenticate the user.
Update the UI or proceed to the personalized page.

Get credential information #

Browser support

Chrome 51, Supported 51
Firefox 60, Supported 60
Edge 18, Supported 18
Safari 13, Supported 13

Source

To get credential information, invoke navigator.credentials.get(). Specify the type of credentials to request by giving it a password or federated.

Always use mediation: 'silent' for auto sign-ins, so you can easily dismiss the process if the user:

Has no credentials stored.
Has multiple credentials stored.
Is signed out.

Before getting a credential, don’t forget to check if the user is already signed in:

if (window.PasswordCredential || window.FederatedCredential) {
  if (!user.isSignedIn()) {
    navigator.credentials.get({
      password: true,
      federated: {
        providers: ['https://accounts.google.com'],
      },
      mediation: 'silent',
    });
    // ...
  }
}

The promise returned by navigator.credentials.get() resolves with either a credential object or null. To determine whether it is a PasswordCredential or a FederatedCredential, simply look at the .type property of the object, which will be either password or federated.

If the .type is federated, the .provider property is a string that represents the identity provider.

Authenticate user #

Once you have the credential, run an authentication flow depending on the type of credential, password or federated:

    }).then(c => {
     if (c) {
       switch (c.type) {
         case 'password':
           return sendRequest(c);
           break;
         case 'federated':
           return gSignIn(c);
           break;
       }
     } else {
       return Promise.resolve();
     }

When the promise resolves, check if you've received a credential object. If not, it means auto sign-in couldn’t happen. Silently dismiss the auto sign-in process.

Update UI #

If the authentication is successful, update the UI or forward the user to the personalized page:

    }).then(profile => {
     if (profile) {
       updateUI(profile);
     }

Don’t forget to show authentication error message #

To avoid user confusion, users should see a blue toast saying “Signing in” at the time of getting the credential object:

One important tip: if you succeed in obtaining a credential object but fail to authenticate the user, you should show an error message:

        }).catch(error => {
          showError('Sign-in Failed');
        });
      }
    }

Full code example #

if (window.PasswordCredential || window.FederatedCredential) {
  if (!user.isSignedIn()) {
    navigator.credentials
      .get({
        password: true,
        federated: {
          providers: ['https://accounts.google.com'],
        },
        mediation: 'silent',
      })
      .then((c) => {
        if (c) {
          switch (c.type) {
            case 'password':
              return sendRequest(c);
              break;
            case 'federated':
              return gSignIn(c);
              break;
          }
        } else {
          return Promise.resolve();
        }
      })
      .then((profile) => {
        if (profile) {
          updateUI(profile);
        }
      })
      .catch((error) => {
        showError('Sign-in Failed');
      });
  }
}

If a user requires mediation, or has multiple accounts, use the account chooser to let the user sign-in, skipping the ordinary sign-in form, for example:

The steps to sign in via the account chooser are the same as in auto sign-in, with an additional call to show the account chooser as part of getting credential information:

Get the credential information and show the account chooser.
Authenticate the user.
Update the UI or proceed to a personalized page.

Get credential information and show account chooser #

Show an account chooser in response to a defined user action, for example, when the user taps the "Sign-In" button. Call navigator.credentials.get(), and add mediation: 'optional' or mediation: 'required' to show the account chooser.

When mediation is required, the user is always shown an account chooser to sign in. This option allows users with multiple accounts to easily switch between them. When mediation is optional, the user is explicitly shown an account chooser to sign in after a navigator.credentials.preventSilentAccess() call. This is normally to ensure automatic sign-in doesn't happen after the user chooses to sign-out or unregister.

Example showing mediation: 'optional':

    var signin = document.querySelector('#signin');
    signin.addEventListener('click', e => {
     if (window.PasswordCredential || window.FederatedCredential) {
       navigator.credentials.get({
         password: true,
         federated: {
           providers: [
             'https://accounts.google.com'
           ]
         },
         mediation: 'optional'
       }).then(c => {

Once the user selects an account, the promise resolves with the credential. If the users cancels the account chooser, or there are no credentials stored, the promise resolves with null. In that case, fall back to the sign in form experience.

You should fall back to a sign-in form for any of these reasons:

No credentials are stored.
The user dismissed the account chooser without selecting an account.
The API is not available.

    }).then(profile => {
        if (profile) {
          updateUI(profile);
        } else {
          location.href = '/signin';
        }
    }).catch(error => {
        location.href = '/signin';
    });

Full code example #

var signin = document.querySelector('#signin');
signin.addEventListener('click', (e) => {
  if (window.PasswordCredential || window.FederatedCredential) {
    navigator.credentials
      .get({
        password: true,
        federated: {
          providers: ['https://accounts.google.com'],
        },
        mediation: 'optional',
      })
      .then((c) => {
        if (c) {
          switch (c.type) {
            case 'password':
              return sendRequest(c);
              break;
            case 'federated':
              return gSignIn(c);
              break;
          }
        } else {
          return Promise.resolve();
        }
      })
      .then((profile) => {
        if (profile) {
          updateUI(profile);
        } else {
          location.href = '/signin';
        }
      })
      .catch((error) => {
        location.href = '/signin';
      });
  }
});

Federated login lets users sign in with one tap and without having to remember additional login details for your website.

To implement federated login:

Authenticate the user with a third-party identity.
Store the identity information.
Update the UI or proceed to a personalized page (same as in auto sign-in).

Authenticate user with third-party identity #

When a user taps on a federated login button, run the specific identity provider authentication flow with the FederatedCredential.

Browser support

Chrome 51, Supported 51
Firefox, Not supported
Edge 79, Supported 79
Safari, Not supported

Source

For example, if the provider is Google, use the Google Sign-In JavaScript library:

navigator.credentials
  .get({
    password: true,
    mediation: 'optional',
    federated: {
      providers: ['https://account.google.com'],
    },
  })
  .then(function (cred) {
    if (cred) {
      // Instantiate an auth object
      var auth2 = gapi.auth2.getAuthInstance();

      // Is this user already signed in?
      if (auth2.isSignedIn.get()) {
        var googleUser = auth2.currentUser.get();

        // Same user as in the credential object?
        if (googleUser.getBasicProfile().getEmail() === cred.id) {
          // Continue with the signed-in user.
          return Promise.resolve(googleUser);
        }
      }

      // Otherwise, run a new authentication flow.
      return auth2.signIn({
        login_hint: id || '',
      });
    }
  });

Google Sign-In results in an ID token as a proof of authentication.

In general, federated logins are built on top of standard protocols such as OpenID Connect or OAuth. To learn how to authenticate with federated accounts, refer to respective federated identity providers' docs. Popular examples include:

Store identity information #

Once authentication is done, you can store the identity information. The information you’ll store here is the id from the identity provider and a provider string that represents the identity provider (name and iconURL are optional). Learn more about this information in the Credential Management specification.

To store federated account details, instantiate a new FederatedCredential object with the user's identifier and the provider's identifier. Then invoke navigator.credentials.store() to store the identity information.

After successful federation, instantiate a FederatedCredential synchronously, or asynchronously:

Example of synchronous approach:

// Create credential object synchronously.
var cred = new FederatedCredential({
  id: id, // id in IdP
  provider: 'https://account.google.com', // A string representing IdP
  name: name, // name in IdP
  iconURL: iconUrl, // Profile image url
});

Example of asynchronous approach:

// Create credential object asynchronously.
var cred = await navigator.credentials.create({
  federated: {
    id: id,
    provider: 'https://accounts.google.com',
    name: name,
    iconURL: iconUrl,
  },
});

Then store the credential object:

// Store it
navigator.credentials.store(cred).then(function () {
  // continuation
});

Sign out #

Sign out your users when the sign-out button is tapped. First terminate the session, then turn off auto sign-in for future visits. (How you terminate your sessions is totally up to you.)

Call navigator.credentials.preventSilentAccess():

signoutUser();
if (navigator.credentials && navigator.credentials.preventSilentAccess) {
  navigator.credentials.preventSilentAccess();
}

This will ensure the auto sign-in won’t happen until next time the user enables auto sign-in. To resume auto sign-in, a user can choose to intentionally sign in by choosing the account they wish to sign in with from the account chooser. Then the user is always signed back in until they explicitly sign out.

Feedback #

The Credential Management API

2016-11-08T00:00:00Z

The Credential Management API is a standards-based browser API that provides a programmatic interface between the site and the browser for seamless sign-in across devices.

The Credential Management API:

Removes friction from sign-in flows - Users can be automatically signed back into a site even if their session has expired or they saved credentials on another device.
Allows one tap sign in with account chooser - Users can choose an account in a native account chooser.
Stores credentials - Your application can store either a username and password combination or even federated account details. These credentials can be synced across devices by the browser.

Want to see it in action? Try the Credential Management API Demo and take a look at the code.

Check Credential Management API browser support #

Browser support

Chrome 51, Supported 51
Firefox 60, Supported 60
Edge 18, Supported 18
Safari 13, Supported 13

Source

Before using the Credential Management API, first check if PasswordCredential or FederatedCredential is supported.

if (window.PasswordCredential || window.FederatedCredential) {
  // Call navigator.credentials.get() to retrieve stored
  // PasswordCredentials or FederatedCredentials.
}

To sign in the user, retrieve the credentials from the browser's password manager and use them to log in the user.

For example:

When a user lands on your site and they are not signed in, call navigator.credentials.get().
Use the retrieved credentials to sign in the user.
Update the UI to indicate the user has been signed in.

Learn more in Sign In Users.

Save or update user credentials #

If the user signed in with a federated identity provider such as Google Sign-In, Facebook, GitHub:

After the user successfully signs in or creates an account, create the FederatedCredential with the user's email address as the ID and specify the identity provider with FederatedCredentials.provider.
Save the credential object using navigator.credentials.store().

Learn more in Sign In Users.

If the user signed in with a username and password:

After the user successfully signs in or creates an account, create the PasswordCredential with the user ID and the password.
Save the credential object using navigator.credentials.store().

Learn more in Save Credentials from Forms.

Sign out #

When the user signs out, call navigator.credentials.preventSilentAccess() to prevent the user from being automatically signed back in.

Disabling auto-sign-in also enables users to switch between accounts easily, for example, between work and personal accounts, or between accounts on shared devices, without having to re-enter their sign-in information.

Learn more in Sign out.

Feedback #

Introduction to ARIA

2016-10-04T00:00:00Z

So far, we've encouraged using native HTML elements because they give you focus, keyboard support, and built-in semantics, but there are times when a simple layout and native HTML won't do the job. For example, currently there's no standardized HTML element for a very common UI construct, the pop-up menu. Nor is there an HTML element that provides a semantic characteristic such as "the user needs to know about this as soon as possible".

In this lesson, then, we'll explore how to express semantics that HTML can't express on its own.

The Web Accessibility Initiative's Accessible Rich Internet Applications specification (WAI-ARIA, or just ARIA) is good for bridging areas with accessibility issues that can't be managed with native HTML. It works by allowing you to specify attributes that modify the way an element is translated into the accessibility tree. Let's look at an example.

In the following snippet, we use a list item as a kind of custom checkbox. The CSS "checkbox" class gives the element the required visual characteristics.

<li tabindex="0" class="checkbox" checked>
    Receive promotional offers
</li>

While this works fine for sighted users, a screen reader will give no indication that the element is meant to be a checkbox, so low-vision users may miss the element entirely.

Using ARIA attributes, however, we can give the element the missing information so the screen reader can properly interpret it. Here, we've added the role and aria-checked attributes to explicitly identify the element as a checkbox and to specify that it is checked by default. The list item will now be added to the accessibility tree and a screen reader will correctly report it as a checkbox.

<li tabindex="0" class="checkbox" role="checkbox" checked aria-checked="true">
    Receive promotional offers
</li>

ARIA works by changing and augmenting the standard DOM accessibility tree.

Although ARIA allows us to subtly (or even radically) modify the accessibility tree for any element on the page, that is the only thing it changes. ARIA doesn't augment any of the element's inherent behavior; it won't make the element focusable or give it keyboard event listeners. That is still part of our development task.

It's important to understand that there is no need to redefine default semantics. Regardless of its use, a standard HTML <input type="checkbox"> element doesn't need an additional role="checkbox" ARIA attribute to be correctly announced.

It's also worth noting that certain HTML elements have restrictions on what ARIA roles and attributes can be used on them. For example, a standard <input type="text"> element may not have any additional role/attribute applied to it.

See the ARIA in HTML spec for more information.

Let's see what other capabilities ARIA has to offer.

What can ARIA do? #

As you saw with the checkbox example, ARIA can modify existing element semantics or add semantics to elements where no native semantics exist. It can also express semantic patterns that don't exist at all in HTML, like a menu or a tab panel. Often, ARIA lets us create widget-type elements that wouldn't be possible with plain HTML.

For example, ARIA can add extra label and description text that is only exposed to assistive technology APIs.

<button aria-label="screen reader only label"></button>

ARIA can express semantic relationships between elements that extend the standard parent/child connection, such as a custom scrollbar that controls a specific region.

    <div role="scrollbar" aria-controls="main"></div>
    <div id="main">
    . . .
    </div>

And ARIA can make parts of the page "live," so they immediately inform assistive technology when they change.

    <div aria-live="polite">
      <span>GOOG: $400</span>
    </div>

One of the core aspects of the ARIA system is its collection of roles. A role in accessibility terms amounts to a shorthand indicator for a particular UI pattern. ARIA provides a vocabulary of patterns we can use via the role attribute on any HTML element.

When we applied role="checkbox" in the previous example, we were telling assistive technology that the element should follow the "checkbox" pattern. That is, we're guaranteeing that it will have a checked state (either checked or not checked), and that the state may be toggled using the mouse or the spacebar, just like a standard HTML checkbox element.

In fact, because keyboard interactions feature so prominently in screen reader usage, it's very important to make sure that, when creating a custom widget, the role attribute is always applied in the same place as the tabindex attribute; this ensures that keyboard events go to the right place and that when focus lands on an element its role is conveyed accurately.

The ARIA spec describes a taxonomy of possible values for the role attribute and associated ARIA attributes that may be used in conjunction with those roles. This is the best source of definitive information about how the ARIA roles and attributes work together and how they can be used in a way that is supported by browsers and assistive technologies.

However, the spec is very dense; a more approachable place to start is the ARIA Authoring Practices document , which explores best practices for using the available ARIA roles and properties.

ARIA also offers landmark roles that extend the options available in HTML5. See the Landmark Roles Design Patterns spec for more information.

Hiding and updating content

2016-10-04T00:00:00Z

aria-hidden #

Another important technique in fine-tuning the experience for assistive technology users involves ensuring that only relevant parts of the page are exposed to assistive technology. There are several ways to ensure that a section of the DOM does not get exposed to accessibility APIs.

First, anything that is explicitly hidden from the DOM will also not be included in the accessibility tree. So anything that has a CSS style of visibility: hidden or display: none or uses the HTML5 hidden attribute will also be hidden from assistive technology users.

However, an element that is not visually rendered but not explicitly hidden is still included in the accessibility tree. One common technique is to include "screen reader only text" in an element that is absolute positioned offscreen.

.sr-only {
    position: absolute;
    left: -10000px;
    width: 1px;
    height: 1px;
    overflow: hidden;
}

Also, as we have seen, it's possible to provide screen reader only text via an aria-label, aria-labelledby, or aria-describedby attribute referencing an element that is otherwise hidden.

See this WebAIM article on Techniques for hiding text for more information on creating "screen reader only" text.

Finally, ARIA provides a mechanism for excluding content from assistive technology that is not visually hidden, using the aria-hidden attribute. Applying this attribute to an element effectively removes it and all of its descendants from the accessibility tree. The only exceptions are elements referred to by an aria-labelledby or aria-describedby attribute.

<div class="deck">
    <div class="slide" aria-hidden="true">
    Sales Targets
    </div>
    <div class="slide">
    Quarterly Sales
    </div>
    <div class="slide" aria-hidden="true">
    Action Items
    </div>
</div>

For example, you might use aria-hidden if you're creating some modal UI that blocks access to the main page. In this case, a sighted user might see some kind of semi-transparent overlay indicating that most of the page can't currently be used, but a screen reader user may still be able to explore to the other parts of the page. In this case, as well as creating the keyboard trap explained earlier, you need to make sure that the parts of the page that are currently out of scope are aria-hidden as well.

Now that you understand the basics of ARIA, how it plays with native HTML semantics, and how it can be used to perform fairly major surgery on the accessibility tree as well as changing the semantics of a single element, let's look at how we can use it to convey time-sensitive information.

aria-live #

aria-live lets developers mark a part of the page as "live" in the sense that updates should be communicated to users immediately regardless of the page position, rather than if they just happen to explore that part of the page. When an element has an aria-live attribute, the part of the page containing it and its descendants is called a live region.

For example, a live region might be a status message that appears as a result of a user action. If the message is important enough to grab a sighted user's attention, it is important enough to direct an assistive technology user's attention to it by setting its aria-live attribute. Compare this plain div

<div class="status">Your message has been sent.</div>

with its "live" counterpart.

<div class="status" aria-live="polite">Your message has been sent.</div>

aria-live has three allowable values: polite, assertive, and off.

aria-live="polite" tells assistive technology to alert the user to this change when it has finished whatever it is currently doing. It's great to use if something is important but not urgent, and accounts for the majority of aria-live use.
aria-live="assertive" tells assistive technology to interrupt whatever it's doing and alert the user to this change immediately. This is only for important and urgent updates, such as a status message like "There has been a server error and your changes are not saved; please refresh the page", or updates to an input field as a direct result of a user action, such as buttons on a stepper widget.
aria-live="off" tells assistive technology to temporarily suspend aria-live interruptions.

There are some tricks to making sure your live regions work correctly.

First, your aria-live region should probably be set in the initial page load. This is not a hard-and-fast rule, but if you're having difficulty with an aria-live region, this might be the issue.

Second, different screen readers react differently to different types of changes. For example, it's possible to trigger an alert on some screen readers by toggling a descendant element's hidden style from true to false.

Other attributes that work with aria-live help you fine-tune what is communicated to the user when the live region changes.

aria-atomic indicates whether the entire region should be considered as a whole when communicating updates. For example, if a date widget consisting of a day, month, and year has aria-live=true and aria-atomic=true, and the user uses a stepper control to change the value of just the month, the full contents of the date widget would be read out again. aria-atomic's value may be true or false (the default).

aria-relevant indicates what types of changes should be presented to the user. There are some options that may be used separately or as a token list.

additions, meaning that any element being added to the live region is significant. For example, appending a span to an existing log of status messages would mean that the span would be announced to the user (assuming that aria-atomic was false).
text, meaning that text content being added to any descendant node is relevant. For example, modifying a custom text field's textContent property would read the modified text to the user.
removals, meaning that the removal of any text or descendant nodes should be conveyed to the user.
all, meaning that all changes are relevant. However, the default value for aria-relevant is additions text, meaning that if you don't specify aria-relevant it will update the user for any addition to the element, which is what you are most likely to want.

Finally, aria-busy lets you notify assistive technology that it should temporarily ignore changes to an element, such as when things are loading. Once everything is in place, aria-busy should be set to false to normalize the reader's operation.

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.

Semantics and navigating content

2016-10-04T00:00:00Z

You've learned about affordances, semantics, and how assistive technologies use the accessibility tree to create an alternative user experience for their users. You can see that writing expressive, semantic HTML gives you a lot of accessibility with very little effort, as many standard elements have both the semantics and supporting behavior built in.

In this lesson we'll cover some less obvious semantics that are very important to screen reader users, especially as regards navigation. In a simple page with lots of controls but not much content, it's easy to scan the page to find what you need. But on a content-heavy page, such as a Wikipedia entry or a news aggregator, it's not practical to read through everything from the top down; you need a way to efficiently navigate through the content.

Developers often have the misconception that screen readers are tedious and slow to use, or that everything on the screen has to be focusable for the screen reader to find it. That's often not the case.

Screen reader users often rely on a list of headings to locate information. Most screen readers have easy ways to isolate and scan a list of page headings, an important feature called the rotor. Let's see how we can use HTML headings effectively to support this feature.

Using headings effectively #

First, let's reiterate an earlier point: DOM order matters, not only for focus order but for screen reader order. As you experiment with screen readers like VoiceOver, NVDA, JAWS, and ChromeVox, you'll find the heading list follows the DOM order rather than the visual order.

This is true for screen readers in general. Because screen readers interact with the accessibility tree, and the accessibility tree is based on the DOM tree, the order a screen reader perceives is thus directly based on the DOM order. This means that an appropriate heading structure is more important than ever.

In most well-structured pages, the heading levels are nested to indicate parent-child relationships among content blocks. The WebAIM checklist repeatedly refers to this technique.

1.3.1 mentions "Semantic markup is used to designate headings"
2.4.1 mentions heading structure as a technique for bypassing blocks of content
2.4.6 discusses some details for writing useful headings
2.4.10 states "individual sections of content are designated using headings, where appropriate"

Not all headings have to be visible on-screen. Wikipedia, for instance, uses a technique that deliberately places some headings off-screen to specifically make them accessible only to screen readers and other assistive technology.

<style>
    .sr-only {
    position:absolute;
    left:-10000px;
    top:auto;
    width:1px;
    height:1px;
    overflow:hidden;
    }
</style>

<h2 class="sr-only">This heading is offscreen.</h2>

For complex applications, this can be a good way to accommodate headings when the visual design doesn't require or have room for a visible heading.

Caution: It's important not to go overboard with this technique. Remember that assistive technology users may also be able to see the screen for themselves, so going too far down the path of creating "screen reader only" content may actually degrade the user experience for some users. It can also create a maintenance headache for you later.

Although pages with good headings help screen reader users navigate, there are other elements they can use to move around a page, including links, form controls, and landmarks.

Readers can use the screen reader's rotor feature (an easy way to isolate and scan a list of page headings) to access a list of links on the page. Sometimes, as on a wiki, there are many links, so the reader might search for a term within the links. This limits the hits to links that actually contain the term, rather than every occurrence of the term on the page.

This feature is useful only if the screen reader can find the links and the link text is meaningful. For example, here are some common patterns that make links hard to find.

Anchor tags without href attributes. Often used in single-page applications, these link targets cause problems for screen readers. You can read more in this article on single-page apps.
Buttons that are implemented with links. These cause the screen reader to interpret the content as a link, and the button functionality is lost. For these cases, replace the anchor tag with a real button and style it appropriately.
Images used as link content. Sometimes necessary, linked images can be unusable to screen readers. To guarantee that the link is properly exposed to assistive technology, make sure the image has alt attribute text.

Poor link text is another problem. Clickable text such as "learn more" or "click here" provides no semantic information about where the link goes. Instead, use descriptive text like "learn more about responsive design" or "see this canvas tutorial" to help screen readers provide meaningful context about links.

The rotor can also retrieve a form control list. Using this list, readers can search for specific items and go directly to them.

A common error that screen readers make is pronunciation. For example, a screen reader might pronounce "Udacity" as "oo-dacity", or read a phone number as a large integer, or read capitalized text as though it were an acronym. Interestingly, screen reader users are quite used to this quirk and take it into consideration.

Some developers try to ameliorate this situation by providing screen-reader-only text that is spelled phonetically. Here's a simple rule for phonetic spelling: don't do it; it only makes the problem worse! If, for example, a user is using a braille display, the word will be spelled incorrectly, leading to more confusion. Screen readers allow words to be spelled aloud, so leave it to the reader to control their experience and decide when this is necessary.

Readers can use the rotor to see a landmarks list. This list helps readers find the main content and a set of navigational landmarks provided by HTML landmark elements.

HTML5 introduced some new elements that help define the semantic structure of the page, including header, footer, nav, article, section, main, and aside. These elements specifically provide structural clues in the page without forcing any built-in styling (which you should do with CSS anyway).

Semantic structural elements replace multiple, repetitive div blocks, and provide a clearer, more descriptive way to intuitively express page structure for both authors and readers.

The Accessibility Tree

2016-10-04T00:00:00Z

Imagine that you're building a user interface for screen reader users only. Here, you don't need to create any visual UI at all, but just provide enough information for the screen reader to use.

What you'd be creating is a kind of API describing the page structure, similar to the DOM API, but you can get away with less information and fewer nodes, because a lot of that information is only useful for visual presentation. It might look something like this.

This is basically what the browser actually presents to the screen reader. The browser takes the DOM tree and modifies it into a form that is useful to assistive technology. We refer to this modified tree as the Accessibility Tree.

You might visualize the accessibility tree as looking a bit like an old web page from the '90s: a few images, lots of links, perhaps a field and a button.

Visually scanning down a page like this case gives you an experience similar to what a screen reader user would get. The interface is there, but it is simple and direct, much like an accessibility tree interface.

The accessibility tree is what most assistive technologies interact with. The flow goes something like this.

An application (the browser or other app) exposes a semantic version of its UI to assistive technology via an API.
The assistive technology may use the information it reads via the API to create an alternative user interface presentation for the user. For example, a screen reader creates an interface in which the user hears a spoken representation of the app.
The assistive technology may also allow the user to interact with the app in a different way. For example, most screen readers provide hooks to allow a user to easily simulate a mouse click or finger tap.
The assistive technology relays the user intent (such as "click") back to the app via the accessibility API. The app then has the responsibility to interpret the action appropriately in the context of the original UI.

For web browsers, there's an extra step in each direction, because the browser is in fact a platform for web apps that run inside it. So the browser needs to translate the web app into an accessibility tree, and must make sure that the appropriate events get fired in JavaScript based on the user actions that come in from the assistive technology.

But that is all the browser's responsibility. Our job as web developers is just to be aware that this is going on, and to develop web pages that take advantage of this process to create an accessible experience for our users.

We do this by ensuring that we express the semantics of our pages correctly: making sure that the important elements in the page have the correct accessible roles, states, and properties, and that we specify accessible names and descriptions. The browser can then let the assistive technology access that information to create a customized experience.

Semantics in native HTML #

A browser can transform the DOM tree into an accessibility tree because much of the DOM has implicit semantic meaning. That is, the DOM uses native HTML elements that are recognized by browsers and work predictably on a variety of platforms. Accessibility for native HTML elements such as links or buttons is thus handled automatically. We can take advantage of that built-in accessibility by writing HTML that expresses the semantics of our page elements.

However, sometimes we use elements that look like native elements but aren't. For example, this "button" isn't a button at all.

Give me tacos

It might be constructed in HTML in any number of ways; one way is shown below.

<div class="button-ish">Give me tacos</div>

When we don't use an actual button element, the screen reader has no way to know what it has landed on. Also, we would have to do the extra work of adding tabindex to make it usable to keyboard-only users because, as it is coded now, it can only be used with a mouse.

We can easily fix this by using a regular button element instead of a div. Using a native element also has the benefit of taking care of keyboard interactions for us. And remember that you don't have to lose your spiffy visual effects just because you use a native element; you can style native elements to make them look the way you want and still retain the implicit semantics and behavior.

Earlier we noted that screen readers will announce an element's role, name, state, and value. By using the right semantic element, role, state, and value are covered, but we must also ensure that we make an element's name discoverable.

Broadly, there are two types of names:

Visible labels, which are used by all users to associate meaning with an element, and
Text alternatives, which are only used when there is no need for a visual label.

For text-level elements, we don't need to do anything, because by definition it will have some text content. However, for input or control elements, and visual content like images, we need to make sure that we specify a name. In fact, providing text alternatives for any non-text content is the very first item on the WebAIM checklist.

One way to do that is to follow their recommendation that "Form inputs have associated text labels." 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 a label element

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

Receive promotional offers?

Use the label's for attribute and refer to the element's id

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

Receive promotional offers?

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?".

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.

ARIA labels and relationships

2016-10-04T00:00:00Z

Labels #

ARIA provides several mechanisms for adding labels and descriptions to elements. In fact, ARIA is the only way to add accessible help or description text. Let's look at the properties ARIA uses to create accessible labels.

aria-label #

aria-label allows us to specify a string to be used as the accessible label. This overrides any other native labeling mechanism, such as a label element — for example, if a button has both text content and an aria-label, only the aria-label value will be used.

You might use an aria-label attribute when you have some kind of visual indication of an element's purpose, such as a button that uses a graphic instead of text, but still need to clarify that purpose for anyone who cannot access the visual indication, such as a button that uses only an image to indicate its purpose.

aria-labelledby #

aria-labelledby allows us to specify the ID of another element in the DOM as an element's label.

This is much like using a label element, with some key differences.

aria-labelledby may be used on any element, not just labelable elements.
While a label element refers to the thing it labels, the relationship is reversed in the case of aria-labelledby — the thing being labeled refers to the thing that labels it.
Only one label element may be associated with a labelable element, but aria-labelledby can take a list of IDREFs to compose a label from multiple elements. The label will be concatenated in the order that the IDREFs are given.
You can use aria-labelledby to refer to elements that are hidden and would otherwise not be in the accessibility tree. For example, you could add a hidden span next to an element you want to label, and refer to that with aria-labelledby.
However, since ARIA only affects the accessibility tree, aria-labelledby does not give you the familiar label-clicking behavior you get from using a label element.

Importantly, aria-labelledby overrides all other name sources for an element. So, for example, if an element has both an aria-labelledby and an aria-label, or an aria-labelledby and a native HTML label, the aria-labelledby label always takes precedence.

Relationships #

aria-labelledby is an example of a relationship attribute. A relationship attribute creates a semantic relationship between elements on the page regardless of their DOM relationship. In the case of aria-labelledby, that relationship is "this element is labelled by that element".

The ARIA specification lists eight relationship attributes. Six of these, aria-activedescendant, aria-controls, aria-describedby, aria-labelledby, and aria-owns, take a reference to one or more elements to create a new link between elements on the page. The difference in each case is what that link means and how it is presented to users.

aria-owns #

aria-owns is one of the most widely used ARIA relationships. This attribute allows us to tell assistive technology that an element that is separate in the DOM should be treated as a child of the current element, or to rearrange existing child elements into a different order. For example, if a pop-up sub-menu is visually positioned near its parent menu, but cannot be a DOM child of its parent because it would affect the visual presentation, you can use aria-owns to present the sub-menu as a child of the parent menu to a screen reader.

aria-activedescendant #

aria-activedescendant plays a related role. Just as the active element of a page is the one that has focus, setting the active descendant of an element allows us to tell assistive technology that an element should be presented to the user as the focused element when its parent actually has the focus. For example, in a listbox, you might want to leave page focus on the listbox container, but keep its aria-activedescendant attribute updated to the currently selected list item. This makes the currently selected item appear to assistive technology as if it is the focused item.

aria-describedby #

aria-describedby provides an accessible description in the same way that aria-labelledby provides a label. Like aria-labelledby, aria-describedby may reference elements that are otherwise not visible, whether hidden from the DOM, or hidden from assistive technology users. This is a useful technique when there is some extra explanatory text that a user might need, whether it applies only to users of assistive technology or all users.

A common example is a password input field that is accompanied by some descriptive text explaining the minimum password requirements. Unlike a label, this description may or may not ever be presented to the user; they may have a choice of whether to access it, or it may come after all the other information, or it may be pre-empted by something else. For example, if the user is entering information, their input will be echoed back and may interrupt the element's description. Thus, a description is a great way to communicate supplementary, but not essential, information; it won't get in the way of more critical information such as the element's role.

aria-posinset & aria-setsize #

The remaining relationship attributes are a little different, and work together. aria-posinset ("position in set") and aria-setsize ("size of set") are about defining a relationship between sibling elements in a set, such as a list.

When the size of a set cannot be determined by the elements present in the DOM — such as when lazy rendering is used to avoid having all of a large list in the DOM at once — aria-setsize can specify the actual set size, and aria-posinset can specify the element's position in the set. For example, in a set that might contain 1000 elements, you could say that a particular element has an aria-posinset of 857 even though it appears first in the DOM, and then use dynamic HTML techniques to ensure that the user can explore the full list on demand.

Introduction to semantics

2016-10-04T00:00:00Z

You've seen how to make a site accessible to users who can't use a mouse or pointing device — whether due to physical impairment, a technology issue, or personal preference — by addressing keyboard-only use. While it requires some care and thought, it's not a huge amount of work if you plan it from the beginning. Once that basic work is done, you're a long way down the path to a fully accessible and more polished site.

In this lesson, we'll build on that work and get you thinking about other accessibility factors, such as how to build websites to support users like Victor Tsaran, who can't see the screen.

First, we'll get some background on assistive technology, the general term for tools like screen readers that help users with impairments that can keep them from accessing information.

Next, we'll look at some general user experience concepts, and build on those to take a deeper dive into the experience of users of assistive technology.

Finally, we'll see how to use HTML effectively to create a good experience for these users, and how it overlaps quite a bit with the way we addressed focus earlier.

Assistive technology #

Assistive technology is an umbrella term for devices, software, and tools that help any person with a disability complete a task. In the broadest sense this could be something low-tech like a crutch for walking or a magnifying glass for reading, or something high-tech like a robotic arm or image recognition software on a smartphone.

Assistive technology can include something as general as browser zoom, or as specific as a custom-designed game controller. It can be a separate physical device like a braille display, or be implemented completely in software like voice control. It can be built-in to the operating system like some screen readers, or it can be an add-on like a Chrome extension.

The line between assistive technology and technology in general is blurry; after all, all technology is meant to assist people with some task or another. And technologies can often move into and out of the "assistive" category.

For example, one of the earliest commercial speech synthesis products was a talking calculator for the blind. Now speech synthesis is all over the place, from driving directions to virtual assistants. Conversely, technology that was originally general-purpose often finds an assistive use. For example, people with low vision may use their smartphone's camera zoom to get a better look at something small in the real world.

In the context of web development, we must consider a diverse range of technologies. People may interact with your website using a screen reader or braille display, with a screen magnifier, via voice control, using a switch device, or with some other form of assistive technology that adapts the page's default interface to create a more specific interface that they can use.

Many of these assistive technologies rely on programmatically expressed semantics to create an accessible user experience, and that's what most of this lesson is about. But before we can explain programmatically expressed semantics, we need to talk a bit about affordances.

Affordances #

When we use a man-made tool or device, we typically look to its form and design to give us an idea of what it does and how it works. An affordance is any object that offers, or affords, its user the opportunity to perform an action. The better the affordance is designed, the more obvious or intuitive its use.

A classic example is a kettle or teapot. You can easily recognize that you should pick it up by the handle, not the spout, even if you've never seen a teapot before.

That's because the affordance is similar to those you have seen on many other objects -- watering pots, beverage pitchers, coffee mugs, and so on. You probably could pick up the pot by the spout, but your experience with similar affordances tells you the handle is the better option.

In graphical user interfaces, affordances represent actions we can take, but they can be ambiguous because there is no physical object to interact with. GUI affordances are thus specifically designed to be unambiguous: buttons, check boxes, and scroll bars are meant to convey their usage with as little training as possible.

For example, you might paraphrase the use of some common form elements (affordances) like this:

Radio buttons — "I can choose one of these options."
Check box — "I can choose 'yes' or 'no' to this option."
Text field — "I can type something into this area."
Dropdown — "I can open this element to display my options."

You are able to draw conclusions about these elements only because you can see them. Naturally, someone who can't see the visual clues provided by an element can't comprehend its meaning or intuitively grasp the value of the affordance. So we must make sure that the information is expressed flexibly enough to be accessed by assistive technology that can construct an alternative interface to suit its user's needs.

This non-visual exposure of an affordance's use is called its semantics.

Screen readers #

One popular type of assistive technology is the screen reader, a program that enables visually impaired people to use computers by reading screen text aloud in a generated voice. The user can control what is read by moving the cursor to a relevant area with the keyboard.

We asked Victor Tsaran to explain how, as a blind person, he accesses the web using a the built-in screen reader on OS X, called VoiceOver. See this video of Victor using VoiceOver.

Now, it's your turn to try using a screen reader. Here is a page with ChromeVox Lite, a minimal but functioning screen reader written in JavaScript. The screen is purposefully blurred to simulate a low-vision experience and force the user to complete the task with a screen reader. Of course, you'll need to use the Chrome browser for this exercise.

ChromeVox lite demo page

You can use the control panel at the bottom of the screen to control the screen reader. This screen reader has very minimal functionality, but you can explore the content using the Previous and Next buttons, and you can click things using the Click button.

Try using this page with ChromeVox lite enabled to get a feel for screen reader use. Think about the fact that a screen reader (or other assistive technology) actually creates a complete alternate user experience for the user based on the programmatically expressed semantics. Instead of a visual interface, the screen reader provides an audible interface.

Notice how the screen reader tells you some information about each interface element. You should expect a well-designed reader to tell you all, or at least most, of the following information about the elements it encounters.

The element's role or type, if it is specified (it should be).
The element's name, if it has one (it should).
The element's value, if it has one (it may or may not).
The element's state, e.g., whether it is enabled or disabled (if applicable).

The screen reader is able to construct this alternate UI because the native elements contain built-in accessibility metadata. Just as the rendering engine uses the native code to construct a visual interface, the screen reader uses the metadata in the DOM nodes to construct an accessible version, something like this.

Text Alternatives for Images

2016-10-04T00:00:00Z

Images are an important component of most web pages, and are of course a particular sticking point for low-vision users. We must consider the role an image plays in a page to work out what type of text alternative it should have. Take a look at this image.

<article>
    <h2>Study shows 9 out of 10 cats quietly judging their owners as they sleep</h2>
    <img src="imgs/160204193356-01-cat-500.jpg">
</article>

Study shows 9 out of 10 cats quietly judging their owners as they sleep #

In the page we have a picture of a cat, illustrating an article on cats' well-known judgmental behavior. A screen reader will announce this image using its literal name, "/160204193356-01-cat-500.jpg". That's accurate, but not at all useful.

You can use the alt attribute to provide a useful text alternative to this image — for example, "A cat staring menacingly off into space."

<img src="/160204193356-01-cat-500.jpg" alt="A cat staring menacingly off into space">

Then the screen reader can announce a succinct description of the image ( seen in the black VoiceOver bar) and the user can choose whether to move on to the article.

A couple of comments about alt:

alt allows you to specify a simple string to be used any time the image isn't available, such as when the image fails to load, or is accessed by web crawling bot, or is encountered by a screen reader.
alt differs from title, or any type of caption, in that it is only used if the image is not available.

Writing useful alt text is a bit of an art. In order for a string to be a usable text alternative, it needs to convey the same concept as the image, in the same context.

Consider a linked logo image in the masthead of a page like those shown above. We can describe the image pretty accurately as "The Funion logo".

<img class="logo" src="logo.jpg" alt="The Funion logo">

It might be tempting to give it a simpler text alternative of "home" or "main page", but that does a disservice to both low-vision and sighted users.

But imagine a screen reader user who wants to locate the masthead logo on the page; giving it an alt value of "home" actually creates a more confusing experience. And a sighted user faces the same challenge — figuring out what clicking the site logo does — as a screen reader user.

On the other hand, it's not always useful to describe an image. For example, consider a magnifying glass image inside a search button that has the text "Search". If the text wasn't there, you would definitely give that image an alt value of "search". But because we have the visible text, the screen reader will pick up and read aloud the word "search"; thus, an identical alt value on the image is redundant.

However, we know that if we leave the alt text out, we'll probably hear the image file name instead, which is both useless and potentially confusing. In this case you can just use an empty alt attribute, and the screen reader will skip the image altogether.

<img src="magnifying-glass.jpg" alt="">

To summarize, all images should have an alt attribute, but they need not all have text. Important images should have descriptive alt text that succinctly describes what the image is, while decorative images should have empty alt attributes — that is, alt="".

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.

Meggin Kearney on web.dev

Save Credentials from Forms

Include autocomplete in the form #

Prevent the form from submitting #

Authenticate by sending a request #

Store the credential #

Update the UI #

Full code example #

Browser compatibility #

PasswordCredential #

navigator.credentials.store() #

Feedback #

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 #

Sign in Users

Auto Sign-in #

Get credential information #

Authenticate user #

Update UI #

Don’t forget to show authentication error message #

Full code example #

Sign-in via account chooser #

Get credential information and show account chooser #

Don't forget to fall back to sign-in form #

Full code example #

Federated Login #

Authenticate user with third-party identity #

Store identity information #

Sign out #

Turn off auto sign-in for future visits #

Feedback #

The Credential Management API

Check Credential Management API browser support #

Sign in user #

Save or update user credentials #

Sign out #

Feedback #

Introduction to ARIA

What can ARIA do? #

Hiding and updating content

aria-hidden #

aria-live #

DOM Order Matters

Offscreen content #

Introduction to Focus

What is focus? #

What is focusable? #

Experiencing focus #

Semantics and navigating content

Using headings effectively #

Other navigation options #

The Accessibility Tree

Semantics in native HTML #

Using tabindex

Managing focus at the page level #

Managing focus in components #

Modals and keyboard traps #

ARIA labels and relationships

Labels #

aria-label #

aria-labelledby #

Relationships #

aria-owns #

aria-activedescendant #

aria-describedby #

aria-posinset & aria-setsize #

Introduction to semantics

Include `autocomplete` in the form #

`PasswordCredential` #

`navigator.credentials.store()` #