Web Accessibility for Designers

Essential Tools for Inclusive Design

Slides: github.com/svinkle/web-accessibility-for-designers-workshop

Agenda

The basics of accessibility
Understanding various disabilities
Color contrast
Heading structure and design
Control design
Form design
Animation
Visual focus indicator
Touch targets/white space
Content

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?

When we speak about accessibility on the web we're talking about making sure our apps and web sites that we create are understandable and usable by people with disabilities. In doing so, we actually increase the usabilty for all.

Think of a few things in the physical world that have been implemented to aid folks with a disability; automatic doors, curb cuts at street intersections, elevators and escalators. These features are pretty great and make everyone's lives a little easier at one point or another.

Making something accessible does not only involve the code behind the app or site, but a lot of what we design visually and the user experience we determine and set in place for our users plays a very large part in the accessibility of our products.

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 design 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 designing 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

Since the web is primarily a visual medium, it's important to design with an inclusive mindset, one which considers those who are able to see the screen and also those who use various input devices to interact with our user interfaces who are unable to see the screen at all.

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

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

The World Wide Web Consortium (W3C) is an international community that develops open standards to ensure the long-term growth of the web. These standards include things such as the HTML and CSS specifications, as well as standards for web payments, commerce, and security.

One key group formed from the W3C is the Web Accessibility Initiative (WAI). This group is responsible for creating new content for and maintenance of the Web Content Accessibility Guidelines.

WCAG (also pronounced "wuh-cag") is a world-wide recognized standard for testing and implementing accessible user experiences for people with disabilities. It's used for desktop web, mobile web and native apps, and pretty much any type of digital content.

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?

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

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 your 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 ration of 4.5 to 1.
Larger text greater than 18 point has a ratio of 3.0 or 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.

We have available to us quite a number of color contrast testing tools. Some are more automated than others; which one you use might depend on your current need.

Here's a few contrast ratio tools to consider:

Snook's Color Contrast Checker is a great tool for testing the contrast ratio, includes lots of other details and tools
Lea Verou's Contrast Ratio calculator has a nice and simple UI to test color contrast
Chrome Dev Tools now has color contrast tests built-in to its dev tools
Lighthouse is another set of tools built in to Chrome which includes automated accessibility testing, including color contrast tests
Color Contrast Analyser for Sketch is a Sketch plugin that calculates the color contrast of two layers and evaluates the output against WCAG requirements

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! 🎨

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 above the white line in order to select an accessible color

Heading structure

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

2.4.6 Headings and Labels

"Headings and labels describe topic or purpose."

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;
              }

In addition to the hover and focus state, the active state is also available.

The active state shows only when an element is currently being interacted with. For example, when someone clicks down on a link and then releases the mouse button, that in-between state is the active state.

Including a unique active state style helps people with motor impairments or even dyslexia as when an item is interacted with, the active state serves as a confirmation and reassurance that the element was clicked.

I know I'm showing some code here but what's important is to include each state in your design and clearly annotate which color variation represents which state. This way a developer can implement these when they start their work.

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

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.

Form design

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.

Required fields

Notes which fields are absolutely necessary to fill in
Ensure placement of the icon is consistent
Contrast ratio high enough to be visible

See an example of required fields notice.

When only specific fields are required to fill out a form, it's best to denote this requirement with a visual cue. This helps people to know which fields they absolutely need to fill in which in turn provides reassurance when filling out the form.

Typically this is done with an asterisk character placed beside the form label. Weather you use the asterisk or some other form of icon, what's important here is:

The placement of the icon is consistent throughout the form
The icon features a contrast ratio high enough to be visible (3.0:1 for non-text elements)

In addition to the visual cue for each required field beside the label, it's also ideal (but not necessarily required) to place visual instructions at the top of the form noting what the icon is for. Something along the lines of:

* denotes a required field

With this visible note, people with cognitive impairments will have less trouble with understanding what the icon is for.

(Load up a Shopify store as an example of an alternative method.)

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.

Input styles

In addition to the error text to convey the current state, we can also consider altering the visual design of the input. This is typically done by adding a red border for extra visual aid. In doing so, people who are able to perceive the color change will have a better understanding that this input requires their attention.

Optionally, sometimes the input background color is also changed to something like a light red. Use caution when altering the current state of the form so drastically; when some people are met with a wall of red, they can be easily overwhelmed and feel a sense of frustration or self-doubt. The ideal state we wish our users to remain in is calm and confident. If they're able to get through filling out a web form with ease, they'll be more likely to return and recommend you site or app to their friends and family.

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 list itself is best positioned above the form.

The heading 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 list portion is made up of a list element containing links. Each link represents a single error in the form. Its 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 form content to meet its 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.

Error list demo

Angular Forms Demo — Next-Level Accessibility

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

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

How to ensure "accessible-friendly" animations

Design subtle animations — minimize altering speed, movement, or control
Animations should be easily understood and predictable
Design a "no animation" state — allow people to use tools in their operating system
Allow animations to be paused — give control to the user

To be clear, the recommendation isn't to not use animation as some animations can be quite helpful. Let's look at a few ways to create an accessible and inclusive experience through use of animation:

Design subtle animations. Using animations in way that is subtle and used as a means to guide the user can be very helpful. Try to minimize animations which alter default speed, movement, and control that users are accustomed to.

For example, when adding an item to a shopping cart, there could be an animation to highlight this activity as complete. Another example might be when submitting a dynamic form, animate an error or success message to draw the users attention to this area.
Animations should be easily understood and predictable. In keeping with the "subtle" theme, animation should ideally be use in a way that people can understand the meaning behind the animation.

An example of which; the classic loading spinner. This helps to inform the user that progress is being made and a background process is being run. It basically conveys the message, "Please be patient while we process your data."
Design a "no animation" state. It is possible for people to "turn-off" animations at an operating system level. For example, the macOS Accessibility settings features the "Reduce motion" option.

With this setting enabled, developers can take advantage of the CSS media query, "prefers-reduced-motion." Any styles applied within this media query would be those to produce the "no animation" state. This would be idea for any site featuring parallax scrolling; with this CSS media query in use, a developer could create a layout for a "static" alternative.
Allow animations to be paused. If there are background videos, carousel sliders, or even animated GIF images on screen, provide a means for these types of content to be paused.

Build the pause control into each element, but if there are many different animations to be halted, consider designing and implementing a global, "Pause all animations" control. Your users who are susceptible to motion sickness will thank you.

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! 🎈

Break into groups of 3 (or 4)
Each group gets 1 balloon
Designate someone to inflate and tie off the balloon
Toss the balloon between your group members, and…
Complete this task on your phone:
- Find what's playing at a local movie theatre, this Saturday, 7pm
Try not to drop the balloon!

Focus indicator

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

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.

What happens when you use the Tab key on a site is the keyboard cursor will move from one HTML element to the next. The elements highlighted are 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.

Sometimes, the request is made to remove the focus indicator outline. This is usually a result of the outline being displayed on mouse interaction which can be viewed as a negative cosmetic result. While it is strongly recommended to not remove the default indicator, there are a few work-arounds which could be used as a replacement.

Custom focus indicator

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

Keep in mind…

Ensure the contrast ratio of the indicator against the background is high. If people can't see the focus indicator the its purpose is lost.
Make it consistent. Since a custom focus indicator will be unexpected on first visit, it's a good idea to keep things consistent and predictable throughout the user experience of the site.

Detect keyboard/mouse usage

There's been lots of great work done recently on detecting when someone's using a mouse or a keyboard to navigate site content. In doing so, designers are able to create a custom, highly visible focus indicator for keyboard users only. Mouse users would be free to rely on only the mouse cursor as their indicator.

This technique is not yet built directly into browsers. However, there are third-party code snippets (also called a "polyfill") available to gain this functionality.

Two of which worth checkout out include:

When implementing a custom outline, there are a couple things to keep in mind:

Ensure the contrast ratio of the indicator against the background is high. If people can't see the focus indicator the its purpose is lost.
Make it consistent. Since a custom focus indicator will be unexpected on first visit, it's a good idea to keep things consistent and predictable throughout the user experience of the site.

2.4.7 Focus Visible

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

Exercise! ⌨️

Go to your browser and open up some of your favorite sites. Try navigating with just the Tab key. Are you able to see where the keyboard cursor is currently placed? Or is there any focus indicator at all?

Touch target size and whitespace

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.

Content is also design

Why do people visit your site? What keeps them coming back for more? Most likely its a result of high quality content. Content makes up the essence of the web and why people spend so much of their day there. As a result, content itself needs to be well designed in order to create a comfortable user experience.

Not all users of the web have received the same amount of education in their lifetime. Some of us read at different levels and at different speeds. Those with a **learning disability** may have difficulty reading and comprehending content which is full of jargon, acronyms, and other complexities.

How then, do we continue to write quality content that is both informative and inclusive to meet the needs of our readers?

In order to ensure content is readable and understandable by as many people as possible, consider testing your content readability with the Hemingway app. This handy utility app will read your content and make recommendations based on how difficult it might be for someone to read and comprehend. Some of the recommendations include:

Considerations when using adverbs
Use of passive voice
Complexity of phrases
Difficulties in sentence comprehension

By running your content through this utility, you will end up restructuring your content to better suit a more general audience. The recommended reading level for inclusive content is usually 7th or 8th grade reading level. The Hemingway app will let you know how your content measures up with this requirement.

Designing for Dyslexia

Avoid justified text, always left/right align
Avoid pure black text on pure white background
Sparingly use italicized styles
Consider offering Dyslexie as an option

Someone with **Dyslexia**, which is a disability that impairs a person's fluency or accuracy in being able to read, write, and spell, may have difficulty reading the content on screen.

There are a few design considerations for making text itself readable for folks with Dyslexia. The following are things to **avoid** when designing content:

**Justified text.** Text which is fully justified can cause dyslexic readers to repeatedly lose their place when reading. To avoid this frustration, always left align text (or right align, depending on your region.)
**High contrast.** Text which is styled to be pure black (#000000) against pure white (#ffffff) can generate a high contrast reading environment. As a result, some dyslexic users may experience words to swirl or blur together.
**Italicized content.** Use of italicized text can actually result in a poor reading experience for people with Dyslexia as a result of the slanted nature and extra pixelation of letter shapes. Use sparingly!
Consider offering Dyslexie font as an option — Dyslexie is a soecialized font face to help readers with dyslexia.

Readability: Larger font sizes equates to increased readability. This makes for an easier reading experience for folks with low-vision, including older generations who usually require larger font on any UI due to eyesight deterioration. Bumping up the font size on any site by a few pixels greatly helps with readability.
Usability: Larger fonts means less content required to fill available space in a design. Less content means less cognitive load on readers. Less content required also means being precise and direct when writing content, meeting the requirement of lowering the reading level, which in turn, increases readership and user base as a whole.
Scannability: It’s quite common for people to quickly scan a page of content just to get a feel for what the page has to offer. With larger font sizes, especially headings when they’re designed and used in a visual hierarchy, this increases the sannability of content. The benefit again is to lower cognitive load. And on the flip side of the age equation, younger generations tend to have less patients and attention, therefore scannability is key to getting your message across to younger readers.

Larger font size means less screen clutter which generates a clearer reading path and more of what people want; content.

More design considerations

Line length

Screenshot of W3C Web Payments Working Group homepage.

Line height

Text zoom

Screenshot of a hotel booking website with 200% zoom enabled. Text elements are overlapped and difficult to read.

One other WCAG SC that’s important to consider when designing typography is 1.4.4 Resize text. This states that someone should be able to resize text up to 200% without loss of content or functionality.

In other words, allow for text and content containers to grow organically in size when text is resized. In CSS, static sizing units such as px are to be avoided. Whenever possible, use flexible units like %, em, or rem.

It’s also worth noting that text resize as referenced by this WCAG SC is different than the browser default zoom. Modern browsers today will zoom in using the viewport, essentially using CSS media queries to resize and align content. When the viewport is zoomed in far enough, you might see mobile styles and layout.

This is different than zooming by text alone, which only enlarges text an nothing else. To test for this, use Firefox text zoom option, or a browser extension with your prefered browser.

1.4.4 Resize text

"Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality."

Image 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 is 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.

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

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 Designers

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

Color contrast

Contrast threshold

Contrast tools

Don't rely on color alone

✅ 1.4.3 Contrast (Minimum)

Exercise! 🎨

Heading structure

Logical heading order is key

Examples

✅ 2.4.6 Headings and Labels

Control design

Control design and accessibility

Hover, focus, and active state

Hover state

Focus state

Active state

✅ 2.4.4 Link Purpose

Proximity/text zoom

The straw test

The straw test "test" part 1

The straw test "test" part 2

✅ 1.3.3 Sensory Characteristics

Form design

Labels

Placeholders

Floating labels

Always-visible labels

Required fields

✅ 3.3.2 Labels or Instructions

Error messaging

Error text

Input styles

Error list

Error list demo

✅ 3.3.1 Error Identification

Animation

What actually makes up a "poor" animation

Animation and accessibility

Animation example

How to ensure "accessible-friendly" animations

✅ 2.3.3 Animation from Interactions

Exercise! 🎈

Focus indicator

Custom focus indicator

Detect keyboard/mouse usage

✅ 2.4.7 Focus Visible

Exercise! ⌨️

Touch target size and whitespace

Touch target size

Touch target example

✅ 2.5.5 Target Size

Whitespace

Content is also design

Designing for Dyslexia

Font size

1.4.3 Contrast (Minimum)

2.4.6 Headings and Labels

2.4.4 Link Purpose

1.3.3 Sensory Characteristics

3.3.2 Labels or Instructions

3.3.1 Error Identification

2.3.3 Animation from Interactions

2.4.7 Focus Visible

2.5.5 Target Size

1.4.4 Resize text

1.1.1 Non-text Content