Web Accessibility for Developers

Essential Tools for Inclusive Coding

Slides & Demo Site: github.com/svinkle/web-accessibility-for-developers-workshop
Windows users: nvaccess.org/download

Agenda

The basics of accessibility
Understanding various disabilities
Semantic HTML
Testing with screen readers
Page structure
Keyboard accessibility
Image alt text
Forms
Links vs Buttons
Dynamic components

And much more!

Intros! 👋

Your name
Favorite Netflix show
What you hope to learn today

Design with an inclusive mindset; create products everyone can use.

What is accessibility?

Mindfulness is key

Poor connection speed — Performance
Handheld device — Responsive design
Person with disability — Accessibility

Consider this: When you’re driving a car, it’s crucial to pay attention to your surroundings. To be a successful driver, you must take into account other drivers, cyclists, road signs, and pedestrians. Without this consideration for others, you face the potential of getting into trouble quite quickly.

Along the same lines, as designers and developers, when you are mindful of people and the various ways they use and interact with your website you help ensure a positive user experience for all.

If you consider someone in a remote area of the world with a poor connection speed, you’ll make sure the site and all its assets will load quickly and perform optimally
If you consider someone doing research and learning about a topic using a handheld device, you’ll be sure to design a user interface that supports a wide range of device screen sizes and orientations
If you consider someone who is blind, hard of hearing, motor impairments, or who has difficulty understanding written text on a page, then you’ll code and structure content in a way that will help convey meaning and purpose for people who use and depend on assistive technology to experience the web.

What really happens is that as you start thinking of and developing for people with disabilities, you end up actually improving the usability of a site for all users.

Disabilities

Visual impairments
Deafness / hard of hearing
Motor disabilities
Vestibular issues / seizure disorders
Cognitive disabilities

Understanding Disabilities

Visual impairments

Low vision — difficulty seeing things clearly
Color blindness — cannot perceive the difference between color
Legally blind — only see light, vague shapes, or nothing at all

A visual impairment is anything that affects a person's ability to see clearly. In other words, if you don't have perfect 20/20 vision, you are considered to have a visual impairment.

Q: Does anyone here use any assistive technology to help with their vision? (Glasses are assistive tech!)

Some impairments can easily be corrected by simply wearing a pair of glasses or inserting contact lenses. Other impairments are more permanent, such as:

Low vision

Difficulty seeing things clearly, which is common among the elderly, or due to genetics, traumatic injuries, or illnesses
Color blindness

Which means some folks cannot perceive (see) the difference between certain color combinations
Legally blind

Which doesn't necessarily mean someone can't see at all, but rather can only see light or vague shapes of objects

Challenges and assistive technology

Challenges: People not being able to see the screen or have difficulty discerning color.
Assistive technology: Glasses, text zoom software, screen reader, braille reader.

Deafness / hard of hearing

Deaf — very little or no functional hearing
Hard of Hearing — mild-to-moderate hearing

Challenges and assistive technology

Challenges: People not being able to hear video or audio content.
Assistive technology: Hearing aid, captions/audio descriptions, transcripts.

Motor disabilities

A wheelchair user riding a pool at a skate park wearing a helmet.

Paraplegia or quadriplegia — paralysis of the limbs
Cerebral palsy — decreased muscle control
Parkinson's disease — uncontrollable tremors

Challenges and assistive technology

Challenges: Being accurate with interactions, using a mouse, interacting with small UI elements.
Assistive technology: Keyboard, voice dictation software, wand mouth stick, switch device

Vestibular issues / seizure disorders

Vestibular disorder — feelings of dizziness or Vertigo
Seizures — strobing, flickering, or flashing effects

Challenges and assistive technology

Challenges: Navigating a web with an increasing amount of animations, no warning of flashing content
Assistive technology: Using "reader mode" to remove animations, "Reduce motion" operating system feature

Cognitive disabilities

A young child looks off into the distance. A teacher stands at a blackboard behind them, looking for their attention.

Clinical diagnoses:

Autism
Down Syndrome
Dementia/Alzheimer's

Less severe:

Attention deficit disorder (ADD)
Dyslexia (difficulty reading)
Learning disabilities

Challenges and assistive technology

Challenges: Reading content, understanding design patterns, completing timed tasks, general focus
Assistive technology: Using "reader mode" to remove distractions, Kurzweil software

Temporary disabilities

A person's arm slung in a temporary cast.

A broken arm or finger
Reading text on your phone while outside
Loud, busy environment
Having Lasik eye surgery
Traveling to a new country
Holding a baby in one arm and your phone in the other!

So far we've discussed many disabilities which can considered permanent. However, there is such a thing as a temporary disability. Perhaps you know someone or you yourself have been in a situation where you have limited abilities for a short term.

Consider the following situations:

A broken arm or finger which limits your ability to only use one arm/hand
Trying to read text on your phone while outside in the sun—contrast!
A loud, busy area such as a bus terminal or train station might limit your cognitive thought process
Having Lasik eye surgery limits your vision for a period of time
Traveling to a new country and not understanding the local spoken language or street signs
Holding a baby in one arm while trying to look something up on your phone with the other!

The point here is that, temporary or permanent, designing with accessibility in mind really helps everyone in any type of situation.

Make accessibility considerations for all disabilities to provide an inclusive user experience.

The four principles of accessibility

W3C 👉 WAI 👉 WCAG

P.O.U.R.

Perceivable
Operable
Understandable
Robust

Perceivable

Interface components must be presentable to users in ways they can comprehend.

A line graph with various patterns to denote each data point.

Short text equivalents for images
Description of data represented on charts
Brief descriptions of non-text content
labels for controls and interface components

Perceivable — Information and user interface components must be presentable to users in ways they can perceive (become aware or conscious of something; come to realize or understand how something works.) Examples include:

Short text equivalents for images, including icons, buttons, and graphics;
Description of data represented on charts, diagrams, and illustrations;
Brief descriptions of non-text content such as audio and video files;
labels for form controls, input, and other user interface components.

In other words, content needs to be available to at least one of the user's four senses

For example, if you have a visual impairment, can you see the content by zooming in on the content, does it have enough color contrast to be readable? If you're blind, does your screen reader work well with the content provide?

If you're deaf, is there a text alternative for that piece of audio content?

We need to make sure people can be made aware of and understand the content presented to them.

Operable

User interface components and navigation must be operable or usable.

Functionality available by mouse is also available by keyboard
No keyboard traps
Web browsers and tooling provides keyboard support

Operable — User interface components and navigation must be operable or usable (the interface cannot require interaction that a user cannot perform). This means user interfaces require keyboard access to all functionality. Keyboard accessibility includes:

All functionality that is available by mouse is also available by keyboard;
Keyboard focus does not get trapped in any part of the content;
Web browsers, authoring tools, and other tools provide keyboard support.

In other words, people need to be able to operate the web site. Not everyone uses or is capable of using a mouse so they may only use a keyboard or perhaps voice recognition software to announce commands.

Understandable

Information and the operation of user interface must be understandable or easily comprehensible.

Identify the primary language of a page
Providing definitions for uncommon words
Use clear and simple language

Understandable — Information and the operation of user interface must be understandable or easily comprehensible. Content authors need to ensure that text content is readable and understandable to the broadest audience possible, including when it is read aloud by text-to-speech software. Such content includes:

Identifying the primary language of a web page, such as Arabic, Dutch, or Korean;
Providing definitions for any unusual or uncommon words, phrases, idioms, and abbreviations;
Using the clearest and simplest language possible, or providing simplified versions.

So making sure interfaces and content is clear, consistent, and predictable is key for making sure someone is able to understand and use your service.

Robust

Content must be created in a way which can be interpreted reliably by a wide variety of user agents.

A table with various mobile phones and tablets.

Markup can be reliably interpreted
Provide a name, role, and value

Robust — Content must be robust and created in a way which can be interpreted reliably by a wide variety of user agents, including assistive technologies. In other words. robust content is compatible with different browsers, assistive technologies and devices, kiosks, phones, toasters, any networked device. Examples of how this can be achieved include:

Ensuring markup can be reliably interpreted, for instance by ensuring it is valid;
Providing a name, role, and value for non-standard user interface components.

So, for example, can a older, mobile browser reliably output the same content as seen on a modern desktop browser? Does the content work well with a screen reader or braille reader?

WCAG Success Criteria

Level A: Provides a baseline to meet basic usability needs of most people
Level AA: Includes usability which meets the needs of most people with disabilities
Level AAA: Success criteria to meet the needs of all people and beyond

Each of the four principles is made up of several success criteria. These criteria make up the conformance tests you need to be conducting in order to create an accessible user experience.

There are three levels of conformance, each increasing in the level of difficulty in order to meet the required success criteria tests. The breakdown of each level is as follows:

Level A: Provides a baseline to meet basic usability needs of most people
Level AA: Includes usability which meets the needs of most people with disabilities
Level AAA: Success criteria to meet the needs of all people and beyond

The typical level to strive for in order to meet the needs of people with disabilities and to conform with most regional laws is WCAG 2.0 Level AA. This level provides a balance of usability, functionality, and aesthetic design that’s achievable by designers and developers the world over.

If any of these principles are not met, users with disabilities will not be able to use the web.

Keyboard

Focus indicator

For people with motor disabilities or any other impairment (temporary or permanent) which prevents use of the mouse, navigating with the keyboard is the next best option.

Additionally, those who consider themselves “power users” who prefer the keyboard over using the mouse, such as filling out long forms, will also greatly benefit.

When you use the Tab key on a site, the keyboard cursor will appear, typically a blue ring or black dotted line depending on the browser, and move from one HTML element to the next. Using Shift + Tab moves the keyboard cursor backward through the page. The elements highlighted are considered to be “naturally” focusable. Elements such as links, buttons, form inputs, etc all receive keyboard focus by default and should highlight when the cursor moves from one to the next.

If you can't see the cursor on the page, you've got an accessibility issue

2.4.7 Focus Visible

"Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible."

Custom focus indicator

            
              *:focus {
                outline: solid 3px red;
              }

Ensure high contrast ratio
Make it consistent

Detect keyboard/mouse usage

Focus order

2.4.3: Focus Order

"If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability."

Ensure the visual order of content matches the HTML order.

Focus management

Animated GIF of a modal window opening on a webpage.

Focus management is a method used to willfully and purposefully move the keyboard cursor from one element to another on behalf of the user. This technique should only be used when absolutely necessary as to not create more work for the user when an unexpected shift in focus has occurred.

An example of default focus management that we get from the browser for free is when we activate the Tab key in a form field, focus is automatically sent to the next field in the set. Or, when moving from link to link, focus moves from the top of the document to the bottom. When using native elements, the browser takes care of moving and managing focus position for us.

However, when it comes to creating a non-native control or widget, such as a modal window which we’ll look at in greater depth later, we need to manage the focus position on behalf of the user.

How we accomplish this is by use of the tabindex attribute.

The tabindex attribute

`tabindex="-1"`

Allows non-focusable elements to programmatically receive focus via JavaScript
Does not add the element to the natural focus order

`tabindex="0"`

Allows non-focusable elements to receive focus
Adds the element to the natural focus order

`tabindex="1"` or higher

Send focus to this element first, then focus returns to the next element
Considered an anti-pattern and should be avoided

Refrain from adding tabindex="0" everywhere!

When it comes to navigating non-focusable elements, such as plain text content, headings, or images, it’s important to note that assistive technology, such as screen readers (which will be discussed in more detail later), have built-in functionality to read and consume these types of content pieces.

After learning about using the Tab key to move around a UI and the tabindex attribute, you may be tempted to place tabindex=”0” on everything in order to ensure a screen reader user is able to Tab to these elements. Please refrain from doing so. This is considered an anti-pattern as this will cause more work for keyboard users to move around and consume the content they’re interest in.

With some exceptions, only elements to receive the tabindex=”0” attribute would be those with an action applied, such as a JavaScript click event handler. Leave all other elements out of the natural tab order, otherwise, keyboard-only users would have to hit the Tab key many times just to reach links at the bottom of a page, cause a very frustrating user experience.

Exercise!

Load up the HTML pages of our demo site in your browser.
Try navigating with just the Tab key.
Fix any issues by adjusting the demo-site/css/styles.css file.

Semantic HTML

Semantic HTML is the foundation of an accessible experience.

What is this thing and what does it do?

Semantics include…

Accessible name
Element role
Current state

The accessible name/label/text equivalent

Screen reader focus on a link. A speech bubble reads, 'Contact us'.

The accessible name is the part that describes what the element is for, its purpose for being.

This is usually found as the content between the start and end tags of an HTML element. It could also be the alternative text value for an image alt attribute, or the label associated with a form input.

Let’s take for instance, a link. This element has text between its start and end tag. This text gets read aloud by a screen reader when it receives keyboard focus. In doing so, this conveys context on what should happen or where the browser should go when that link is activated.

For example, a link in a navigation area with the accessible name of "Contact Us" would indicate that, if you activated that link, it would load a page with contact information, maybe a telephone number or address, and possibly a form where someone could send a message.

The element role

Screen reader focus on a link. A speech bubble reads, 'Contact us, link'.

The element’s role informs the user of a few things, including what the element does and how to interact with it.

Coming back to the link example, the role announced when the link receives keyboard focus would be "link," as links are structured with opening and closing a tags and include a valid href attribute. The expected result or, "what it does," would be for the browser to either load a new page or jump to another section of the same page, shifting focus to a different element. How to interact with the link would be for the user to press the Enter key, as this is also a part of the sematics of a link.

Various element roles come with expectations on how to use them. Depending on the role, a user might expect they would need to press the Enter key to continue (as is the case with a link), use the Space key to activate a button, or perhaps use the Up-arrow or Down-arrow keys to make a selection when interacting with a select element.

The current state

Screen reader focus on a checkbox. A speech bubble reads, 'Apples, unchecked, checkbox'.

1.3.1 Info and Relationships

"Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text."

Using semantic HTML is setting up your users for success.

Testing with screen readers

The piece of content which gets announced is the currently focused item.

Common screen reader commands

Starting up

Screen reader	Start up	Shut down
VoiceOver	`Cmd` + `F5` TouchBar: `Cmd` + `Pwr` (x3)	`Cmd` + `F5` TouchBar: `Cmd` + `Pwr` (x3)
NVDA	`Ctrl` + `Alt` + `N` Windows Run dialog: `nvda` Desktop shortcut	Windows Run dialog: `nvda -q` Taskbar menu

Pause announcements

Homer Simpson's finger pointing at the 'Ctrl' key.

Tabbing around

Tab to move forward
Shift + Tab to move backward

Screen reader virtual cursor

Screen reader	Keys
VoiceOver	`Ctrl` + `Opt` then `Left arrow` or `Right arrow`
NVDA	`Up arrow` or `Down arrow`

Screen reader + browser combinations

Operating system	Browser	Screen reader
Windows	Internet Explorer	JAWS
Windows	Firefox	NVDA
Windows	Firefox	JAWS
macOS	Safari	VoiceOver
iOS	Safari	VoiceOver
Android	Chrome	TalkBack

Here are the most common browser + screen reader combinations. These are the most commonly used as they have the best support regarding features and conveying information through native HTML and ARIA.

Operating system	Browser	Screen reader
Windows	Internet Explorer	JAWS
Windows	Firefox	NVDA
Windows	Firefox	JAWS
macOS	Safari	VoiceOver
iOS	Safari	VoiceOver
Android	Chrome	TalkBack

For more details, see the Screen Reader User Survey.

Exercise!

Load up the homepage of our demo site.
Set your system volume to low — just enough so you can hear it.
Start up your screen reader, then shut it off.
Start the screen reader, hit Ctrl to pause.
Try pressing Tab around — how do things sound?
Try your screen reader virtual cursor!

Page `title`

The page title is the first bit of information that is announced by a screen reader.

How to write `title` text

Homepage

                <title>outdoorsy</title>

Contact page

                <title>Contact | outdoorsy</title>

A blog post

                <title>Choose the Right Gear | outdoorsy</title>

What ends up in the title element actually depends on the current page or state of the site. Ideally the flow of information in the title would be, from left to right: state | page | site.

For example:

The homepage title would simply reflect the site name
<title>outdoorsy</title>
The title for a Contact page would be:
<title>Contact | outdoorsy</title>
A blog post would include the title of the post within the title element:
<title>How to Choose the Right Hiking Gear | outdoorsy</title>
Notice the hierarchy does not get included in the title. This is to avoid having screen readers announce too much information at once.

Updating the state

Form with invalid data

                <title>Error | Contact | outdoorsy</title>

Multi-step form

                <title>Payment information (Step 3 of 4) | Shop | outdoorsy</title>

Using the title element to convey the current state of a website is an extra bonus for someone using a screen reader. With this, they’ll receive the message right away and can avoid wading through page content to find the current state of things.

For example:

If someone submits a form with invalid data which results in a full-page refresh, having the title reflect this state would be helpful in quickly informing the user of the error state of the form.
<title>Error | Contact | outdoorsy</title>
If someone is filling out a multi-step form, perhaps making an online purchase, the title might reflect the current step of the process which they’re about to complete.
<title>Payment information (Step 3 of 4) | Shop | outdoorsy</title>

With clear and unique title element content, both sighted users and screen reader users will benefit in knowing exactly where they are within your site.

2.4.2 Page Titled

"Web pages have titles that describe topic or purpose."

Exercise!

Load up the HTML pages of our demo site in your editor and browser.
Set an appropriate page title.
Bonus! Try starting up a screen reader and refresh the page to hear the title content.

Page structure

People who depend on assistive technology often navigate by headings first.

Logical heading order is key

            
              <h1>Primary heading</h1>
              <!-- … -->

              <h2>Sub-section</h2>
              <!-- … -->

              <h3>Sub-sub-section</h3>
              <!-- … -->

              <h2>Sub-section</h2>
              <!-- … -->

For example, in your HTML you'd start with a single h1 heading as the primary title of the page, followed by an h2 heading for each major sub-section of content. If there were any sub-sub-sections, those would feature h3 headings. When a section of content is complete, the heading would return to the appropriate level to start the new section.

In addition to the HTML code behind the headings, the visual design of headings is also very important. Text sizes which go from large to medium to small denotes the content structure and related content. People with a cognitive impairment or reading/learning disability will greatly appreciate content being split into pieces with headings conveying the message that, "this is a new section of content." Without headings, large walls of content can be quite difficult for some people to consume and may even lead to a sense of overwhelm.

Examples

Landmark elements

Landmark	HTML `role`	Purpose
Header	`banner`	Typically the first landmark element in the DOM, containing the main logo, primary navigation, and sometimes a search form.
Footer	`contentinfo`	Typically the last element in the DOM, containing links and copyright information.
Aside	`complimentary`	Contains content relative to the article or the site in general.
Nav	`navigation`	Used to denote navigation areas.
Main	`main`	The main content area of the page, typically found as a sibling to the `header` and `footer`.
Section	—	A generic element used for sectioning off content such as portions of a page or article—not to be confused with the `div` which as no semantic meaning.

Landmarks are the HTML elements which define the overall structure of a complete page. A typical web page might include sections such as a top bar with a heading logo, main navigation, a sidebar with more navigation or additional related content, a footer section, and of course the main body content. As a result, what we now have with HTML5 are specific elements which feature the semantic meaning for each section.

At a high level, the landmark elements consist of:

Header, with a role of banner, is typically the first landmark element in the DOM, containing the main logo, primary navigation, and sometimes a search form.
Footer, with a role of contentinfo, is typically the last element in the DOM, containing links and copyright information.
Aside, with a role of complimentary, it contains content relative to the article or the site in general.
Nav, with a role of navigation, is used to denote navigation areas.
Main, with a role of main, is the main content area of the page, typically found as a sibling to the header and footer.
Section, the only landmark without an explicit role value, is a generic element used for sectioning off content such as portions of a page or article.

Just like with headings, people who use a screen reader are able to discover page content by navigating via landmark elements only. This allows people to quickly jump to different sections of the page without having to wade through content unrelated to their current task.

2.4.6 Headings and Labels

"Headings and labels describe topic or purpose."

Exercise!

Load up the HTML pages of our demo site in your editor and browser.
Adjust the markup to include Landmark elements such as header, main, footer, aside, etc.
Hint! The applied CSS classes help to decide where a Landmark might be placed.

Image alt text

Who benefits from alt text?

Image on a web page with text bubble, 'Creative writing objects on a table; pens, pencils, a sketch book, and a cup of coffee. Image'

Benefits of alt text include SEO, and sighted users when the image fails to load.

However, screen reader users benefit most; allows participation in consuming non-text content.

There are a few situations where writing alt text and including well formed descriptions for your imagery is beneficial for a successful website, including search engine optimization and sighted users who are able to read the content when and if an image fails to load.

However, it's actually people who use and rely on assistive technology who have the most to gain when interacting with non-text content on the web.

Alt text provides people with visual impairments the ability to participate in consuming non-text content.

When assistive technology, such as a screen reader, encounters an image on the web, the alt text is read and announced aloud. By doing so, someone who relies on this technology can still have a clear understanding of what the image represents and be included in the conversation.

Images missing the `alt` attribute

Invalid HTML markup
The src attribute value is announced by screen readers

When to include alt text

If the image contains text, the alt value should be an exact match
If the image doesn’t add any value, the alt attribute value should be left empty
If the image adds content or value, add descriptive alt text

You might be tempted to always include some sort of text within the alt attribute in order to cater for the cases outlined above. However, the fact remains that not every image should have a value set for its alt attribute.

How do we know when to include alt text for our images? Here are three common situations to consider if alt text should be added or if the alt attribute should be set as empty.

If the image itself contains text, such as a logo or an inspirational quote embedded within the image, the alt attribute value should be an exact match of the visible text.
If the image doesn’t add any valuable content to the article, or is adjacent to related text content, the alt attribute value should be left empty. This results in screen readers bypassing the image altogether as it is considered a "decorative" image.
If the image is considered to add content or value to the article, add descriptive alt text.

There are more examples and situations to consider. For a more comprehensive list, check out the tutorial, "An alt Decision Tree" linked in the notes.

How to write alt text

Be accurate and descriptive
Don't overwhelm with too much information

"A pair of low-top shoes are placed on top of a dark-brown table in front of a white brick wall. The shoes are mostly dark blue with a white midsole, brown laces, a black back tab, and white lining."

"Dark blue, low-top shoes with white midsole, brown lace, black back tab, and white lining."

1.1.1 Non-text Content

"All non-text content that is presented to the user has a text alternative that serves the equivalent purpose."

Exercise!

In your browser and editor, load: demo-site/blog-post.html.
Pick a photo and try writing some alt text describing the image.
Bonus! Use your screen reader virtual cursor to listen to your alt text.

Links vs Buttons

Link and button expectations

Element	Is announced as	Is activated by	Results in	Shifts focus?
a	"link"	`Enter`	Loading a new page, downloading a file, or jumping to a section on the same page.	Yes
button	"button"	`Enter` or `Space`	Submitting a form or executing an on-screen action (eg., sorting table columns.)	No

Control design

Control design and accessibility

An underlined link with the text, 'Link'. A button with the text, 'Button'.

Consistent control design allows people to identify and use with confidence
Voice dictation software accuracy
Color alone may not be enough to perceive the control

When it comes to accessibility best practices, the ideal design for each control would be something of a traditional look; colored text with an underline to denote a link and a solid background color with slightly rounded corners to denote a button.

Why is it so critical to usability and accessibility for these elements to appear in this manner? Here's a few reasons:

Having controls designed in a consistent manner allows people with a cognitive impairment to identify and use the control with confidence, that it will result in meeting their expectations.
When someone with a motor disability relies on voice dictation software and they announce, "click Submit button" when really the button is actually a link element, their command will not work.
When links are only distinguished by color alone, folks with color blindness or low-vision may not be able to perceive the link for a link and miss it completely.

With links designed like links and buttons designed like buttons, everyone will benefit from the clear indication of which is which and will be able to use the controls with confidence. The idea is to avoid activating something that they weren't expecting, causing them more work to undo the previous action.

In other words, make sure things are clear, consistent, and obvious.

Hover, focus, and active state

Hover state

An animated GIF highlighting mouse hover styles; from red to dark red.

            
              a:hover {
                color: FireBrick;
              }

Focus state

An animated GIF highlighting keyboard focus styles.

            
              a:hover, a:focus  {
                color: FireBrick;
              }

Active state

An animated GIF highlighting mouse activation styles; dark red to black.

            
              a:active {
                color: Black;
              }

Notes on the `href` attribute

The missing `href`

Don't do this:

            
              <a onclick="doSomething()">Do something</a>

Do this instead:

            
              <a href="#doSomething" onclick="doSomething()">Do something</a>

Including a unique `href` value

Screen reader with multiple speech bubbles of, 'link visited'.

Just like how links have a visual unvisited and visited state (by default, blue links which turn purple post activation), screen readers also announce the visited state.

Coming back to the web app example of using a link elements with a click event handler, it’s common to include the href attribute with the number or "hash tag" character (#). With the number character set as the href destination, focus would be brought back to the top of the document on click. However, with the custom JavaScript event attached, we don’t need to really worry about the destination, right?

The problem here is that since the link (or potentially many links on the same page) have the same href value, activating one will set all the others as "visited." For someone using a screen reader, hearing "link, visited" when they in fact hadn’t yet visited the link can be a confusing experience.

Including a unique `href` value

Screen reader with speech bubbles of, 'Apples, link', 'Oranges, link'.

2.4.4 Link Purpose

"The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context."

Skip links

The skip link

Animated GIF showcasing a 'Skip to content' link moving focus to the content body.

Skip link requirements

            
              <a href="#main" class="visuallyhidden focusable">Skip to content</a>

Implement as an a element with href
Match the href with the id of the container
Add .visuallyhidden class
Add .focusable class
Set as first item in the HTML document

Skip to where?

            
              <a href="#main" class="visuallyhidden focusable">Skip to content</a>
              <!-- … -->
              <main id="main" tabindex="-1">
                <!-- … -->
              </main>

The other part of creating a skip link is to send keyboard focus to somewhere useful. Remember, the purpose of the link is to skip over repeated content in order to provide quick access to the main content area.

Typically, when the link is activated, focus will be sent to an element such as the main container or perhaps an article element. These elements do not able to receive keyboard focus by default so in order to accomplish this, the tabindex attribute needs to be added to the element. Specifying a value of -1 will allow the element to receive focus, but will not be available in the tab order when moving around the page content.

With this in place, activating the skip link will bring keyboard focus from the very top of the document, past all the repeatable content, and directly to the main element. From this point, the user is able to tab forward and consume the primary content of the page.

2.4.1 Bypass Blocks

"A mechanism is available to bypass blocks of content that are repeated on multiple Web pages."

Exercise!

In your browser and editor, load: demo-site/index.html.
Add a skip link to the top of the document.
Add the code for the container to receive focus.

Color contrast

Contrast is the difference in luminance or colour that makes an object (or its representation in an image or display) distinguishable.

In other words, how readable is text against its background? If the contrast is low, people will have greater difficulty with reading the text. On the other hand, a higher contrast will allow for easy reading.

In regards to web accessibility, color contrast is the #1 offender on the web when it comes to accessibility issues. For example, colors like grey on black, light grey on white, etc. These color combinations, as well as a host of others, can be very difficult for some people to perceive.

In order to be more inclusive with our color choices, let's look at how we can test our colors to make sure they're actually readable.

Contrast threshold

Object	Ratio
Text and images of text	`4.5:1`
Large text (greater than `18pt`)	`3.0:1`
Non-text (borders, icons)	`3.0:1`

When it comes to choosing which colors to use for a design, there is a specific number, or contrast ratio, to reach for. This threshold has been determined by the W3C as a way to ensure people with low-vision are able to read text content.

The threshold breakdown is as follows:

Text and images of text, which is text content embedded within the image, has a ratio of 4.5 to 1.
Larger text greater than 18 point has a ratio of 3.0 to 1.
And non-text content, including input borders and icons, also have a ratio of 3.0 or 1.

As displayed here, the threshold is more forgiving for larger text and non-text content, such as input borders and icons. However, we still need to ensure these elements are also highly visible.

Now that we know what to watch for and which ratios should be used to test which type of content, how do we actually test the contrast ratio of our colors to ensure readability?

Contrast tools

Screenshot of Chrome Developer Tools showcasing its color contrast test feature.

Don't rely on color alone

Screenshot of input field in an error state; red border, light red background, red error text with icon below.

Screenshot of input field in an error state which is difficult to notice; grey border, light grey background, grey error text with icon below.

An icon along side error text
An underline for links embedded within body text
Textures or patterns to differentiate sections of a graph or chart

When it comes to relaying messages to the user, especially something important such as an error or success state of a form, how much time is left to complete an exercise, or sections of a pie chart, it's best to not rely on color alone to convey this information. People with low vision or color blindness may not notice and miss seeing this information.

There are different types of color blindness and low-vision impairments which makes seeing specific colors difficult or impossible. With this in mind, to help convey this important information, it's ideal to include other visual indicators such as:

An icon along side error text
An underline for links embedded within body text
Textures or patterns to differentiate sections of a graph or chart

With these extra visual affordances, people with color blindness, low-vision, or perhaps even a cognitive disability will have greater success in using and completing various tasks on your site or app.

1.4.3 Contrast (Minimum)

"The visual presentation of text and images of text has a contrast ratio of at least 4.5:1."

Exercise!

Load up the HTML pages of our demo site in your browser.
Right click an element on the page which you suspect may have poor color contrast
Click Inspect
In the Styles tab, find the color property and click the color swatch
Review the color contrast ratio value
Use the color picker to move the cursor below the white line in order to select an accessible color

Forms

Labels

Placeholders

👎 Unable to convey the purpose of the input by screen readers
👎 Placeholder text is removed from view when typing
👎 May look like text has been entered

Give the Placeholder demo a try.

HTML form fields feature an attribute called placeholder. The value of the attribute places text inside the field and when someone starts to type, the placeholder text is automatically removed.

The original purpose of this attribute is to place helper or hint text inside the input. However, sometimes placeholders are being used in place of an actual HTML label element. This is problematic for a few reasons:

Without a label element associated with the input, some screen readers may not be able to convey the purpose of the input.
When someone starts to type and the placeholder text is removed from view, the context of the input may be lost, forcing someone to remove the entered text in order to remember what the input was for.
In order to to meet color contrast requirements, the default grey text needs to be darkened. In doing so, this may confuse some people in thinking that text has already been entered into the input.

There are more issues with the placeholder attribute, but with these few in mind it's clear that the placeholder should not be used as a replacement for an actual label.

Floating labels

👍 "Floats" labels up above the input when typing
👍 Saves screen real estate
👍 label associated with its input
👎 Small text size
👎 Potential for poor implementation

Give the floating label demo a try.

The "floating label" technique seems to be picking up in popularity as of late. Depending on how it's implemented, the basic idea is to use CSS to position the label (or sometimes the placeholder) text over-top of the related input element. When someone starts typing, the label is "floated" up and placed above the input.

The benefit to this approach is that it saves space in-between inputs when screen real estate is tight. There's also the clear benefit of a label element being associated with its input element for screen readers to convey the purpose of the input.

The downside to this approach is a direct result of its purpose of being; when the label is floated up above the input, the space available typically only allows for less than ideal text size. This could result in difficulty reading the label for anyone with low-vision. Of course, they could just zoom in on the screen, but why require creating more work for our users?

Then the other concern regards the actual implementation. If the technique ends up using the placeholder attribute instead of an actual label, it would result in issues previously discussed, mainly the lack of conveyed purpose when interacted with a screen reader.

Always-visible labels

👍 label is consistent, predictable
👍 No cognitive load to remember the input purpose
👍 Screen reader support
👍 Full text size

Try out the always-visible label demo form.

The ideal design of form labels when it comes to accessibility is the "always visible" label. Just as it sounds, this technique features a text label that is always present across the whole experience of filling out the form.

The benefits of this approach are quite clear:

The text label is in a consistent, predictable position
The label is always visible, requiring no cognitive load on having to remember the input purpose
Screen readers will convey the purpose of the input when interacted with
label text is large with ample white space to be readable

With all this in mind, it's strongly recommended to keep labels visible. Eliminate any guesswork required from your users and allow them to complete the task at hand with ease and confidence.

3.3.2 Labels or Instructions

"Labels or instructions are provided when content requires user input."

Error messaging

Error text
Input styles
Error list

Error text

Screenshot of input field in error state. Arrows point out features of error state which bring in attention.

Error text is critical when conveying an error state. Without this text, people might not realize that the form is in a state in which it cannot be submitted. Sure, we could change the color of the input element, perhaps alter its border or background properties to something recognizable as an error state. However, as we've already seen, relying on color alone to convey meaning is not ideal.

So, how do we ensure the input error state is properly conveyed? A few things we can do are:

Output text which is meaningful and does not overwhelm the user with technical jargon

cognitive impairment

Display the text below the related input (low-vision).
Ensure text is readable by testing its color contrast.
Optionally include an icon to help bring the users attention to the text.

Connecting error text to its input

When someone using a screen reader comes in contact with an input in an error state, this information needs to be announced alongside the label content. Otherwise, there’s a good chance the error context could be lost when navigating through a form.

There are a few ways to accomplish this, but the most robust would be to include the aria-describedby attribute on the input element. Adding this attribute places the error text in the "queue" of announcing the element on keyboard focus. In order to programatically make the connection, the aria-describedby value needs to match the id of the error text container.

For example, let’s review an input in an error state:

This input features a label and some error text directly below. However, the text is not included with the announcement of the label. Let’s make the connection using aria-describedby:

No connection

            
              <label for="fname">First name</label>
              <input type="text"
                id="fname"
                name="fname">
              <span id="error-fname" class="error">First name is required</span>

Using `aria-describedby`

            
              <label for="fname">First name</label>
              <input type="text"
                id="fname"
                name="fname"
                aria-invalid="true"
                aria-describedby="error-fname">
              <span id="error-fname" class="error">First name is required</span>

Error list

Presenting an error list is particularly useful on large forms. It's made up of a heading, explaining the current state of the form, followed by a link list.

The heading, typically an h2, is the primary method of bringing the error state to the users attention. Sighted users will see the large text and non-visual users will have the keyboard focus state, ideally, be brought to this portion of the screen.

The heading, typically an h2, is the primary method of bringing the error state to the user’s attention. When the heading is presented to the user, send the focus to the heading element using the JavaScript focus() method as well as applying tabindex="-1" to the heading element in order for it to receive focus.

The list portion is made up of a ul list element containing links. Each link represents a single error in the form. The link text would match that of the error text output below the related input. When activated, the keyboard focus would switch from the link to the related input, allowing the user to focus and address the issue on hand.

The ideal positioning of the error list is directly above the form which is for user convenience. For example, if someone using a screen reader were to move forward past the error list, they would be brought to the form and the input elements. Each input would be accompanied by their own error state text which would inform the user on how to adjust the input content to meet its validation requirements.

The error list, in combination with the error text below the input, ensures the user is notified of the current errors which need attention, and allows the user to not have to remember each error which needs fixing. The message is available when then arrive at the input element.

3.3.1 Error Identification

"If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text."

Exercise!

In your browser, load: demo-site/blog-post.html and submit the Comment form.
In your editor of choice, load: demo-site/js/form-validation.js.
Add the JavaScript code to connect each input with its related error message.
Bonus! Test with a screen reader to make sure things are connected!

Proximity/text zoom

The straw test

Take one hand and making a fist
Open your fist just enough to let a "straw" through
Hold your fist up to one of your eyes

The straw test "test" part 1

Poor Proximity

The straw test "test" part 2

Better Proximity

How was filling out this form compared to the last when testing with the straw test? Much faster and easier to fill out? Less frustrating?

This demonstrates why, ideally, forms are designed with the form label directly above the form field. This way the form is much easier to consume for people with low-vision who may be using zoom software. It also makes things easier for everyone else in the end, as making things accessible often does.

The main purpose of the straw test is to ensure related elements and content in general is easily found for people with low-vision who rely on zoom software. Even with 20/20 vision, items which are located far apart can be difficult to find.

Let's make sure the user experience we create is easily discoverable and comfortable for our users. We don't want to make them work any harder than they already need to.

1.3.3 Sensory Characteristics

"Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound."

Screenshot of a bank website form. Primary input is at the top of a modal window, call to action buttons are at the bottom.

Responsive design

Avoid 2D scrolling

iPhones with a website loaded. One features a site with both vertical and horizontal scroll bars. The other features the same site but with only a vertical scroll bar.

In the past, if someone with low-vision needed to zoom their browser window in order to better read content, traditionally this would result in the poor experience of 2d scrolling; having to scroll horizontally as well as vertically in order to consume the content. 2d scrolling is not only an irritant for most people, it also introduces a new level of difficulty for anyone with a motor impairment or someone who relies on the keyboard alone to navigate; this requires a shift from using the Tab/Space key to read content vertically, to the arrow keys to read horizontally, and back again.

Where responsive design plays its role is now when someone zooms their browser to enlarge the content, the layout and styling rules defined within the CSS media queries will load as the zoom level increases. In other words, when content is zoomed the person on the other side of the screen will experience the “mobile” layout eliminating the need for horizontal scrolling, resulting in a much more positive user experience.

The viewport meta tag

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

1.4.10 Reflow

"Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions."

Touch targets

Touch target size

Google's Web Fundamentals — 48x48 pixels
Apple's Human Interface Guidelines — 44x44 pixels
Web Content Accessibility Guidelines — 44x44 pixels

When it comes to ensuring usability and accessibility concerns of touch target size, there are a few thing to keep in mind, including the available size of the element and space in between elements in order to avoid accidentally activating something unintended. Here are a few rules to consider from other organizations:

Google's Web Fundamentals guide recommends a touch target size of 48x48 pixels with at least 8 pixels in between.
Apple's Human Interface Guidelines recommends at touch target size of at least 44x44 pixels.
Web Content Accessibility Guidelines v2.1 also includes the recommendation of a touch target size of 44x44 pixels.

What's important to note here is when it comes to design, making the actual icon larger to satisfy these recommendations isn't required. By using the CSS `padding` property we can make the touch area larger without affecting the design or layout of the content.

Touch target example

Touch targets…

2.5.5 Target Size

"The size of the target for pointer inputs is at least 44 by 44 CSS pixels."

Whitespace

Using white space, which is the blank, empty area in between interactive components, is actually quite critical when designing and creating _usable_ user interfaces.

For example, it's not too uncommon to come across a group of links which are meant to behave as callout actions. Often these will be made up of three or more links in a grid and may feature no whitespace in between. This might provide a certain aesthetic appeal, however when it comes to someone with a **motor impairment**, such as hand tremors where they're unable to control the movements of their own hands, the usability of navigating past these callout links becomes problematic.

Let's checkout the following video for an example:

As we've witnessed in this video, the person was having great difficulty when trying to navigate past these large touch target and repeatedly activated the links by accident. This is why it's ideal to place at least 8-10 pixels of whitespace in between interactive elements. Without this white space, it can result in a frustrating user experience.

Offscreen content

Repeated link content

            
              <a href="article/how-to-make-pasta-sauce.html">
                Read more
              </a>

Providing context without disrupting design

Visually hidden text

            
              <a href="article/how-to-make-pasta-sauce.html">
                Read more
                <span class="visuallyhidden">about How to Make Pasta Sauce</span>
              </a>

The CSS visuallyhidden class definition is a way to visually hide text content from sighted users, yet, have it be available for screen reader users.

This method was originally created by Jonathan Snook and has since been adopted in the HTML5 Boilerplate project as a default class definition in its CSS offering.

Coming back to the "Read more" link example, we see here the HTML looks the same as before but with the addition of a new span element. This span features the visuallyhidden class which means the text content within will be hidden from sighted users, preserving the original design, but also provides the extra context needed for screen reader users.

Now, when someone using a screen reader encounters this link, they would hear, "Read more about How to Make Pasta Sauce."

The `aria-label` approach

            
              <a href="article/how-to-make-pasta-sauce.html"
                aria-label="Read more about How to Make Pasta Sauce">
                Read more
              </a>

Using the aria-label attribute is an alternative to the visuallyhidden CSS method. This approach directly sets the intended hidden content as the accessible name for the element.

Revisiting the link example from before, this code is a little bit cleaner and easier to read compared to the visuallyhidden example.

One thing you may have noticed is the repeat content of, "Read more" within the aria-label attribute. This is required in order for a screen reader to announce the text in its entirety.

As a result of using the aria-label attribute is that the attribute value takes precedence over anything else that’s placed within the link element. In other words, when you apply the aria-label attribute, any text within the element will be completely ignored by screen readers.

2.4.4 Link Purpose

"The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general."

A few more examples…

A table of `button`s

Don't do this:

                
                  <button>Remove</button>

Do this:

                
                  <button
                    aria-label="Remove {item title}">
                    Remove
                  </button>

Star ratings

Don't do this:

                
                  <i class="icon icon-star star-4"></i>

Do this:

                
                  <span class="icon icon-star star-4">
                    <span class="visuallyhidden">4 out of 5</span>
                  </span>

It’s common to see a visual representation of a rating on a product page. Often this is represented by a set of icons, typically star icons, representing a 0 to 5 range. The visual meaning of the star image is typically understandable enough for sighted users, but how do we provide an accurate text alternative for someone using a screen reader?

Here’s a typical example of a star rating markup outputting icons: using an i element to simple output a set of icons.

Guessing by the class name, star 4, this might output a "4 out of 5" visual rating, but if someone’s using a screen reader, there’s nothing available to convey the same information.

In order to do so, add some visuallyhidden text to provide a text alternative (and also swap the i element for a span as i has semantic meaning):

Now when a screen reader encounters this content, the visuallyhidden text alternative will be announced, providing content for the user to understand the current product rating: "4 out of 5 stars."

Offscreen navigation

An animated GIF showcasing offscreen menu being activated and sliding into view.

Completely hiding content

CSS display: none (difficult to animate)
CSS visibility: hidden (easier to animate)

HTML hidden attribute

                
                  <span hidden>Hidden content</span>

In order to hide content completely from sighted users, keyboard-only users, and screen reader users, there are a few methods we can take:

Applying CSS display: none to the drawer container will accomplish the desired effect of hiding the content from keyboard users. One note on this solution is that the display property cannot be animated without some extra JavaScript setting the property at a specific time.
Applying the CSS visibility: hidden property essentially produces a similar result as using display: none. The difference here is the visibility property is much easier to animate, especially when used alongside the opacity CSS property.
Lastly, applying the HTML hidden attribute to the drawer container would product the same result as the CSS display: none property; hiding the content completely from visual and non-visual users alike.

An accessibility issue with this pattern arises when the drawer container is positioned off-screen via CSS position property only. The menu is tucked away visually, however, when someone using a keyboard to navigate Tabs through the page content, these visually “hidden” links will still be focusable, essentially creating hidden tab-stops. This is an issue as the keyboard-only user is not able to determine the current focus position on the screen.

If visually hidden, hide from keyboard and assisitve technology, too.

2.4.3: Focus Order

"If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability."

Animation

Have you ever had a bad day where you're just not feeling great? Perhaps you have a headache, or feeling nauseated from the night before? Then you go online to be greeted with a bunch of animation, scroll jacking, parallax motion, or a video background on a slide that it only make you feel worse! It happens to us all at some point or another.

Using animation on the web is a great way to bring a unique flare to your design and maybe add a bit of delight to your user experience. Well designed animations are informative; they let the user know something has taken place or are used to guide the user to a new task which needs attention. Ideally, animations would be useful, predictable, and consistent.

On the other hand, poor use of animations might be distracting, take the attention away from the current task, and might even leave someone feeling queasy and disoriented.

What actually makes up a "poor" animation

Size of movement — Keep animations small and purposeful
Direction and speed – Allow the user to scroll at their own pace.
Distance — Refrain from animating long lengths of content

Everyone will have a different reaction, or perhaps no reaction at all, to a piece of animation. For those who do experience a negative reaction, how to we avoid creating such an experience?

Here's a few points to consider when creating animations:

Size of movement. Small or compact animations, like a loading spinner, are helpful. However, if there's something moving from one side of the screen to another, especially critical pieces of content, this can be problematic. Keep animations small and purposeful.
Direction and speed. Parallax effects and scroll jacking, which tend to involve foreground and background elements moving at different speeds, or objects moving in different directions than expected, can cause issues. Allow the user to scroll at their own pace.
Distance. For animations which seem to span large lengths of space, although only the size of a computer screen, can sometimes trigger a negative experience. Again, it's best to keep animations small and compact in order to avoid a negative user experience. Refrain from animating long lengths of content.

Animation is something that can unexpected, and when it's there, we typically don't have a whole lot of control over the experience. How can we ensure when animation is in use that we also create an accessible experience?

Animation and accessibility

Someone with a cognitive impairment may get easily distracted or frustrated
Someone with Vestibular issues may experience vertigo or feel nauseated

Animation example

The `prefers-reduced-motion` media query

Setting the OS

macOS Settings
Accessibility
Display
Activate the Reduce motion checkbox

Screenshot of macOS Accessibility settings.

Coding a "no animation" state

            
              a {
                color: Crimson;
                transition: color .25s;
              }

              a:focus, a:hover {
                color: FireBrick;
              }

              @media (prefers-reduced-motion) {
                a {
                  transition: none;
                }
              }

When we want to remove or disable a piece of animation in a website, we can add the CSS to a prefers-reduced-motion media query.

For example, if there was a transition set on all a elements to animate the color on hover and focus, the CSS might look like: (what's on the screen)

And if, for example, the end user didn't want to wait the .25 seconds for the transition to complete for some reason, we could provide a "no animation" state by utilizing the prefers-reduced-motion media query:

And that's it! By including this bit of CSS, any transition animations set on the a selector will be removed when the user has selected the Reduce motion option in their operating system settings.

As of this writing only Safari and Firefox support this media query with other browsers and operating systems trailing behind.

By using the `prefers-reduced-motion` media query, we're allowing our users to remove all animations which they may find distracting or jarring. Remember, the key here is to provide a usable and comfortable user experience in order for people to enjoy, return to, and share the content we create.

Browser/OS Support

2.3.3 Animation from Interactions

"Motion animation triggered by interaction can be disabled, unless the animation is essential to the functionality or the information being conveyed."

Exercise!

In your browser, load: demo-site/blog-post.html and
- Mouse-over the "Leave a Comment"
- Click the "Newsletter" link
In your editor of choice, load: demo-site/css/styles.css.
Add the prefers-reduced-motion media query to disable the fade-in animations.

ARIA

How does ARIA accomplish this?

Attribute	Purpose	Example
`role`	Used to add or alter the base semantic meaning of an element.	`<div role="button"></div>`
`aria-label`	Adds an accessible name to an element.	`<div role="button" aria-label="Fake button"></div>`
`aria-disabled`	Announces the element as in a "disabled" state.	`<div role="button" aria-label="Fake button" aria-disabled="true"></div>`

What ARIA does not do

Does not make elements keyboard focusable
Does not automatically provide keyboard support

Custom components

Checkbox in HTML

A label element
The input element
A clearly defined state

Checkbox in HTML

            
              <label for="apple-checkbox">
                <input type="checkbox"
                  id="apple-checkbox"
                  name="apple">
                Apple
              </label>

Checkbox built with ARIA

An accessible name
Its role conveyed
A clearly defined state

Checkbox built with ARIA

            
              <div class="checkbox__wrapper">
                <div class="checkbox__checkbox"
                  role="checkbox"
                  tabindex="0"
                  aria-checked="false"
                  aria-labelledby="apple-checkbox"></div>
                <div class="checkbox__label"
                  id="apple-checkbox">Apple</div>
              </div>

Let’s look at the HTML code to accomplish this…

The div with class="checkbox__checkbox" would represent the checkbox visual, typically with an SVG icon or CSS
This div also features role="checkbox". This is the attribute required for screen readers to announce this component as a "checkbox." Without it, it would appear as a generic container.
The div features the tabindex attribute with its value set to 0. This allows non focusable elements to receive keyboard focus when the user Tabs to the element.
The aria-checked attribute is present which conveys the current state of the checkbox. When interacted with, this value would need to toggle from false to true.
Finally, the div has the aria-labelledby attribute with its value set to the id of the element which holds the text label. When this div receives keyboard focus, the aria-labelledby attribute will make the connection with the element which matches its value and add the matching element’s content to the announcement of the checkbox on focus.

As you may be able to tell, using the ARIA method is quite a bit more code to write and maintain. This is only the HTML needed to create the ARIA version of a checkbox. There’s also the CSS code to visually style the checkbox as well as the JavaScript to handle the Space keypress event and toggle the aria-checked value.

For this reason, it’s recommended to use native HTML elements. This way there’s less code to write and maintain, as well as the built-in keyboard support and semantic meaning that comes with each native element.

Non-standard components

Live region components

Screen reader speech bubble announcing, 'Success!'

One other unique feature that ARIA adds is the ability to create a live region. With a live region, you’re able to send an audible message out to screen reader users, when appropriate, in order to inform them of a change in state upon interaction or a timed message.

For example:

When sending or deleting an email from a list, it would be ideal to let the user know when the message was either sent or removed from their inbox
When adding an item to a cart, make the user aware of the successful addition
If someone has a limited amount of time to complete a task, announce the amount of time remaining in semi-regular intervals
If an app is currently in a loading state displaying a loading animation, make screen reader users aware of this context as well

The purpose of a live region is to help provide an equal user experience for those who are unable to see the user interfaces we create and make sure they're made aware of the current context.

Refer to the WAI-ARIA 1.1 spec document for more information.

Dynamic components

Modal window

A modal window is a common component used in order to bring the user’s attention to something important. It’s often represented visually with a small portion of content right in the middle of the screen with the rest of the page content "below" or "behind" the modal content with a darkened overlay. Essentially this visual representation states to the user, "Put whatever it was you were doing on hold as this content is really important. Please provide your full attention on me for now."

When it comes to interacting with a modal window, someone using a mouse can either dismiss the window by clicking the close button, clicking a call-to-action button (usually "Ok" or "Cancel"), or sometimes the darkened overlay itself can be interacted with to dismiss.

However, when it comes to someone using just the keyboard, how can we ensure the expected interactions are available to successfully navigate a modal window? What are the expected interactions? How do we convey the information needed to inform a screen reader user, someone who may not be able to see the modal window visual, of the current context they’re interacting with?

Let’s look through the Authoring Practices guide on creating a modal window; the expected keyboard interaction, managing focus, and adding the appropriate ARIA attributes.

Keyboard interaction

Key	Expected interaction
`Tab`	Moves focus to the next focusable element inside the modal window. If keyboard focus is on the last focusable element inside the modal, the next `Tab` keypress moves focus to the first focusable element inside the modal.
`Shift` + `Tab`	Moves focus to the previous focusable element inside the modal window. If focus is on the first focusable element inside the modal, the next `Shift` + `Tab` keypress moves focus to the last focusable element inside the modal.
`Escape`	Dismisses the modal window.

The expected keyboard support is as follows.

When pressing Tab
- Moves focus to the next focusable element inside the modal window.
- If keyboard focus is on the last focusable element inside the modal, the next Tab keypress moves focus to the first focusable element inside the modal.
When pressing Shift Tab
- Moves focus to the previous focusable element inside the modal window.
- If focus is on the first focusable element inside the modal, the next Shift + Tab keypress moves focus to the last focusable element inside the modal.
When Esc is pressed, the modal window is dismissed.

Focus management

Upon activation, shift focus from the control to the modal window
Trap keyboard focus within the modal window
When dismissed, return focus to the control

Focus management is a method used to willfully and purposefully move the keyboard cursor from one element to another on behalf of the user. This technique is sometimes required to guide the user with the intended flow of the app. Focus management should only be used when absolutely necessary as to not create more work for the user when an unexpected shift in focus has occurred. (When to shift focus is pointed out in the ARIA best practices guide.)

Let’s review the required focus management for an accessible modal window component.

When the user activates the launcher control (typically a button element but could also be an link depending on the context), the keyboard focus will shift from the control to the modal window container.
As pointed out in the previous section, keyboard focus should remain within the modal window when using Tab, Shift + Tab or the screen reader virtual cursor to navigate.
When the modal window is dismissed, focus should return to the control which launched the window. This way, the user can carry on with their task right where they left off.

ARIA roles, states, and properties

Element	Attribute	Usage
Launcher `button`	`aria-haspopup="modal"`	Informs the user of a modal context upon interaction
Modal container `div`	`role="dialog"`	Identifies the current container and context as a modal window
Modal container `div`	`aria-labelledby="IDREF"`	Helps to describe the purpose of the modal window by referencing the `h2` heading element — if no heading is available, use `aria-label` instead
Modal container `div`	`aria-modal="true"`	Informs assistive technologies that the content underneath the current dialog are not available for interaction

When someone using a screen reader encounters a modal window, they need to know what it is they’re currently navigating and interacting with. The method to share this information is through applying ARIA attributes to specific HTML elements.

On the launcher control, add aria-haspopup="modal" — This hepls to inform the user of a modal context upon interaction
The modal container should have role="dialog" — This identifies the current container and context as a modal window when it receives focus
The modal container should have aria-labelledby attribute — This helps to describe the purpose of the modal window by giving it an accessible name by referencing the heading element. If no heading is available, apply the aria-label attribute instead and provide a name this way
Finally, the modal container should have aria-modal attribute — This informs assistive technologies that the content underneath the current dialog are not available for interaction

Keyboard trap?

The `inert` attribute

Definition: When a node is inert, the user agent must act as if the node was absent for the purposes of targeting user interaction events, may ignore the node for the purposes of text search, and may prevent the user from selecting text in that node.
Polyfill: github.com/WICG/inert

Using `inert`

            
              <header inert>
                <!-- … -->
              </header>

              <main inert>
                <!-- … -->
              </main>

              <footer inert>
                <!-- … -->
              </footer>

              <div class="modal" …>
                <!-- … -->
              </div>

Exercise!

In your browser, load: demo-site/popup.html
In your editor of choice, load: demo-site/js/modal-window.js
Add the JavaScript code to make the "Sign up for our newsletter" modal accessible!
Bonus! There are other issues to fix — can you find them?

"Don't think of accessibility as a chore that's too difficult to implement, but rather a coding challenge."

– @vavroom

Thank you!

Animated GIF of Harry Potter saying, 'Great work everyone. Well, well done.' Children clapping.

Find me @svinkle — DMs are always open! 🚀

Web Accessibility for Developers

Agenda

Intros! 👋

What is accessibility?

Mindfulness is key

Disabilities

Understanding Disabilities

Visual impairments

Challenges and assistive technology

Deafness / hard of hearing

Challenges and assistive technology

Motor disabilities

Challenges and assistive technology

Vestibular issues / seizure disorders

Challenges and assistive technology

Cognitive disabilities

Challenges and assistive technology

Temporary disabilities

The four principles of accessibility

W3C 👉 WAI 👉 WCAG

P.O.U.R.

Perceivable

Operable

Understandable

Robust

WCAG Success Criteria

Keyboard

Focus indicator

✅ 2.4.7 Focus Visible

Custom focus indicator

Detect keyboard/mouse usage

Focus order

✅ 2.4.3: Focus Order

Focus management

tabindex="-1"

tabindex="0"

tabindex="1" or higher

Exercise!

Semantic HTML

The accessible name/label/text equivalent

The element role

The current state

✅ 1.3.1 Info and Relationships

Testing with screen readers

Common screen reader commands

Starting up

Pause announcements

Tabbing around

Screen reader virtual cursor

Screen reader + browser combinations

Exercise!

Page title

How to write title text

Updating the state

✅ 2.4.2 Page Titled

Exercise!

Page structure

Logical heading order is key

Examples

Landmark elements

✅ 2.4.6 Headings and Labels

Exercise!

Image alt text

Who benefits from alt text?

Images missing the alt attribute

When to include alt text

How to write alt text

✅ 1.1.1 Non-text Content

Exercise!

Links vs Buttons

Link and button expectations

Control design

Control design and accessibility

Hover, focus, and active state

Hover state

Focus state

Active state

Notes on the href attribute

The missing href

Including a unique href value

2.4.7 Focus Visible

2.4.3: Focus Order

`tabindex="-1"`

`tabindex="0"`

`tabindex="1"` or higher

1.3.1 Info and Relationships

Page `title`

How to write `title` text

2.4.2 Page Titled

2.4.6 Headings and Labels

Images missing the `alt` attribute

1.1.1 Non-text Content

Notes on the `href` attribute

The missing `href`

Including a unique `href` value

Including a unique `href` value

2.4.4 Link Purpose

2.4.1 Bypass Blocks

1.4.3 Contrast (Minimum)

3.3.2 Labels or Instructions

Using `aria-describedby`

3.3.1 Error Identification

1.3.3 Sensory Characteristics

1.4.10 Reflow

2.5.5 Target Size

The `aria-label` approach

2.4.4 Link Purpose

A table of `button`s

2.4.3: Focus Order

The `prefers-reduced-motion` media query

2.3.3 Animation from Interactions