OC Streetcar Final Presentation-Downtown Santa Ana
WCAG 2.1: What You Need to Know About the Most Recent Accessibility Standards
1. TODAY:
WCAG 2.1: What You Need
to Know About the Most
Recent Accessibility
Standards
Eduardo Meza-Etienne and
Kara Zirkle
User Experience Professionals
Association International
UXPA International Conference –
Scottsdale, AZ
June 25 - June 27, 2019
Learn more about UXPA
International Check out our next short courses
Suggest speakers and topics at
education@uxpa.org
2. WCAG 2.1: WHAT YOU
NEED TO KNOW ABOUT
THE MOST RECENT
ACCESSIBILITY
STANDARD
5. PEOPLE WITH DISABILITIES
CONTROL
$2 TRILLION IN INCOME
GLOBALLY
FRIENDS AND FAMILY
ADD AN ADDITIONAL
$8+ TRILLION IN ANNUAL
DISPOSABLE INCOME
6. DISABILITIES COME IN MANY FORMS
Vision
● Cataracts
● Sun glare
● Color
blind
● Low
vision
● Blind
Hearing
● Noise
● Ear
infection
● Hard of
hearing
● Deaf
Mobility
● Hands full
● Broken
arm
● Spinal
cord
injury
● Amelia
Speech
● Ambient
noise
● Speech
impediment
● Unable to
speak
Cognitive
● Sleepy
● Distraction
● Migraine
● Learning
disabilities
● Autism
● Seizure
Neural
● Depression
● PTSD
● Bipolar
● Anxiety
Situational
requirement
Temporary
impairment
Permanent
disability
7. 71% of customers with disabilities will leave your website if it
is difficult to use. These customers represent about
10% of total online spending.
Click-Away Pound Survey
9. WEB CONTENT ACCESSIBILITY GUIDELINES
• The World Wide Web Consortium (W3C) is an international community where member organizations, a full-
time staff, and the public work together to develop web standards.
• WCAG 2.0 was published in 2008, and is the most universally accepted set of web accessibility guidelines
available today. There are 12 guidelines that are organized under 4 principles. For each guideline, there are
testable success criteria, which are at three levels: A, AA and AAA.
• International standards harmonizing to WCAG 2.0 such as AODA and EN 301549
• A new update, four years in the making was published on June 5th. WCAG 2.1 does not replace version 2.0.
It’s an extension (add-on), tackling some additional accessibility barriers that aren’t addressed by 2.0 alone,
and is backwards compatible.
10. WCAG 2.0 GUIDELINES AT A GLANCE
P.O.U.R- Perceivable, Operable, Understandable and Robust
1.1 Text Alternatives: Provide text alternatives for any non-text content.
1.2 Time-based media: Provide alternatives for time-based media.
1.3 Adaptable: Create content they can be presented in different ways for example simpler layout without losing
information or structure.
1.4 Make It Easier: Ease of use to see and read your content including separating foreground and background.
2.1 Keyboard Accessible: Make off I'm sure nobody available from a keyboard.
2.2 Enough Time: Provide users enough time to read and use content.
2.3 Seizures: Do not designed content in a way that is known to cause seizures.
2.4 Navigable: Provide ways to help users navigate, find content, and determine where they are.
3.1 Readable: Make text content readable and understandable.
3.2 Predictable: Make web pages appear and operate in predictable ways.
3.3 Input Assistance: Help users avoid and correct mistakes.
4.1 Compatible: Maximize compatibility with current and future user agent including assistive technologies.
11. NEW WCAG 2.1 GUIDELINE 2.5: INPUT
MODALITIES
Make it easier for users to operate functionality through various
inputs beyond keyboard.
• 2.5.1 Pointer Gestures (A)
• 2.5.2 Pointer Cancellation (A)
• 2.5.3 Label in Name (A)
• 2.5.4 Motion Actuation (A)
12. WCAG 2.1 SUCCESS CRITERIA
Expands provision on Mobile
• Improves support for touch interactions, keyboard and mouse
• Avoids unintended activation of device sensors
Expands provisions for low vision
• Extends contrast requirements to graphics
• Improves text and layout adaptability
Expand provisions for cognitive and learning disabilities
• Enables more detailed description of page controls and elements to support personalization of user
interface
Coordinates with update of EN 301 549
• Harmonized update in progress in Europe
• Particularly for expanded mobile
13. WCAG 2.0 AND 2.1 SUCCESS CRITERIA
WCAG 2.0 (12
Guidelines)
WCAG 2.1 (1
Additional
Guideline = 13)
TOTAL WCAG
2.0 and 2.1
Success
Criteria
Level A - the most basic web
accessibility features
25 5 30
Level AA - deals with the
biggest and most common
barriers for disabled users
13 7 20
Level AAA - the highest (and
most complex) level of web
accessibility
23 5 28
Total 61 17 78
14. P.O.U.R. WEBSITES: WHAT MAKES THEM WORK?
WCAG 2.1
P.
Perceivable
O.
Operable
U.
Understandable
R.
Robust
15. PERCEIVABLE
Perceivable information and user interface.
Accessibility requirements include: providing
text alternative for images, providing
captions or transcripts for video and audio,
and providing sufficient color contrast
between text and background.
16. 16Enabling brands. Empowering people.
OPERABLE
Operable user interface and navigation.
Accessibility requirements include: enabling
navigation using only a keyboard, providing
meaningful hyperlinks, and allowing enough time for
users to complete a task.
17. UNDERSTANDABLE
Understandable information and user interface.
Accessibility requirements include: making
content readable, providing predictable
functionality, and helping users avoid and
correct mistakes.
18. ROBUST
Robust content and reliable interpretation.
Accessibility requirements include:
maximizing compatibility with current and
future tools (web browsers, assistive
technologies, etc.).
20. APPLICABLE CRITERIA BY ROLE
Designers: A web designer is both creative and technically inclined and uses both these attributes to build or redesign
websites. The web designer can understand what is needed to make a website functional and easy to use, but at the
same time make it aesthetically appealing to the user.
Content Authors: Website content writer. A website content writer or web content writer specializes in providing relevant
content for websites. Every website has a specific target audience and requires different content.
Developers: A web developer is a programmer who specializes in, or is specifically engaged in, the development of
World Wide Web applications, or applications that are run over HTTP from a web server to a web browser
Quality Assurance/Testers: QA individuals test, monitor and record results from development, processes and
procedures. Results are continually compared to predetermined expected ranges and any deviation from expected
results leads to corrective measures.
WCAG Quick Reference Guide
21. DESIGNERS
A web designer is both
creative and technically
inclined and uses both
these attributes to build or
redesign websites. The web
designer can understand
what is needed to make a
website functional and easy
to use, but at the same time
make it aesthetically
appealing to the user.
Level A Level AA Level AAA
Designers
1.1.1, 1.2.1,
1.2.2, 1.2.3,
1.3.1, 1.3.2,
1.3.3, 1.4.1,
1.4.2, 2.1.1,
2.1.2,2.1.4,
2.2.1, 2.2.2,
2.3.1, 2.4.1,
2.4.2, 2.4.3,
2.4.4,
2.5.1, 2.5.2,
2.5.3, 2.5.4,
3.1.1, 3.2.1,
3.2.2, 3.3.1,
3.3.2, 4.1.1,
4.1.2
1.2.4, 1.2.5,
1.3.4,
1.3.5,1.4.3,
1.4.4, 1.4.5,
1.4.10, 1.4.11,
1.4.12, 1.4.13,
2.4.5, 2.4.6,
2.4.7, 3.1.2,
3.2.3, 3.2.4,
3.3.3, 3.3.4,
4.1.3
1.2.6, 1.2.7, 1.2.8,
1.2.9, 1.3.6, 1.4.6,
1.4.7, 1.4.8, 1.4.9,
2.1.3, 2.2.3, 2.2.4,
2.2.5, 2.2.6, 2.3.2,
2.3.3, 2.4.8, 2.4.9,
2.4.10, 2.5.5, 2.5.6,
3.1.3, 3.1.4, 3.1.5,
3.1.6, 3.2.5, 3.3.5,
3.3.6
22. CONTENT
AUTHORS
A website content writer or
web content writer
specializes in providing
relevant content for
websites. Every website
has a specific target
audience and requires
different content.
Level A Level AA Level AAA
Content
Authors
1.1.1, 1.2.1,
1.2.2, 1.2.3,
1.3.1, 1.3.2,
1.3.3, 1.4.1,
1.4.2, 2.1.1,
2.1.2, 2.1.4,
2.2.1, 2.2.2,
2.3.1, 2.4.1,
2.4.2, 2.4.3,
2.4.4, 2.5.1,
2.5.2, 2.5.3,
2.5.4, 3.1.1,
3.2.1, 3.2.2,
3.3.1, 3.3.2,
4.1.1, 4.1.2
1.2.4, 1.2.5,
1.3.4, 1.3.5,
1.4.3, 1.4.4,
1.4.5, 1.4.10,
1.4.11, 1.4.12,
1.4.13, 2.4.5,
2.4.6, 2.4.7,
3.1.2, 3.2.3,
3.2.4, 3.3.3,
3.3.4, 4.1.3
1.2.6, 1.2.7, 1.2.8,
1.2.9, 1.3.6, 1.4.6,
1.4.7, 1.4.8, 1.4.9,
2.1.3, 2.2.3, 2.2.4,
2.2.5, 2.2.6, 2.3.2,
2.3.3,2.4.8, 2.4.9,
2.4.10, 2.5.5, 2.5.6,
3.1.3, 3.1.4, 3.1.5,
3.1.6, 3.2.5, 3.3.5,
3.3.6
23. DEVELOPERS
A web developer is a
programmer who
specializes in, or is
specifically engaged in, the
development of World Wide
Web applications, or
applications that are run
over HTTP from a web
server to a web browser
Level A Level AA Level AAA
Developers
1.1.1, 1.2.1,
1.2.2, 1.2.3,
1.3.1, 1.3.2,
1.3.3, 1.4.1,
1.4.2, 2.1.1,
2.1.2, 2.1.4,
2.2.1, 2.2.2,
2.3.1, 2.4.1,
2.4.2, 2.4.3,
2.4.4, 2.5.1,
2.5.2, 2.5.3,
2.5.4, 3.1.1,
3.2.1, 3.2.2,
3.3.1, 3.3.2,
4.1.1, 4.1.2
1.2.4, 1.2.5,
1.3.4, 1.3.5,
1.4.3, 1.4.4,
1.4.5, 1.4.10,
1.4.11, 1.4.12,
1.4.13, 2.4.5,
2.4.6, 2.4.7,
3.1.2, 3.2.3,
3.2.4, 3.3.3,
3.3.4, 4.1.3
1.2.6, 1.2.7, 1.2.8,
1.2.9, 1.3.6, 1.4.6,
1.4.7, 1.4.8, 1.4.9,
2.1.3, 2.2.3, 2.2.4,
2.2.5, 2.2.6, 2.3.2,
2.3.3, 2.4.8, 2.4.9,
2.4.10, 2.5.5, 2.5.6,
3.1.3, 3.1.4, 3.1.5,
3.1.6, 3.2.5, 3.3.5,
3.3.6
24. QUALITY
ASSURANCE
QA individuals test, monitor
and record results from
development, processes
and procedures. Results
are continually compared to
predetermined expected
ranges and any deviation
from expected results leads
to corrective measures.
Level A Level AA Level AAA
Quality
Assurance
ALL ALL ALL
25. WCAG 2.1 BREAKDOWN LEVEL A
AND AA
WCAG
Standard
Lvl Plain language summary of requirements Who does it help and how?
1.3.4
Orientation
AA
Requires authors not to rely on a screen orientation.
(With exceptions)
Users who have their device mounted, or
who cannot change orientation can still use
the site even though they have a fixed
orientation.
1.3.5 Identify
Input Purpose
AA
Ensures common names are provided using the
HTML autocomplete list.
This will enable future assistive technology to identify
them, customize them, add icons or symbols, and present
them to cognitive users in different ways.
The purpose of each input field collecting information about
the user can be programmatically determined when:
The input field serves a purpose identified in the Input
Purposes for User Interface Components section; and
The content is implemented using technologies with
support for identifying the expected meaning for form input
data.
Users with various cognitive disabilities
including people with language and memory
related disabilities, and disabilities that
affects executive function and decision
making.
Personalization and the possibility for a
familiar interface is available for users
having trouble with understanding forms.
The autocomplete function of user agents is
able to support people by the filling in
predetermined data.
26. WCAG
Standard
Lvl Plain language summary of requirements Who does it help and how?
1.4.10 Reflow AA
Basically, requires Responsive design (or a few tricks to get
zoom to work)
(With exceptions)
Users with low vision who need to make
things larger. The content will wrap inside
the viewport instead of causing horizontal
scroll.
1.4.11 Non-
Text Contrast
AA
Extends 3:1 contrast minimums to important graphical
information, visible focus indicators and other interactive
controls.
(With exceptions)
Users with low vision and cognitive
disabilities need help seeing or perceiving
information in graphics, interactive
components, and focus indicators.
1.4.12 Text
Spacing
AA
Requires author not to interfere with user style sheets and
other CSS based client-side interventions. Also, requires
enough space around text that the spacing can be spread
out a little bit.
Users with low vision or cognitive
disabilities who need to override the font,
line spacing, paragraph spacing, color
scheme etc.
1.4.13 Content
onHover or
Focus
AA
Requires hover effects like custom tooltips etc., not to
obscure the trigger that activated them, and helps users
move into the hover box without having it close on them.
Users with low vision who need to work
without hover behavior obscuring content.
WCAG 2.1 BREAKDOWN LEVEL A
AND AA
27. WCAG
Standard
Lvl Plain language summary of requirements Who does it help and how?
2.1.4 Character
key shortcuts
A
Requires authors to not use single key shortcuts or provide a
way to turn them off or change them.
Shortcut keys that have a combination of keys are much less
likely to be triggered this way.
Users of speech technology. (e.g., If the site
hijacks "p" key for shortcut, when the user
dictates words such as "happy" the shortcut
can be triggered.)
2.5.1 Pointer
gestures
A
Requires authors to ensure the user can perform touch
functions with assistive technology or one finger.
Users with dexterity disabilities, those who
are blind or have other disabilities that
interfere with the use of timed gestures, multi
finger, or complex gestures. They can use
simple pointer events.
2.5.2 Pointer
Cancellation
A
Requires authors to use up-event triggering (which is standard)
on interactive components.
(With exceptions)
Users with dexterity disabilities who miss the
target. It ensures the target is not triggered
on touch down, but rather on touch up
allowing them to move their finger away from
the wrong target if they miss.
WCAG 2.1 BREAKDOWN LEVEL A
AND AA
28. WCAG
Standard
Lvl Plain language summary of requirements Who does it help and how?
2.5.3 Label in
Name
A
Requires any visible label that is not the accessible name
to be part of the string that makes up the accessible name.
An example, speech users say "click Go" if they see a
button with the word "go" visually on it. If the button has an
aria-label="submit" then that command will do nothing, and
because the accessible name is not visible, the speech
user wouldn't know what to say to press it.
But if the word "go" was part of the string
in the ACCNAME, (i.e., aria-label="Go,
Submit" then saying "Click Go" would
activate the button.
2.5.4 Motion
Actuation
A
Will require functionality from shaking, tilting etc., also be
usable with interface components.
People who have a mounted device, or
who cannot shake or tilt a device
4.1.3 Status
Changes
AA
For HTML pages, when there is a visible status message,
this requires authors to use aria-live roles or attributes to
notify AT users when something on the page changes.
(With exceptions)
Users of AT who can't see changes or
have trouble perceiving visible status
messages on a page, such as shopping
cart updates. Their AT will announce the
status message that was visibly added to
the page.
WCAG 2.1 BREAKDOWN LEVEL A
AND AA
31. CHECKING A CURRENT APPLICATION
FOR ACCESSIBILITY
Determine the
required level of
compliance
Use the accessibility
checklist
Consult the test
methods for each
guideline
Test with real users,
in various
environments
32. DIGITAL ACCESSIBILITY TESTING
Automated, technical and functional tests should be completed on the user interface of the
selected web pages or mobile apps to identify barriers faced by individuals with disabilities as
per WCAG 2.0 Level A, and AA, to inform key recommendations and fixes.
Accessibility
Testing
Methodology
Online
Evaluation
Tools
Accessibility
Toolbars
Assistive
Technology
Testing
Manual
Review
33. SAMPLE TEST SCOPE
Determine
customer workflows
Determine
employee
workflows
Determine highest
used sites
Ensure any
accessibility
specific pages are
included
Prioritize Errors
34. SAMPLE TEST PLAN
Ensure you’re
testing to the most
accurate
environments for all
users.
• Check Google
Analytics
• Cross reference
against WebAIM
Screen Reader
Survey
Cross Check
the accessibility
features with
HTML5
Browser
Accessibility to
ensure all
features are
supported.
Keyboard
Accessibility
Check
Code Validation
Check
Automated
Accessibility
Tool Check
User Stories for
Manual and
Functional Testing
• Web Stories with
Individuals with
Disabilities
• Easy Check, First
Review of
Accessibility
35. ASK YOURSELF THE QUESTIONS
Why is the screen
reader reading the
sidebar before the
main article?
Do I have to tab
through every
page and every
navigation before
getting to the
content? (Why
isn’t there a skip
to content link?)
What does image
IMG_238429.jpg
mean?
What did I miss
on the page?
39. USE CODE VALIDATION TOOLS
Procedure
Open the browser and navigate
to the specified URL
For each state of the system,
validate the HTML markup
Expected Results
All of the HTML markup should
properly validate in all states.
Stop Test
Refresh the browser to return
the page to its initial state
Quit the tool you are using to
validate
41. USE AUTOMATED ACCESSIBILITY
TOOLS
Procedure
Open the browser and navigate
to the specified URL
For each state of the system,
ensure that the WCAG
guidelines are being met to at
least AA level
Expected Results
Passes WCAG 2.0 AA
requirements
Limited Expectations –
Automated tools check for 30-
40%
Stop Test
Refresh the browser to return
the page to its initial state
Quit the tool you are using to
validate
43. DEVELOP
ACCESSIBILITY-
RELATED USER
STORIES:
• As keyboard-only user, I want the ability to reach all links
(text or image), form controls and page functions, so that
I can perform an action or navigate to the place I choose.
• As a screen reader user, I want to hear the text equivalent
for each image conveying information so that I don’t miss
any information on the page.
• As a user who has trouble reading due to low vision, I
want to be able to make the text larger on the screen so
that I can read it.
• As a user who is color blind, I want to have access to
information conveyed in color so that I do not miss
anything and I understand the content.
• As a user who is hearing-impaired, I want closed
captioning functionality so that I can have access to all
information provided in video clips.
45. KEYBOARD ACCESSIBILITY
Step 1: Keyboard Focus Images
• Procedure
• Open the browser and navigate to the
specified URL
• Using the keyboard, tap the 'tab' key until one of
the images has focus
• Expected Results
• The styling of the element should change to indicate
that the image has focus
Step 2: Navigate Images
• Procedure
• Complete Test 1
• Using the keyboard, tap the 'left' or 'right' arrow or tab
key
• Expected Results
• The keyboard focus styling should move to the other
element
Step 3: Select an Image
• Procedure
• Complete Test 2
• Using the keyboard, tap the 'enter' key
• Expected Results
• The select image should be shown in the viewer
46. KEYBOARD NAVIGATION
Step 4: Navigation Focus
• Procedure
• Complete Test 3
• Using the keyboard, tap the 'tab' key to ensure
all navigation has focus
• Expected Results
• The styling of the element should change to
indicate that it has focus
Step 5: Navigation Order
• Procedure
• Complete Test 4
• Using the keyboard, tap the 'left' or 'right' arrow or
tab key
• Expected Results
• The keyboard focus styling should move in the
appropriate reading order for all elements
Step 6: Select Navigation
• Procedure
• Complete Test 5
• Using the keyboard, tap the 'enter' key
• Expected Results
• The starts should highlight to the selected
navigation and can select sub navigation, fly out
or pop up navigation.
47. USE ASSISTIVE TECHNOLOGY
Procedure
Open the browser and navigate to the specified URL
Using the above state tests (Test 1 - 6) as a guide, attempt to navigate through each
state of the system
Examples of assistive technologies
• Screen Readers: JAWS, NVDA, VoiceOver, Orca
• Built in AT features: Windows, Mac, Linux, iOS, Android
• Others ATs: Speech Recognition, Screen Magnifiers, switch access, etc.
Expected Results
All states of the system should be reachable and usable while using the AT
48. SCREEN READER EXAMPLE
Links
• Use the Tab key to jump from link to link
• Links should make sense when read out of context
• Distinguishing information should be at the start of the link
• Skip navigation speeds up the reading process
‒ Helps users distinguish between the main navigation and the main content.
Headings
• Navigate from heading to heading. Users hear an outline of the page's main ideas
• Without headings, this method of skimming through content is completely useless
Landmarks and page sections
• Users can navigate via ARIA landmarks and HTML5 sectioning elements, such as <main>, <nav>,
<header>, etc.
• Define appropriate ARIA landmarks and use HTML5 elements appropriately
Paragraphs and page elements
• Users can jump from paragraph to paragraph or from element to element, such as <div> tags, links, form
elements, list items, or other units of content.
49. ANDROID
TESTING
4 ways of checking accessibility in Android
1. Use the built in accessibility features
in Android
2. Use Android Accessibility Scanner
Simulation
3. UI Automator Viewer
4. Automated tools
50. IOS TESTING
4 ways of checking accessibility in iOS
1. Use the built in accessibility features
of the iOS platform
2. Use Mac Xcode simulation
• Google Toolbox for Accessibility iOS
is an open source test automation
framework
3. iOS Simulator Accessibility Inspector
tool
4. Automated accessibility tools
51. PRIORITIZATION LEVELS
Priority Description
Critical
This issue results in blocked content for individuals with disabilities. Until a solution is implemented
content will be completely inaccessible, making your organization highly vulnerable to legal
action. Remediation should be a top priority.
High
This issue results in serious barriers for individuals with disabilities. Until a solution is implemented
some content will be inaccessible, making your organization vulnerable to legal action. Users relying on
Assistive Technology will experience significant frustration when attempting to access content.
Remediation should be a priority.
Medium
This issue results in some barriers for individuals with disabilities but would not prevent them from
accessing fundamental elements or content. This might make your organization vulnerable to legal
action. This issue must be resolved before a page can be considered fully compliant.
Low
This is considered an Accessibility issue that yields less impact for users than a medium issue. For a
page to be considered fully compliant this issue must be resolved but can be dealt with last.
52. ACCESSIBILITY ISSUES
Critical
• 1.3.3 Sensory Characteristics
• 1.4.4 Resize Text
• 2.1.1 Keyboard
• 2.1.2 Keyboard Trap
• 2.2.1 Timing Adjustable
• 3.2.2 On Input
• 3.3.3 Error Suggestions
• 3.3.4 Error Prevention
• 4.1.2 Name, Role, Value
High
• 1.1.1 Non-text Content
• 1.2.1 Audio-only and Video-only
(Prerecorded)
• 1.2.2 Captions (Prerecorded)
• 1.2.3 Audio Description or Media
Alternative (Prerecorded)
• 1.2.4 Captions (live)
• 1.2.5 Audio Description
(Prerecorded)
• 1.3.1 Info and Relationships
• 1.3.2 Meaningful Sequence
• 1.4.1 Use of Color
• 1.4.2 Audio Control
• 1.4.5 Images of Text
• 2.2.2 Pause, Stop, Hide
• 2.4.3 Focus Order
• 2.4.4 Link Purpose
• 2.4.7 Focus Visible
• 3.1.1 Language of Page
• 3.2.1 On Focus
• 3.2.3 Consistent Navigation
• 3.3.1 Error Identification
• 3.3.2 Labels of Instructions
• 4.1.1 Parsing