14Four Wiki

# 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. 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. Note that impairment can be temporary, situational, or permanent, and affects everyone at some point or time, resulting in keeping accessibility in mind beneficial to everyone.

Accessibility should be considered from the wireframe and design process, all the way through the development phase and then on a regular basis as content updates are made and new features are added to a project. While retrofitting an existing site to meet accessibility requirements is possible, it’s much easier to include from the beginning.

# Resources

# ADA

Americans with Disabilities Act (ADA) was signed into law in July 1990, five years after the first domain name was registered. This legislation “prohibits discrimination and guarantees that people with disabilities have the same opportunities as everyone else to participate in the mainstream of American life”. What the ADA does not do is give us a checklist of things that we need to do to make sure a website is ‘accessible’. The best we have to work with so far is WCAG, however meeting WCAG standards does not shield from potential lawsuits.

# WCAG

WCAG (Web Content Accessibility Guidelines) is the most recognised web accessibility standard in the world. The guidelines are divided up into three levels of conformance: A, AA, and AAA.

  • WCAG Level A: This level represents the bare-minimum of compliance.
  • WCAG Level AA: This level is the target compliance level that the majority of organizations aim for.
  • WCAG Level AAA: Any organization that has achieved this level of compliance is exceeding requirements. It is the highest level achievable, meaning it complies with the success criteria of all three levels.

All additional level requires the implementation of the previous level (AA needs to meet A and AA, AAA needs to meet A, AA, and AAA). The majority of our projects will aim to hit AA compliance. For more detail, see the WCAG Checklist (opens new window)

# Resources

# POUR

POUR is an acronym for four high-level principles that describe functional accessibility. Accessible technology is Perceivable, Operable, Understandable, and Robust. In addition to websites, most other information technology can be made accessible by applying the POUR principles. Many of the technology challenges faced by people with disabilities can be described using one of the POUR principles.

# 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?

# Resources

# General Impairment Categories

Generally speaking, accessibility is creating something that is accessible to anyone. Specifically, it concerns those who are experiencing some type of impairment or disability. However, accessibility is beneficial to everyone. There are generally four categories for impairments. Visible, motor, hearing, and cognition. Impairment can be temporary, situational, or permanent, and affects everyone at some point or time, resulting in keeping accessibility in mind beneficial to everyone.

# Visual

Can be split into a few categories. No vision, low-vision, and poor color vision.

Accomodations: Screen readers, braille display, screen magnifier, text-to-speech, high-contrast mode.

# Motor

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.

Accomodations: A keyboard, switch device, voice control, an eye-tracking device

# Hearing

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.

Accomodations: Video captions and transcripts

# Cognition

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.

Accomodations: Zoom functionality, minimalist design

# Multi-lingual Accessibility

A multi-lingual website is a website where the content is written in more than one language. The information displayed in different languages is often the same, but maybe tailored for different audiences. Booking.com (opens new window) is an example of a multi-lingual website as its content is available in 35 different languages.

# Resources

# ARIA Labels

WIA-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) is a spec from the World Wide Web Consortium (W3C) that was created to improve accessibility of web pages and applications by providing extra information to screen readers via HTML attributes.

ARIA helps provide screen reader users with better context to the content on the page.

ARIA has attributes, which are divided into three categories. Roles, States, and Properties.

# Roles

Roles describe widgets that aren't otherwise available in HTML 4, such as sliders, menu bars, tabs, and dialogs.

# Properties

Properties describe characteristics of these widgets, such as if they are draggable, have a required element, or have a popup associated with them.

# States

**States **describe the current interaction state of an element, informing the assistive technology if it is busy, disabled, selected, or hidden.

# Resources

# Tools for Accessibility Check

For the most part, running your site through the IBM tool should be good enough for client approval. However, to ensure accessibility, it doesn't hurt to use at least two different tools as there could be some violations being thrown in one and not another.

# IBM (opens new window)

IBM.image1

IBM.image2

# Pros

  • Extension is built right into dev tools.
  • Option to download, sort and store the current scan report.
  • Gives you practical steps in the learn more tab on why violations are important to fix, and how to do so.
  • Ability to filter between violations, elements that need reviewed, and recommendations.
  • Follows Level AA WCAG 2.1 requirements

# Cons

  • There were some violations that were being thrown on other tools that were not showing up on this tool. Something minor, but worth noting.
  • No visual queue of where the warning is coming from on the page.
  • No option to check color contrast, just throws an error that it does not meet minimum requirements.

# ANDI (opens new window)

ANDI.image1

ANDI.image2

# Pros

  • Provides the ability to discover the presence of hidden content that should be tested for accessibility.
  • Ability to test the content in iframes.
  • Reveals what a screen reader should say for interactive elements (the accessible name computation.)
  • Sections out errors and violations into categories
  • Displays the calculated contrast ratio, the Pass/Fail status, the minimum required contrast ratio (Min Req), and a suggested new color. Also has a color contrast playground, and a grayscale option.
  • Follows Level AA WCAG 2.1 requirements

# Cons

  • Not a browser extension, it is a bookmarked tab.
  • Does not pull up code in dev tools to reference where errors are. This could be annoying.

# WAVE (opens new window)

wave.image1

# Pros

  • Shows visual tags of where errors and alerts are.
  • Follows Level AA WCAG 2.1 requirements
  • Gives reference to errors and why they need to be corrected
  • Pulls up code for reference.
  • Color contrast checker

# Cons

  • With absolute elements, visual tags get stuck, this can be annoying.
  • Tags on site can get confusing and get in the way.
  • Is not built into dev tools.

# How to Implement and Verify Accessibility

# Steps

  1. Follow all rules in the checklist(s) that are applicable to Level AA or Below, and WCAG 2.1. Confirm that the site follows all rules applicable.
  2. Use the IBM Tool (opens new window) to confirm that the site throws no major errors or warnings (potentially follow up with another tool: Wave (opens new window) or ANDI (opens new window)).
  3. If your site is multi-lingual, double check that all content is readable, in the correct orientation, and all alt text, metadata, and ARIA labels are reflected in the correct language.
    • Can the default human language of each Web page be programmatically determined?
    • Does the site have a primary language set?
    • Does the site change the language direction for applicable languages?
    • Does the site declare character encoding?
    • Does font size dynamically change depending on the readability of the language?
    • Does the design of the website cater for different length words used throughout the site?

# Accessibility CheckList

← Password Policies →