Accessibility

Accessibility is about making your application usable by as many people as possible, regardless of their abilities.

While we often think about disabilities when we talk about accessibility, it’s really about making your application available for all of your users.

Accessibility scenarios

Here are some scenarios where accessibility applies…

Why is accessibility important?

Accessibility focuses on users as people, not just customers.

Accessibility helps us maximize usability. We are not our users. It’s easy to assume that others will approach our application with the same knowledge, experience, mindset, and abilities that we have, but that often isn’t the case. There are over 1 billion people with some degree of disability, about 15-20% of the population. By meeting our users where they are, regardless of ability, we demonstrate our commitment to customer and user experience.

Accessibility can extend our market reach.

Web accessibility litigation has been increasing, something we obviously want to avoid.

And simply put, it’s the right thing to do, both as product developers and as humans.

Assistive technology

Users primarily interact with your Responsive UI web application using the browser (sometimes referred to as the “user agent”), a keyboard and mouse in desktop environments, and a touchscreen in mobile environments and some desktop environments.

In addition to the browser and traditional input devices, some users may use assistive technologies to interact with your application, extending the browser’s built-in capabilities.

These assistive technologies include:

• Screen readers: Software that reads aloud a verbal representation of your application. Screen readers allow users with limited vision to use their ears to understand your application rather than their eyes.
• Screen magnifiers: Software that enlarges a small portion of the screen at a time, which can be useful for those with limited vision. Unlike the zoom capability built into the browser, where the layout of your entire application scales to reflect the current zoom level, a screen magnifier displays an enlarged view of only part of the screen, similar to how a magnifying glass works.
• Alternative input technologies: Users who have difficulties interacting with a traditional keyboard or mouse may require other technologies to provide input to and interact with your application. These include:
  • Speech input software: Software that allows the user to enter input or control the application using only their voice.
  • Head pointer: Either a physical pointing device mounted to the user’s head used to manually press keys on the keyboard, or camera-based software used to move the mouse. Both allow the user to control an application without requiring the use of their hands.
  • Sip and puff: Device that allows the user to control the application by “sipping” (inhaling), “puffing” (exhaling), and moving a tube with their mouth, an analog to traditional mouse functions.
  • Eye tracker: Device that allows the user to control the application using their eyes.

Measuring accessibility

If we only test our applications using traditional tools – browser, keyboard, mouse, and touchscreen – then we run the risk of preventing users of assistive technologies from using these apps.

The WC3 maintains the Web Content Accessibility Guidelines (WCAG), which are standards for web application accessibility.

WCAG outlines 3 levels of support:

• A - Basic support: This level is required for assistive technology like screen readers to be able to read, understand, or operate the application. This is the base level of compliance.
• AA - Ideal support: This level is required for government and public websites. This is the level most organizations work to support.
• AAA - specialized support: This level is typically reserved for specific sections of a web app that serve a specialized audience. Our goal for Responsive UI applications is to support at least level A, but preferably level AA.

What Responsive UI does to help ensure accessibility

Responsive UI uses multiple approaches to ensure accessibility internally within the development components.

Responsive UI components use semantic HTML elements wherever possible. Semantic elements are HTML elements that have a specific meaning. Screen readers understand how to announce semantic elements.

Responsive UI components use ARIA tags (accessible rich internet applications) where semantic HTML doesn’t apply. ARIA tags provide additional semantic information that help a screen reader to announce the element properly.

The Contrast theme ensures a AA rating for color contrast. The other themes are not guaranteed to provide this level of contrast across all of the themed colors.

Responsive UI turns off component animations for users that have a vestibular disorder (which can be triggered by animations or parallax) by honoring the prefers-reduced-motion CSS media feature.

Responsive UI hides all instances of icon components from screen readers by internally setting aria-hidden=“true”.

What your application needs to do to help ensure accessibility

As we saw above, Responsive UI helps ensure accessibility, so use Responsive UI components and theming for as many of the elements in your application as possible. This will get you most of the way towards accessibility in your application.

Test your application’s usability for users with limited vision by zooming the browser to between 100% and 200%. If your application is still usable at 200% — it doesn’t have to be ideal, just usable — then your application will satisfy the WCAG 2.1 criteria for resizing text.

All input tags must have a corresponding label tag. The for attribute for the label tag and the id for the input tag must match so the screen reader can pair the two for the user.

<label class="control-label" for="field-city">City:</label>
<input id="field-city" formControlName="city" type="text" class="rui-form-control" />

All anchor tags must specify value text.

<a href="...">This is the anchor tag value</a>

Every img tag must specify alternate text that describes the image, using the alt attribute. This alternate text is read by screen readers, helping users with limited vision understand what the image represents. The alternate text must be meaningful enough to describe the image to the user.

<img src="img_bird.jpg" alt="A small bird with brown feathers and an orange bill">

Icon-only button components (rui-button, rui-dropdown-button, rui-split-button, and rui-popup-button) automatically use the icon name as the text for screen readers. This works well if you’re using a simple icon such as “Edit” or “Delete”, but if the icon name doesn’t clearly describe the button’s purpose, you must set either the button’s title attribute or its aria-label attribute to a value that adequately describes the button’s purpose.

<!–– The icon name describes the button action well here, so we're good ––>
<rui-button iconType="edit"></rui-button>

<!–– The icon name does not describe the button action well here, so we specify an aria-label ––>
<rui-button iconType="view-list" aria-label="Display a list of customer accounts"></rui-button>

Icon-only toggle buttons must set either the button’s title property or its aria-label attribute to a value that adequately describes the button’s purpose.

<rui-toggle-button [(value)]="bold" title="Toggle bold">
    <rui-icon iconType="text-bold"></rui-icon>
</rui-toggle-button>

Toggles must set either the title or aria-label attribute to a value that adequately describes the toggle’s purpose.

<rui-toggle id="showPassword" aria-label="Toggle the display of the user's password"></rui-toggle>

Add the sr-only CSS class to label elements which you want read by screen readers but which won’t be visible on the page.

<label for="inputUser" class="sr-only">Username</label>

<input type="text" id="inputUser" name="inputUser" class="rui-form-control"
    placeholder="Username" required autofocus [(ngModel)]="userId"
    autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false">

You can learn more about accessible development at the W3C Resources for Developers page.