298 results

Web Accessibility

What is Web Accessibility?
- Common Considerations
Simulating Disabilities for Testing
Understanding WCAG Guidelines and Developing Testing Strategy
Designing with Accessibility in Mind
Developing Accessible Navigation and Content
Accessible Form Design
Adding Accessibility to Images and Media
Video, Audio, and Accessibility

What is Web Accessibility?

Practice of making websites usable for the widest range of people possible, including those with disabilities.

this also includes those with partial disabilities
some people only interact with web through screen readers and/or a keyboard (or assistive technology that mimics keyboard behavior)

Common Considerations

Visual Disabilities
Auditory Impairments
Physical and Motor Disabilities
Cognitive, Learning, and Neurological Disabilities
Speech Disabilities
Technical Issues
Changing Abilities
Temporary Disabilities

Visual Disabilities

manifestations
- blindness
- low vision
- color blindness
impact on web usage/design
- enlarged/reduced text size
- custom fonts, colors, and spacing
- text-to-speech
- audio descriptions for video
- keyboard navigation
- refreshable braille
- structure/semantics are important
- design/color perceived differently
- custom settings should work
common barriers
- missing text alternatives (i.e. no alt text on img tags)
- improper labels
- missing orientation cues
- missing captions or transcripts
- improper document structure
- inconsistent navigation/functionality
- lack of support for custom colors
- lack of keyboard support

Auditory Impairments

manifestations
- deafness
- hard-of-hearing
impact on web usage/design
- need visual descriptions
- need transcripts
- no background noise
common barriers
- missing captions
- captions not adjustable (font size and color)
- too much background noise (low quality audio)
- missing transcripts
- trouble with voice interactions

Physical and Motor Disabilities

manifestations
- lack of motor control
- speech troubles
- limitations of muscle control
- paralysis
- limitations of sensation
- joint disorders
- chronic pain
- other issues
- some examples include:
  - Amputation
  - Arthritis
  - Fibromyalgia
  - Reduced dexterity
  - Muscular dystrophy
  - Repetitive stress injury
  - Tremor or spasms
  - Paralysis
impact on web usage
- special keyboard or mouse
- head pointer or mouth stick
- foot, shoulder, sip-and-puff switches
- voice recognition and eye tracking
- mouse-like or keyboard-like devices
- require more time
- trouble clicking small areas
impact on web design
- provide large clickable areas
- provide more time
- provide error correction options
- provide clear focus indication
- provide skip navigation links
common barriers
- missing keyboard support
- not enough time to complete tasks
- missing text alternatives
- missing or improper labels
- missing orientation cues
- improper document structure
- inconsistent navigation/functionality

Cognitive, Learning, and Neurological Disabilities

manifestations
- learning disabilities
- distractibility
- inability to remember or focus
- range of movement
- vision
- hearing
- comprehension
- other psychiatric disabilities
- some examples include:
  - ADHD
  - Autism
  - Intellectual disabilities like Down Syndrome
  - Mental health disabilities like anxiety, delirium, depression, and schizophrenia
  - Memory impairments like dementia
  - Diseases like multiple sclerosis
  - Perceptual disabilities like dyslexia
  - Seizure disabilities like epilepsy or migraines
impact on web usage/design
- structure/semantics are important
- need consistent labelling
- need predictable functionality
- need different methods of navigation
- need simpler text with images
- may use text-to-speech
common barriers
- complex navigation and layouts
- complex/unusual wording
- large amounts of text without images
- moving or flashing content
- audio that can't be turned off
- no method to disable motion/animation

Speech Disabilities

manifestations
- apraxia of speech
- cluttering
- dysarthria
- speech sound disorders
- stuttering
- muteness
impact on web usage/design
- issues with voice-based services
- troubles producing speech that's recognizable by software
- issues with telephone only communications
common barriers
- voice-only interaction
- phone as only communication

Technical Issues

manifestations
- slow connection, screen size, old technology
impact on web usage/design
- TBD
common barriers
- TBD

Changing Abilities

manifestations
- effects of aging
impact on web usage/design
- TBD
common barriers
- TBD

Temporary Disabilities

manifestations
- broken bones, recovery
impact on web usage/design
- TBD
common barriers
- TBD

Simulating Disabilities for Testing

Testing with Keyboard

tab through in proper order?
appropriate visual feedback to know where we are focused?
do form controls and links work as expected?

JAWS
NVDA

Test with a Simulator

Web Disability Simulator (Chrome extension)

Understanding WCAG Guidelines and Developing Testing Strategy

Planning

Identity Goals
Put someone in charge of accessibility for project (to keep everyone on track)
Evaluate Tools and Frameworks
- if they're not accessible, we shouldn't use them!
Do some research about current tools and best practices regarding accessibility
Create Personas with different types of disabilities
- we can refer to throughout design and development process
- commonality for discussion
- create empathy

WCAG

created by the W3C (World Wide Web Consortium)
single set of accessibility guidelines
contain "success criteria" and "levels of conformance"
ensure content is accessible to as many people as possible

WCAG 2.0

overview
Quick Reference
published December 2008
12 guidelines organized into 4 principle categories: P.O.U.R.
Perceivable
- cannot be invisible to all their senses
Operable
- must be able to operate all UI controls
- cannot require interaction that can't be performed
Understandable
- must be able to understand information and UI
Robust
- should not be fragile
- should work in a variety of user agents and assistive technologies
- should be as future proof as possible

WCAG 2.1

Quick Reference
published June 2018
extends WCAG 2.0
now official W3C recommendation
additions focused 3 specific groups
- cognitive or learning disabilities
- low vision
- disabilities on mobile devices

Testing WCAG Compliance with WAVE

WAVE web accessibility evaluation tool
NOTE: 0 errors != accessible!

Automated Accessibility Testing with AXE Core

axe-core
- developed by Deque Labs

Designing with Accessibility in Mind

pick color palettes that are color-blind-friendly
don't rely solely on color to convey information
accessible touch targets are usually recommended to be at least a square of 44px-48px
make sure icons
- are simple and recognizable
- have text to make intention clear
related to motion
- transitions, animations, blinking/strobing, parallax effects
- common things that can cause seizures:
  - flashing 3 times per second
  - high contrast strobing effects
  - flashing including red
- NOTE: a flashing cursor will not trigger a seizure
- may be helpful to have a way for users to disable animations entirely
typography
- healthy body copy font size is 16px-20px
- optimal line length between 45 and 75 characters, with 66 being ideal
- for line height, good rule of thumb is ~150% of X height, easily achieved by setting line height to 125% of text size
- avoid justifying text
- text in all caps can be problematic
  - can be hard for people to read
  - may be misread by screen readers

Headings

should only have 1 occurrence of h1
should be sure not to skip levels

<!-- BAD -->
<h1>Main Title</h1>
<p>This is the main description.</p>
<h2>Secondary Title</h2>
<p>This is the secondary description.</p>
<h4>Nested Title</h4>
<p>...</p>
<h2>Another Secondary Title</h2>
<p>...</p>


<!-- GOOD -->
<h1>Main Title</h1>
<p>This is the main description.</p>
<h2>Secondary Title</h2>
<p>This is the secondary description.</p>
<h3>Nested Title</h3>
<p>...</p>
<h2>Another Secondary Title</h2>
<p>...</p>

Lists

Unordered List

Use when no order of sequence or importance is needed

<ul>
    <li>Milk</li>
    <li>Bread</li>
    <li>Lettuce</li>
</ul>

Ordered List

Use when order of sequence or importance is needed

<ol>
    <li>First, do this</li>
    <li>Next, do that</li>
    <li>Lastly, do the other thing</li>
</ol>

Description List

Use when description for each item is needed or for key/value pairs

<dl>
    <dt>Milk</dt>
    <dd>Fat free organic</dd>
    <dt>Bread</dt>
    <dd>Whole wheat sourdough</dd>
</dl>

Accessible Keyboard Control

focus and active indicators
- browsers add them by default
- sometimes may be removed by developers (unintentionally or otherwise)
- inaccessible without them
tab order
- logical and easy to follow pattern
- follow visual flow of information
- left to right/right to left (depending on language)
- top to bottom
- controlled by document structure
non-navigable items
- divs or spans as buttons become completely inaccessible
skip to content link
- need to allow skipping of long navigation lists
- tabbing steps through each link and control
- should allow users to skip large chunks of navigation
  - easy way to implement is add a link before these lists with text such as "Skip to main content" with an href that has the id of the HTML element to skip to
  - if you don't like the visual aesthetics of it, you can use CSS to make it visible only when it's focused

CSS Cascade Overview

Applied in order:

default browser styles
external CSS
style sheets embedded in page
inline styles
end user custom configuration settings

End user is ultimately in control so we should build with flexibility in mind

use scalable values (em, rem, %, etc.)
don't rely on CSS alone to convey meaning
use proper, semantic HTML whenever possible

Visually Hiding Elements Only For Assistive Technologies

/* BAD */
.hidden {
    display: none;
    height: 0;
    visibility: hidden;
    width: 0;
}

.hidden {
    text-indent: -9999px;
}


/* GOOD */
.hidden {
    height: 1px;
    left: -9999px;
    position: absolute;
    overflow: hidden;
    top: auto;
    width: 1px;
}

/* MAYBE BETTER? */
.hidden {
    clip: 1px, 1px, 1px, 1px;
    position: absolute;
}

Links

if possible, use more descriptive text (instead of "read more", something like "read more of the 1st post")
if it's visually important to just have generic text in a link, can use CSS

<style>
a::after {
    content: "Read More";
}
</style>

<a href="blog-post-01.html">
    Read More of the 1st Post
</a>

Accessible Form Design

Identify Required Fields
- reduces cognitive load
- don't rely on color alone!
Add Special Formatting Requirements
- reduces cognitive load
- prevents frustration
Add Clear, Descriptive Form Labels
- all fields need a label
- don't solely use placeholder text to label fields (disappears when we type)
Provide Clear Feedback for Errors and Warnings
- don't rely on color alone
- add a message

Native vs. Custom Form Controls

Should always use native controls if possible as custom markup will often require a lot of other HTML attributes and/or JavaScript to make them accessible.

Labeling and Describing Form Controls

Use label tags with the for attribute, which should have the value of the id for the related form field.
```
<label for="firstName">First name</label>
<input id="firstName" type="text" />
```
Placeholder text should be reserved to providing more information to the user, like instructions or example values
When sensible, hidden labels are ok but must still exist in code and be available to assistive technologies
Labels must be clear and descriptive
Provide instructions when needed
Group related fields (such as using the fieldset tag)
Mark required fields

Focus and Active Indicators
- browsers add them by default (so don't remove them!)
- they must exist
- they must be unobstructed
- they need plenty of contrast
Tab Order
- ensure source order is correct
- should have a logical flow
- add tabindex for custom controls
- use native controls!
Avoid Non-standard Functionality
- don't make it awkward!

Adding Accessibility to Custom Non-standard Form Controls

WAI-ARIA

Accessible Rich Internet Applications
specification from W3C's Web Accessibility Initiative (WAI)
set of attributes for HTML to make it more accessible
Common UI patterns with custom markup and full accessibility features

Custom Select Example

<!-- BEFORE -->
<span>
    <input id="country" required hidden type="hidden" />
    <span id="exp_elem" class="account__label">
        Country <span class="account__required">*</span>
    </span>
    <div id="exp_wraper">
        <div
            tabindex="0"
            id="exp_button"
            onclick="toggleDropdown(event)">
        </div>
        <ul
            tabindex="0"
            id="exp_elem_list"
            class="hidden">
            <li id="exp_elem_au">Australia</li>
            <li id="exp_elem_br">Brazil</li>
            <li id="exp_elem_ca">Canada</li>
            <li id="exp_elem_cl">Chile</li>
            <!-- ... -->
        </ul>
    </div>
</span>

<!-- AFTER -->
<span>
    <input id="country" required hidden type="hidden" />
    <span id="exp_elem" class="account__label">
        Country <span class="account__required">*</span>
    </span>
    <div id="exp_wraper">
        <button
            tabindex="0"
            aria-labelledby="exp_elem exp_button"
            aria-haspopup="listbox"
            id="exp_button"
            onclick="toggleDropdown(event)">
        </button>
        <ul
            tabindex="0"
            role="listbox"
            aria-labelledby="exp_elem"
            id="exp_elem_list"
            class="hidden">
            <li id="exp_elem_au" role="option">Australia</li>
            <li id="exp_elem_br" role="option">Brazil</li>
            <li id="exp_elem_ca" role="option">Canada</li>
            <li id="exp_elem_cl" role="option">Chile</li>
            <!-- ... -->
        </ul>
    </div>
</span>

Creating Accessible Form Validation

Feedback for Both Success and Failure
- report if there are errors
- report successful submission too
Error Can Be Read By Assistive Technologies
- don't rely on icons and colors only
- inaccessible to those who don't see color
- inaccessible to those who can't see
Avoid Disabling the Submit Button
- the disabled button won't ever receive focus for someone using keyboard only to navigate
- better to let users submit data at any time and if error exists, set focus on first field with error
Error Messages Should be Helpful
- needs to be clear!
- consider an email field
  - "Error" is a bad error message
  - "Error: email address is invalid, example@domain.com" is much better

Adding Accessibility to Images and Media

The `alt` Attribute

short description of the content of the image
present the content and function of the image
should be succinct, a single sentence or two
should not be redundant to context of content around it
should not restate that it's an image/graphic/illustration/etc.
commonly recommended that every image has alt attribute
- in some cases, it can be empty: if content around image would make the text redundant, sometimes icons, etc.

Images Containing Content

for the most part, just add text content in image to alt text
for images applied as CSS backgrounds, use role="image" and aria-label="..."

Purely Decorative Images

for img tags, use empty alt attribute
could also apply the CSS as a background image
aria-hidden="true"

Complex Images

can't be described in a short sentence or two
charts, graphs, diagrams, illustrations, etc.
require more in-depth descriptions

if description length allows, can add detailed description inside figcaption

<figure role="group">
    <div>
        <img alt="Super Complex Thing" src="..." />
    </div>

    <figcaption>
        <h2>
            Super Complex Thing
        </h2>
        <dl>
            <dt>
                First part of complex thing
            </dt>
            <dd>...</dd>

        </dl>
    </figcaption>
</figure>

if description is sufficiently long, put description in its own page and link to page in figcaption

Video, Audio, and Accessibility

Captions
- text alternatives for time-based media (video or audio)
- help those that are hearing impaired or do not have access to sound
- closed and open captions are acceptable
- should be...
  - adjustable for size, font, and color
  - synchronized with audio
  - equivalent to spoken word
Provide Transcripts
- allow content to be read in one form or another
- provide textual version of content
- not intended to be created verbatim