Basic Accessibility & Testing

Web Design Considerations, by Disability Types

Presented by Htet Htet Aung

~ 1 in 5 (20%) has a disability of some kind
• Recognizable Disabilities
• Blindness
• Paralysis
• Missing limbs
• Hidden Disabilities
• Deafness
• Reading disorder
• Seizure prone
• Temporary Disabilities
• Injury or surgery related limitation on mobility
• Age-Related Disabilities
• Loss of hearing, sight, mobility, cognition
“ For people without disabilities, technology
makes things convenient, whereas for people
with disabilities, it makes things possible. ”

Judy Hueman
Accessibility Improves People's Lives
• Accessible designs make life easier for
people with disabilities
• Or, in some cases, it's even more dramatic:
accessibility makes things possible that
would be otherwise literally impossible. In
this sense, accessibility isn't just nice to
have, it's necessary
Accessible websites/apps let people
• Do their jobs
• Conduct their personal banking
• Make restaurant reservations
• Access government benefits
• Apply for college
• Shop online
• Read the news
• Play online games... and anything
else that is available on the web
Different types of disabilities
needs different types of
design and code
Perceptual/Motor

• Low-Vision
• Color-Blindness
• Deaf/Deaf-Blindness
• Blindness
• Physical or Motor Disabilities
Other

• Autism/ADD
• Anxiety
• Dyslexia/Reading Disabilities
• Seizure Disorders
Digital accessibility
What is Digital Accessibility?
• Development of systems and applications
flexible enough to accommodate the needs of
the broadest range of users... regardless of
age or disability ...so that everyone can have
the same user experience when they access
these types of digital components

• Encourages good design and development

practices

• Supports
• Search engine optimization
• Internationalization
• Mobile-friendly content
• Estimated 10-20% of the World’s population
has a disability

• Accessibility benefits everyone!

Four Measures
Criteria for Digital Accessibility
Inclusive Design
Disabilities are not binary
• It's helpful to think of disabilities on a spectrum, rather than as simple binary
characteristics that a person either has 100% or is missing 100%. There is far
more variation than that. In fact, we can extend the concept of disability to
include temporary and situational limitations.

• Permanent: A defining characteristic of the person's body.

• Temporary: An injury, sickness, or short-term impairment.
• Situational: A condition or context that limits a person's ability.
Mobility/Touch Ability Spectrum
Variations among those with permanent
mobility disabilities: Permanent Temporary Situational

• A person with an arm, but no hand, or

a partial hand

• A person with constant tremors

• A person with occasional tremors
• A person with full paralysis of the limbs
• A person with partial paralysis, with A person who cannot use
their hands
A person with an arm
injury
A new parent holding a
child in one arm
some mobility, but limited dexterity or
precision
Visibility Ability Spectrum
Variations among those with permanent
visibility disabilities: Permanent Temporary Situational

• People who are "legally blind" with

some residual vision

• People with low vision who require

magnification

• People with reduced contrast vision

• People with varying degrees of color- A person who is blind A person with dilated A person who is driving
blindness eyes from an eye exam who should not look at a
computer device

• People who are sensitive to bright light

Auditory Ability Spectrum
Variations among those with
permanent auditory disabilities: Permanent Temporary Situational

• Hard-of-hearing
• Loss of hearing in the high
frequency range

A person who is hard of A person with an ear A person at a rock

hearing infection concert
Speech Ability Spectrum
Variations among those with
permanent speech disabilities: Permanent Temporary Situational

• A person with cerebral palsy whose

speech sounds slurred

• A person who has undergone throat

cancer surgery whose voice now
sounds harsh

• A person who stutters A person who is non- A person sick with A person in a quiet room
verbal laryngitis in a library
 SIMON Low Vision

COMMON INTERACTIONS

- Financial software

- Financial, government tax law, and tax prep websites

- Social media

- Online shopping

DEMOGRAPHICS WANTS AND NEEDS

- Accountant - Bigger fonts and images

- Uses both mouse and - Content is not lost when zoomed in highly

-
keyboard to navigate
Uses software that
- High contrast to make reading easier on the eyes

enlarges the view on

computer screen
Screen Magnification
Zoom in on a section of the screen using ZoomText or MAGic
• Experience what is it
like to use ZoomText:
https://
www.youtube.com/
watch?v=ojtiVj78QPw

• ZoomText and MAGic

have basic screen
readers built into
them

• Place popups, alerts,

error messages, and
other similar
messages near the
visual focus, to make
sure users don't miss
them.
 RANDALL Color-Blindness

COMMON INTERACTIONS

- Coding software

- Collaboration tools like Slack, Teams

- Forums

- Game maps and navigation

DEMOGRAPHICS WANTS AND NEEDS

- Engineer - Clear differentiated colored code elements

- Loves to play video

games
- Needs to know when there’s a new chat message, when someone’s online vs.
offline

- Identify important game elements and read game maps

Types of Color-Blindness
• Red-Green
• Deuteranopia
• Protanopia
• Blue-Yellow
• Tritanopia Red and Green Colors Red/Green Color Blindness All Colors

• All colors (Gray)

• Achromatopsia
• Red-Black
Red and Black Colors Red and Black Color-Blindness
Simulation
Color Contrast
Use good color contrasts and readable font size
Designing for users with
low vision !
Do… Don’t…
• Common • Pass
• Sense • Pass use good colour
contrasts and a
readable font size
Aa use low colour
contrasts and small
font size
Aa

• Is • Pass
• Vital • Pass
publish all information
on web pages
! HTML
bury information
in downloads
!
• When • Fail use a combination
Start !
only use colour to
of colour, shapes convey meaning
and text

• Considering • Fail 200% magnification 200% magnification

• Color • Fail
! !
follow a linear, spread content
logical layout all over a page

• Contrast • Fail
put buttons and separate actions Submit
notifications in from their context
You can use the contrast checker to check both text and graphical objects contrast. context Submit

https://webaim.org/resources/contrastchecker/
This work is licensed under the Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International License. To view a copy of
For more information, contact:
Digital, Data and Technology this license, visit http://creativecommons.org/licenses/by-nc-sa/4.0/. access@digital.homeoffice.gov.uk
Color Contrast
Text with almost exactly 4.5:1 contrast
Using Color
Do not use color only to convey meaning
Designing for users with
low vision !
Do… Don’t…
The green mushrooms are OK to eat.
The red mushrooms will kill you. use good colour
contrasts and a
readable font size
Aa use low colour
contrasts and small
font size
Aa

publish all information

on web pages
! HTML
bury information
in downloads
!
use a combination only use colour to
of colour, shapes Start ! convey meaning
and text

The mushrooms with checks are OK to eat. 200% magnification 200% magnification

! !
follow a linear, spread content
The mushrooms without checks will kill you. logical layout all over a page

put buttons and separate actions Submit

notifications in from their context
context Submit

This work is licensed under the Creative Commons Attribution- For more information, contact:
NonCommercial-ShareAlike 4.0 International License. To view a copy of
Digital, Data and Technology this license, visit http://creativecommons.org/licenses/by-nc-sa/4.0/. access@digital.homeoffice.gov.uk
 Color Only Color + Icon

Color Only (Normal)

Color Only (Color Blind)

Color + Icon (Color Blind)

Layout
Designing for users with
low vision !
Follow a linear logical layout
Do… Don’t…
• Principle of Proximity
• Group related items together to show the relationship between
them
use good colour
contrasts and a
readable font size
Aa use low colour
contrasts and small
font size
Aa

• People with low vision will start at top left of the page and orient
themselves and move through rest of the content of the page.
• STRAW test/Zoom 200-400%
publish all information
on web pages
! HTML
bury information
in downloads
!
use a combination only use colour to
of colour, shapes Start ! convey meaning
and text

200% magnification 200% magnification

! !
follow a linear, spread content
logical layout all over a page

put buttons and separate actions Submit

notifications in from their context
context Submit

This work is licensed under the Creative Commons Attribution- For more information, contact:
NonCommercial-ShareAlike 4.0 International License. To view a copy of
Digital, Data and Technology this license, visit http://creativecommons.org/licenses/by-nc-sa/4.0/. access@digital.homeoffice.gov.uk
 ANGIE Deaf

COMMON INTERACTIONS

- Typical business and medical billing/coding software and internet searches

- Online chat tools

- Social media

- Online shopping

DEMOGRAPHICS WANTS AND NEEDS

-
-
Medical Coder
- Audio or video with captions and transcription
Have work colleagues talk to Siri
on her smartphone to type out - Simple and concise language, short sentences

-
what they say so she can read it
Relies on sign language - Clear start/stop/pause UI
interpreter when attending
meetings or watching public
speaking
- Avoid jargon and idioms as English is a second language for deaf people
 Designing for users who are
Make sure users know what's
on the page
D/deaf or
hard of hearing
!
Do… Don’t…
• Make the content and functionality available
through sight, sound, and touch write in
Do this.
use complicated
words or figures

!
plain language
of speech

• Make Images, Videos, Audios perceivable

• Be sure to provide adequate description for
informational and functional images
use subtitles
or provide
transcripts for
videos !
CC
put content in
audio or video
only !
! !
make complex

• Provide synchronized captions for the deaf

use a linear, layouts and
logical layout menus

• Provide synchronized audio descriptions for the

blind
break up content
with sub-headings,
images and videos
make users
read long blocks
of content !!
• Provide a text transcript for those who are both
deaf and/or blind
let users ask for their
preferred communi-
cation support when
booking appointments
!
make telephone
the only means of
contact for users
!!
This work is licensed under the Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International License. To view a copy of
For more information, contact:
Digital, Data and Technology this license, visit http://creativecommons.org/licenses/by-nc-sa/4.0/. access@digital.homeoffice.gov.uk
 BOBBY Motor Disabilities

COMMON INTERACTIONS

- Reading and learning from online course content

- Podcasts and videos

- Social media

DEMOGRAPHICS WANTS AND NEEDS

- Student - Keyboard accessible websites and apps

- Uses joystick in lieu - No keyboard traps

of keyboard and
mouse - Easy to use apps

- No time limits
Physicist Stephen Hawking
Degenerative Neuromuscular Disease ALS (Amyotrophic Lateral Sclerosis)

• Stephen Hawking used a computer to help him speak, write, and interact
with the world. He had a sensor hooked up to his glasses that detected
movements in his cheek.

• As he looked at the computer screen, options were displayed on the

screen, and he was able to select from among the options and type his
words on the computer. He then had the computer read his words out
loud.

• TED talk: https://www.ted.com/talks/

stephen_hawking_questioning_the_universe?language=en

All my life I have sought to understand the universe and find answers [...] I
have been very lucky that my disability has not been a serious handicap.
Indeed, it has probably given me more time than most people to pursue the
quest for knowledge."
Everything has to work
• The goal of operability is to ensure that web components work.
• All features—particularly navigation and dynamic or interactive components—must be
functional, no matter what input device a person is using

• An accessible web app must work with all of the input devices:
• Mouse or touchpad
• Keyboard
• Touchscreen
• `Voice recognition software
• Other specialized input devices (most of which emulate the keyboard or mouse)
 Designing for users with

Keyboard only access physical or motor

disabilities
Design for keyboard or speech only use
Do… Don’t…

• When you make things accessible with a keyboard, make large Yes demand No
you make it work for everyone clickable actions precision

• Make sure it is always visibly apparent which element

has focus give form
fields space
bunch
interactions !
together

• Don’t remove focus indicators

• Avoid using apps, plugins, widgets, or JavaScript design for
keyboard or Tab make dynamic
content that
1
2 2a
techniques that trap the keyboard speech only ! requires a lot of 3 2b
use mouse movement
2c !
• Users should be able to get into and out of any
!
design with
user interface element mobile and
touchscreen
in mind
! have short
time out
windows
! Your session
has timed out

• Provide links that are visible (when tabbing through

using keyboard) that let users skip to the areas they provide
Postcode tire users
with lots of
Address

need to go easily shortcuts

Find address
typing and
scrolling

This work is licensed under the Creative Commons Attribution-

NonCommercial-ShareAlike 4.0 International License. To view a copy of
For more information, contact:
Digital, Data and Technology this license, visit http://creativecommons.org/licenses/by-nc-sa/4.0/. access@digital.homeoffice.gov.uk
Allow user to skip over repetitive and/or lengthy lists of links
Effective Visual Focus

• Plan your focus states

• Reuse :hover state for :focus
• Use text-decoration: underline
for links

• Use background color changes

to indicate focus

• Test with keyboard only

Provide Accessible Time Limits
• Allow users to do one or more of the following:
• Turn off
• The user is allowed to turn off the time limit before
encountering it

• Adjust
• The user is allowed to adjust the time limit before
encountering it over a wide range that is at least ten times
the length of the default setting

• Extend
• The user is warned before time expires and given at least
20 seconds to extend the time limit with a simple action
(for example, “press the space bar”), and the user is
allowed to extend the time limit at least ten times
 MARY Legally Blind

COMMON INTERACTIONS

- Scheduling clients, taking notes

- Reading digitized copies of therapy notes and online research papers

- Navigating various websites and social media

- Online shopping

DEMOGRAPHICS WANTS AND NEEDS

- Counselor/Therapist - Sites that are easy to navigate (have landmarks)

- Uses keyboard short - Content that is scannable and understandable via screen reader

-
cuts
Likes navigating by
- To skip around repetitive lists (like menu)

headings, landmarks,
and links.
Screen Readers
Convert text on into spoken words

• Listening is reading
• Experience what is
it like to use a
screen reader:
https://
www.youtube.com/
watch?
v=qL4shFJHOvc

• Note: Experienced
screen readers
often turn up the
speed on their
screen readers
 Designing for users of
Make Dynamic Content Perceivable screen readers ! !

• Blind users won't know when content or state changes Do… Don’t…
on the page unless the system lets them know

• You can use ARIA ("Accessible Rich Internet describe images

<alt>
only show
and provide information in an
Applications") to announce when a tab is transcripts
for video
image or video

"expanded" or "collapsed"

• You can use an ARIA live region to announce new

content as it is inserted into the DOM (Document
Object Model)
follow a linear,
logical layout

! spread content
all over a page

!
structure content
<h1> rely on text size 36pt, bold
<nav> and placement

• If new content is injected into a page—such as an error using HTML5

<label>
for structure Header
message or a confirmation message—blind users need
to hear this new information

• ARIA live regions can be used for this purpose, or

build for keyboard
use only
! force mouse or
screen use
!
you can move the browser's focus to those areas to
force screen readers to read them write descriptive
links and headings Contact us
write uninformative
links and headings Click here

This work is licensed under the Creative Commons Attribution- For more information, contact:
NonCommercial-ShareAlike 4.0 International License. To view a copy of
Digital, Data and Technology this license, visit http://creativecommons.org/licenses/by-nc-sa/4.0/. access@digital.homeoffice.gov.uk
 MAUREEN Cognitive Disabilities

COMMON INTERACTIONS

- Reading and studying online course materials

- Looking up words she does not understand

- Browse websites to do research for her homework

DEMOGRAPHICS WANTS AND NEEDS

- Highschool Student - Information that is easy to read and understand

- Needs extra support

for learning
- Focus on text and not be distracted

- Complex language
can sometimes be a
challenge in reading
 Designing for users on the
Autism autistic spectrum

• Consistent Navigation and Layout across the Do… Don’t…

system
use simple use bright

• Same or similar actions on similar UI

colours contrasting colours

components should produce similar results

Do this.
write in use figures of
plain language speech and idioms

• Reduce clutter and distractions !

• Simple, plain text. Identify non-standard use simple
sentences and
! create a wall
of text
!!
terms as well as abbreviations and acronyms
bullets

• Avoid time limits, and automatic refreshes

make buttons
make buttons vague and Click here!
descriptive Attach files
unpredictable

• Clear instructions and error messages when

filling out forms build simple and
consistent layouts
! build complex and
cluttered layouts

This work is licensed under the Creative Commons Attribution-

!
For more information, contact:
NonCommercial-ShareAlike 4.0 International License. To view a copy of
Digital, Data and Technology this license, visit http://creativecommons.org/licenses/by-nc-sa/4.0/. access@digital.homeoffice.gov.uk
Attention Deficit Disorder
Stressed, Distracted, Using app while on the move

• Common Interactions
• A need to focus on most important thing
• Needs
• Distraction Free Layout
• Avoid animations and auto updating content
• Give the user control over what they can show or not
• Findability
• Consistent navigation
• Relevant Autosuggestion when searching help
• Clear Instructions and Error Handling
• To avoid time limitations
 Designing for users with
Anxiety anxiety
Do… Don’t…
• Timing is everything. Make sure your timing
is long enough to allow users to complete an give users enough
time to complete
rush users or set
impractical time

action an action limits

• Explain what will happen after a user does

explain what We have sent
leave users
will happen after you an email confusd about
completing a next steps or

something service timeframes

1 2
leave users

• Clearly show what is important make important

information clear
uncertain about
the consequences
of their actions
3 4

• Allow users to check their answers and be give users the

support they
make support

sure they are correct before submitting them need to complete

a service
or help hard
to access

let users check

their answers leave users ?
? ?
?
before they questioning what
submit them answers they gave ? ?

This work is licensed under the Creative Commons Attribution-

NonCommercial-ShareAlike 4.0 International License. To view a copy of
For more information, contact:
Digital, Data and Technology this license, visit http://creativecommons.org/licenses/by-nc-sa/4.0/. access@digital.homeoffice.gov.uk
 dA i
i
yyLS
dA
Designing for users with
Dyslexia dyslexia X Lee
• Images and diagrams may come in handy here to Do… Don’t…
support text

!
use images use large

• Text should be in a consistent layout and left aligned

and diagrams
to support text
blocks of
heavy text !!
• Other formats may be used (audio) align text to the
left and keep a
underline words,
use italics or
DON’T
consistent write in capitals DO THIS
• Make sure the page reads well in a screen browser
layout

such as Chrome/Vox consider producing force users to remember

!
!
• Avoid placing text in images that can’t easily be read
materials in other
formats (for example,
audio or video) ! things from previous
pages - give reminders
and prompts

• Short and clear content

rely on accurate dyslexia !
keep content
spelling,
short simple,
make clears
don't provide
autocorrect
dsyle
prompts

• Allow users to change the contrast between

background and text let users change

! !
put too much
the contrast be- information in
tween background one place
and text

This work is licensed under the Creative Commons Attribution-

NonCommercial-ShareAlike 4.0 International License. To view a copy of
For more information, contact:
Digital, Data and Technology this license, visit http://creativecommons.org/licenses/by-nc-sa/4.0/. access@digital.homeoffice.gov.uk
Seizure Disorder
Avoid flashing/strobing content

• Animations may cause vertigo, dizziness, nausea, or Guidance

pain for some people

• Parallax effect may cause headaches • Allow users the choice to turn
animations off
• Flashing content can trigger seizure
• Make sure your site or app doesn’t
• More than 3 times in any one-second period rely on animation

• To understand more, refer to sateach.es/vestibular • Dissolve effect is better than sliding

effect
• Tools
• W3C guidelines for general flash and red
thresholds

• Photosensitive Epilepsy Analysis Tool (PEAT)

Meeting Accessibility Guidelines
Accessibility Improves Public Perception
• Improves Public Perception
• If you have an accessible website/app, it shows that you—and the organization
you work for—are committed to basic ideals of equal opportunity and fairness

• You can leverage your accessible website/app as a differentiator among your

competitors or peers who may have less accessible web sites

• You show that you CARE

• Increases Compatibility
• Improves Search Engine Optimization
• Increases Your Eligibility for Funding
Accessibility Helps You
Avoid Lawsuits
• In many areas of the world, creating
inaccessible web sites is against the
law

• The legal picture isn't always

straightforward, but people with
disabilities have rights, and they might
decide to sue your company if the
website is not accessible

• That's bad press, a huge expense, and

it's totally avoidable if you create an
accessible website in the first place.

• Accessibility keeps you out of court!

Meeting Accessibility guidelines

• Section 508 of the Rehabilitation Act

• Requires the U.S. federal government to take accessibility into account when
procuring information technologies: websites, telephones, copiers, computers,
and other technologies, including both hardware and software

• WCAG level A and AA guidelines are incorporated by reference and required by

Section 508

• The Americans with Disabilities Act (ADA) applies to:

• Businesses and other organizations open to the public, with the exception of
religious entities and private clubs

• Federal and state government entities

Some Accessibility issues are objective

• Automated testing or special tools can help us determine some accessibility

issues

• We can determine:
• If inputs have associated labels
• If images have alt text defined
• If the color contrast is enough for the font-size
• If the code is well-formed
Most Accessibility issues are Subjective

• Is there an understandable document hierarchy with titles and sections correctly

labeled and identified?

• Do the labels for inputs accurately describe the inputs they are associated with?
• Do informational images have alt text that realistically describe the images?
• Do the link texts make sense? Will the user know where the links will lead them?
• Can a user navigate a page using only their keyboard in a consistent and
understandable manner?

• Can a user navigate the site without getting lost?

 Your application can be
compliant yet
inaccessible
Accessibility > Compliance

Image of 3 women 3 laughing women in a field of

sunflowers. The woman on the
left has sun glasses on and
looking to the left. The woman
in the middle is looking directly
at the viewer. The woman on
the right is looking up with her
eyes closed.
Design for Extremes
Testing
A Basic Testing Routine
• The whole point of web accessibility testing is to find issues or barriers that users
with disabilities might run into while they surf the web.

• The discoveries testers make should provide developers and designers with
recommendations, so improvements can be made to the overall user experience
of the product, application, or web site.

• Develop or adopt a web accessibility testing method to ensure consistency in the

testing process and to produce consistent results.

• Here’s the start of basic testing routine:

1. Determine the Scope for Testing
Determine how many pages will be evaluated, selecting representative pages,
choosing which conformance level to evaluate against, etc.
Determine the Scope of the Test
• Questions to answer before the test
• Are a few pages going to be evaluated, or an entire web application?
• Will the evaluation stick to informational content or will it also cover transactional processes?
• Which pages are going to be evaluated?
• How can the best pages be selected to get the most out of the evaluation process?
• The main goal here is to select a sample of pages that will be significantly representative of
the entire site or application.

• Usually, all of the pages on the website do not have to be tested as long as the pages selected
are representative of the entire site. However, how big the sample needs to be will vary from
just a few to several dozens or hundreds, depending on the size of the website and the budget.
Scope in order of priority
Weigh and prioritize based on frequency/criticality of use

• Templates - Anything that occurs across the entire site

• Navigational Menus - Anything used to navigate
• Forms - Anything used to accept payment or to commit the user (or organization) to a legal contract
• Anything used during primary interaction with the site.
• Anything typically found to cause accessibility problems: Images, Forms, Tables, Frames, Interface
Elements relying on client-side scripting, and Media.

• Anything typically used by persons with disabilities, such as site maps.

• Anything necessary for contacting the organization, such as contact forms and staff directories.
• Anything that gets a lot of traffic, such as the Home page or any of the pages that receive the top 80%
of traffic.
2. Conduct Tests
• Automated Tests: Use a specific tool or tools to find issues that can be found automatically and report those as a
foundation for the work to come in the manual testing phase.

• Manual Tests: Following the suggested methodologies in this section, go through a series of tests using different
tools to find issues in the page or application that is being tested. The recommended routine for manual testing is:

1. Input: Keyboard

2. Input: Touch

3. Visual Presentation

4. Alternative Text

5. Audio and Video

6. Semantics and Document Structure

7. Forms

8. Dynamic Content

9. Custom Widgets
Document, Remediate, and Regression Testing
3. Document All Findings in an Accessibility Report Format
Bring all the findings together into a comprehensive and usable format that
allows stakeholders to remediate the issues found based on
recommendations provided.

4. Plan for Remediation

Use testing results to prioritize issues to remediate based on things like
business value, risk, severity, etc.

5. Conduct Regression Testing

Re-run previously run tests to check whether program behavior has changed
and whether previously fixed faults have re-emerged.
Template for Accessibility Bug Report
Template Component Description of Component

Descriptive Title Provide a descriptive title that identifies the accessibility issue

Issue Description Provide a detailed description of the issue

Detail the expected behavior, what a user expects to happen upon interaction with
Expected Results
content

Platform and AT Identify the platform and any assistive technology used in discovering the issue

Identify the level of impact (e.g., Critical, Serious, Moderate, Minor); Often used to
Impact/Severity
prioritize and triage fixes
Include specifics needed to reproduce the issue, including step-by-step instructions and
Steps to Reproduce
credentials that should be used to reproduce the issue
Provide a screenshot with visual indicators, video recording of the accessibility issue, or
Visual or Video
even a code snippet of where the issue occurs

Remediation Whenever possible, try to include recommendations for fixing the issue
Bad Bug Report
Descriptive Title Visual Focus Indicator
The visual focus indicator disappears
Issue Description
when tabbing through the web page.
The visual focus indicator should always
Expected Results
be visible.
Platform and AT
Impact/Severity
Steps to Go to MarsCommuter and tab through
Reproduce the web page.
Visual or Video
Make sure visual focus indicator can be
Remediation
seen as users tab through the web
page.
Good Bug Report
Descriptive Title Visual focus indicator disappears in the Booking widget
When a user tabs through the Booking widget on MarsCommuter home
Issue Description page, the visual focus indicator is lost after tabbing through the
Departure Dates form fields.
When a sighted keyboard user tabs through the widget, the user should
Expected Results
be able to see where the keyboard focus is within the widget at all times.
Platform and AT
Impact/Severity Critical (Prevents sighted keyboard users from interacting with web page)
1. Go to the MarsCommuter home page.
2. Place keyboard focus in the From field in the Booking widget.
Steps to Reproduce 3. Tab through the rest of the fields.
4. Visual focus disappears after the form field where users select the
time.
Screenshot of where the visual focus indicator is last seen in the Booking
Visual or Video
widget on MarsCommuter
Check that the CSS outline property is not disabled through outline:
none; or outline: 0; after users tab from the Departure Dates fields. Visual
Remediation
focus indicator must follow the keyboard focus throughout the widget
and the web page.
Testing Tips
• WAVE or Axe DevTools is a good first step but be aware it won’t catch everything.
• Look at your HTML without CSS styling. Does it still make sense?
• Can you identify relationships and importance of items without any other styling or markup?
• Test with your keyboard
• Pretend you lost your mouse and can only use your keyboard. (But you still have your eyes)
• Tab through your finished work, use the arrow and enter keys to make sure all your form
fields and buttons/links work.

• Can you get to everything you need to easily with just the keyboard (remember you can still
use your eyes.)

• How frustrating is it to have to move back and forth with the keyboard only?
Testing Tools

• Color Contrast Checker

• Color-reliant Link Contrast Checker
• CommonLook PDF Plug-in for Acrobat
• WAVE
• Axe DevTools
• Axe Auditor
Resources
• How to meet WCAG (Quick Reference)
• WAI-ARIA Overview
• Aria Authoring Practices Guide
• Keyboard Accessibility
• Designing for Users with Disabilities
• W3C Before and After demonstration
Accessibility in Practice
Accessibility is a Commitment Requiring Team Effort

• Create a culture of accessibility from top to bottom

An organizational commitment can ensure that accessibility isn’t done only
when it is convenient

• Share responsibility, authority, and accountability

Team members should work together - PO, design, development, QA

• Evaluate against standards as part of regular QA

Not only design to be inclusive but incorporate testing for accessibility as part
of your dev/QA process

• Have inclusive usability testing

Include people with disabilities in user research and usability evaluation
Integrated Practice
• Code to standards: Follow coding standards and best practices.
• Make interactive elements universally usable: Take an inventory of how many
different types of forms, interactive features, and dynamic elements and
determine how to make them accessible.

• Make multimedia accessible: Have a plan for the media creators to have plans
in place to include captions and transcripts for each video, audio, or animated
media.

• Provide a Style Guide: This will ensure consistency by documenting decisions

and examples of how design, content, and code elements are used.

• Include people with disabilities: Include them user research, testing, personas,
and scenarios.
Assistive Technology
Screen Readers
• MacOS VoiceOver • For others, see American Foundation for
the Blind: Screen Readers
• Apple > System Preferences >
Accessibility > Check Enable • 3 basic modes
VoiceOver (or in future use keyboard
Command + F5) • Say everything: top to bottom of page
• Windows • Traditional keyboard nav, tab and
arrow
• NVDA (Free) or JAWS
• Filtered movement: uses hotkeys
• Microsoft Narrator (press F to go from form to form) —
links list, forms list, buttons list
• Linux/Unix
• Screen reader short cuts: https://
• BRLTTY dequeuniversity.com/screenreaders/
Screen Magnifiers

• Low vision (macular degeneration, glaucoma, cataract)

• Can only see small portion of the screen
• Split screen mode helps navigate the page while a portion is being
magnified ! May be in picture in picture mode

• Disorienting to use screen with magnifier

• Font size increase may be as large as 10 times the normal
Voice Recognition Software

• Hands-free operation of computing device

• Dragon - most common software for desktop
• Dictation — writing, emails, fill in information — typing
• Command and control — dragging file, switching programs, and clicking
buttons or links

• Switch modes (number mode, command mode)

• See command cheat sheet: https://www.nuance.com/content/dam/nuance/
en_us/collateral/dragon/command-cheat-sheet/ct-dragon-home-en-us.pdf
Hardware Assistive Technology

• Emulates keyboard or mouse input

• Keyboard for single-handed use and switch devices
• Research how disabled people use specific mouse or tech to help them
navigate

• Accessible Tech - Stanford

• 14 Tech Tools for Accessibility
Multi-Media
Audio, Images, and Video
• What is the purpose of the content and determine how to make it accessible? Or not accessible.
• Informational images/media — important information is within the image
• Retail coffee mugs
• Videos/Podcasts
• Functional images/media — images that are part of links or form controls and are used for navigation or for performing tasks
within the browser.

• Video player buttons

• Map controls
• Arrows in navigation
• Decorative images/media — not important to the page
• Image inserted as a page divider line
• Image to decorate the page borders
• Rule of Thumb: Is the presence of the media essential for the meaning of the content or page? If yes, provide text equivalent.
Alt Text (Alternative Text)
• Describe overall purpose or intention
• E.g. Go to amazon.com home
• E.g. View ABC chart
• Determine if media is decoration, informational, or functional and describe
accordingly

• If the image contains information, alt describes image

• If the image is inside an <a> link element, alt describes link target
• If the image is for decoration only, use alt=“”
Responsive Design
Flexible Width & Responsive Design
• Avoid fixed width
• Font sizes should be flexible
• Design for text resize
• Multi-column form becomes single-column for small devices
• Prioritize content flow in small devices
• Allow for pinch/zoom
• DO NOT assume solely on browser window size whether the user is using a touch screen or
regular desktop or vice versa

• Linear order matters (Tabbing order)

• Make all content flow correctly in all sizes: small, medium, large
Design for Flexible Width & Height
• Avoid using fixed height or width. Specify height relative to text such as
“20rem”

• Upon text resize, content must

• Not disappear
• Not get cut off/over lap
• Not lose meaning or functionality
Semantic Structure
Content Hierarchy & Page Structure

• Mark up proper content hierarchy to help with easier/quicker understanding of the

content and helps skimming while using screen reader

• H1 - H6 for titles within each section and article

• Leverage HTML5 semantic markup
• header
• nav
• section > article > header > aside
• figure
• footer
Page Titles and Description
• Each page should have a distinguishing and unique title that matches/reflects
the H1 title of that page — possibly followed by site title

• E.g. Billing Information | Pet Sitter

• Provide short description of content on the page via <meta
name=“description” content=“description of page content”>
Section Titles and Emphasis
• Have either visual or screen reader only section titles
• Provide information about each section for non-visual browsers
• Defines and explains separate sections
• Emphasizing parts of sentence or content makes the emphasized portions
easier to identify

• Using correct tags to emphasize content allows the browser to properly

emphasize it
Some Semantic Elements
• <small>
• Fine print and legalese, terms and conditions, and legal disclaimers, footers, copyright statements, etc.
• Example: <small>All rights reserved</small>
• <cite>
• Title of work pointing to another source
• Great for wrapping the name of the source of a blockquote
• Example: <cite>W3C Web Standards</cite>
• <meter>
• Measures data within a given range, i.e., “9 out of 10 viewers are human”
• Example: <meter value=“9” min=“0” max=“10”>9 out of 10</meter><meter value=“.9”>90%</
meter>
Ordered, Unordered Lists & Others
• Lists can be more than bulleted and numbered lists such as
• Menus
• Blog and other indexes
• Sidebar items
• Comments (with sub-lists)
• Image galleries
• Items in list format are semantically grouped
• User can navigate from one to the next quickly
Forms
Form Validation
• Avoid modal error messages
• Once the modal is closed the message is gone
• Avoid showing error message only at the top but not near the input
• Lack of proximity
• Best Practices
• Consistent placement
• Use of error icon
• Visual proximity
• Simple, plain language
• Programmatic connection
Form Labels
• Programmatic relationship between label and input for assistive tech
• Clearer prompts
• Bigger targets for radio and checkbox
• EVERY form field needs a <label>
• Be aware of memory issues
• Avoid using placeholders as labels or help text
• Placeholder disappears and fields can be left unlabeled and devoid of helpful text
• Placeholder seemed as if it’s already filled out
• Because of lighter color it’s difficult to view for low vision
• Possible anxiety when placeholder moved up to become a label
• Provide help text right below input
Leverage HTML5 Form Elements
• input type
• <input type="color">
• <input type="date">
• <input type="datetime-local">
• <input type="email">
• <input type="image">
• <input type="month">
• <input type="number">
• <input type="password">
• <input type="tel">
• <input type="time">
• <input type="url">
• <input type="week">
Accessible Dynamic Forms
Commonly Violated WCAG 2.0 (A, AA) Success Criteria

• Perceivable
• All labels must be programmatically associated with the input field [WCAG 1.3.1
A]

• Labels must be closely and visually associated with the input field [Best Practice]
• Error Messages must be associated with the input field [WCAG 1.3.1 A]
• Do not use color alone to indicate differences between fields [WCAG 1.4.1 A]
• Required/Optional fields, Error fields
• Color contrast between controls, labels, instructions, errors, and the background
must be sufficient [WCAG 1.4.3 AA]
Commonly Violated WCAG 2.0 (A, AA) Success Criteria
• Operable
• Error Messages that apply to the whole form must be announced automatically [WCAG
2.4.3 A]

• Instructions that update/change dynamically must be announced automatically [WCAG

2.4.3 A]

• If you take action that allows the sighted mouse user to quickly identify and deal with fields
that are in error, then an equivalent mechanism should be provided for keyboard users
[WCAG 2.1.1 A]

• No keyboard trap [WCAG 2.1.1 A]

• Focus order [WCAG 2.4.3 A]
• Focus visible [WCAG 2.4.7 AA]
• Everything must be operable with the keyboard [WCAG 2.1.1 A]
Commonly Violated WCAG 2.0 (A, AA) Success Criteria

• Understandable
• On focus [ WCAG 3.2.1 A ]
• On input [ WCAG 3.2.2 A ]
• Error suggestion [ WCAG 3.3.3 AA ]
• Error prevention (Legal, Financial, Test Data) [ WCAG 3.3.4 AA ]
• Robust
• Name, Role, Value, and State [ WCAG 4.1.2 A ]
How to Code Labels for Inputs
• Simple Labels
• Use for-id association
<label for=“myinputID”>Label Text</label> <input id=“myinputID” type=“text” />

• Use aria-labelledby
<label id=“mylabelID”>Label Text</label> <input aria-labelledby=“mylabelID” type=“text” />

• Use label wrapping

<label>Label Text <input type=“text” /></label>

• Use aria-label and/or title

<input id=“search” type=“text” aria-label=“Search” placeholder=“Search” />

OR

<input id=“search” type=“text” title=“Search” placeholder=“Search” />

Multiple Labels
• Groups of Inputs
• Use <fieldset>
<fieldset><legend>Social Security Number</legend>

<input type=“text” name=“ssn1” id=“ssn1” title=“First 3 digits” />

<input type=“text” name=“ssn2” id=“ssn2” title=“Middle 2 digts” />

<input type=“text” name=“ssn3” id=“ssn3” title=“Last 4 digits” />

</fieldset>
Common States and Properties 1
• aria-describedby – References the id of another
element that offers a description
• Do use when adding more information to a
form input
• Don’t use to add the label already associated
to the input
• aria-hidden - Hides the information from screen
• aria-disabled – Indicates the element is
perceivable, but not editable or operable
• aria-errormessage – References another
element via its id that contains custom error
message text
• Must be used in conjunction with aria-invalid
• aria-invalid – Indicates entered data does not
conform to the format expected
• Do use with aria-required to set aria-invalid to
signal there is an error
• Don’t use before the user has had a chance to
move through that area of the form.
• Use with aria-errormessage
readers. Whatever is in the element and its
descendants are hidden from assistive
technology
• Do use when you are showing something
visually that isn’t useful to screen readers
(such as * for required)
• Don’t use to hide whole areas of a page. We
don’t want separate and not equal.
Common States and Properties 2
• aria-label – A string values that labels the
element
• Do use when adding more information for
assistive technologies
• Don’t use to reference the same information
already available on the screen. (use aria-
labelledby with the id instead)
• aria-live – Indicates the element will be updated
and describes the type of updates the user can
expect from the live region
• Values are expressed in degrees of
importance.
• Polite – AT will notify but doesn’t interrupt the
current task
• Assertive – AT notifies immediately
• Note: aria-live can only be used on an element
that is in the DOM upon screen load. We can’t
load something conditionally after the page
has loaded and expect that aria-live will work
• aria-modal – Indicates the presence of a modal
element
• aria-required – Alerts the screen reader that the
information is required
• aria-selected – Indicates the selected state
(single and multi select widgets)
• aria-readonly – Indicates an element is not
editable. User can read but not set the value of a
widget.
ARIA Basics

• Add aria-required=“true” to input fields that are required

• Add aria-hidden=“true” on items that are necessary visually but add nothing
aurally

• Can pair with another <div className=“sr-only”> to read something out

loud on a screen reader without affecting what’s on screen
Cursor & Focus

• Don’t have the cursor stay on a button after it is clicked. A non-sighted user
has no idea anything has changed.

• When something happens on an event, move the cursor to the area where
that happens: move the focus.
In a Nutshell: Designing for Accessibility
• When communicating with colors for status or
differentiation, do NOT rely on color only. Use
size, shape, patterns to show difference.
• Always test for contrast esp. for text vs.
background colors.
• https://webaim.org/resources/
contrastchecker/
• https://contrastchecker.com
• https://contrast-ratio.com
• http://contrast-finder.tanaguru.com/
• Animations
• Allow users the choice to turn animations off
• Make sure your site or app doesn’t rely on
animation
• Dissolve effect is better than sliding effect
• Flashing content can trigger seizure
• Group related items together to show the
relationship between them
• Plan your focus states
• Design for flexible width and height
• Upon text resize, content must
• Not disappear
• Not get cut off/over lap
• Not lose meaning or functionality
Mobile
Touch Interfaces & Target Sizes

• Touch interface makes content more inclusive.

• Sizes are variable from small (apple watch) to large (MS Surface studio).
• Very small target sizes too close together — Easy to miss by touch or tap.
• Make things a little bigger and give some breathing room.
• In general, plan for minimum 34x34 for MS, 44x44 for apple, 48x48 for google
for small targets.
Working with Gestures
• Not everyone will use touch screen the same way as you
• Blind — swipe means something else — enable double tap as another way
• Using a foot instead of hand — make target larger
• Arthritis — allow for wobble
• Conflicts in gestures — have secondary mechanism
Complex Visuals
• Map, locations
• Hide decorative elements from SCR readers
• Map, route
• Provide text-based directions
• Video
• Provide captions and audio description
• Comparison graph
• Provide information in a tabular form
Dev
Basics
• Easiest way to start creating Accessible Pages is through Structured HTML.
• Structure helps non-sighted users get around the pages more easily via
keyboard commands.

• Structured HTML adds Semantic meaning to our information.

• Create your structure first, add design and functionality second.
• Headings should be grouped correctly. H2 below H1, H3 below H2
• If you want something to be smaller or larger, don’t use an element that
doesn’t convey the correct meaning, style it with CSS
Form HTML
• JAWS/NVDA uses a special form mode — where only form related items are read and
regular text is omitted.

• In forms, if you need a heading use a fieldset legend: <fieldset><legend>Favorite Fruits</

legend> .. list of fruits here .. </fieldset>

• [ Not H1-H6 etc ] Headings are not read by screen readers in a form
• When displaying form information that isn’t editable but you wish for the screen reader to
view, use a definition list: <dl><dt>Label</dt><dd>Input Value</dd></dl>

• [ Not <div class=“label”>label</div> <div class=“input”>input</div> ]

• Use <label for=“input id” ></label><input id=“input id”> or <label><input></label>
• The label and form don’t need to be right next to each other so long as they are
associated by the id.
Best Practices
• Tab Order
• Links, and Form Elements can be tabbed to and follow the DOM
• If you need to add something in to be able to tabbed to use attribute: tablndex=“0”
• If you need to take something out of the DOM use attribute: tabIndex=“-1”
• Links
• Links that have the same wording should go to the same place
• Links going to different places should have wording that is different from each other
• Links must be styled to be distinct from surrounding text
• Errors should be identified so that someone who can’t see the screen understands what and where the
error is and how to get to it and fix it.

• We can and should use <th scope=“row”> on tables if the first column provides identifiable information.
<tbody><tr><th scope=“row”> is acceptable HTML structure.
WAI-ARIA

• We typically use it to insert attributes into the HTML in order to give screen
readers more information

• WAI-ARIA is a partnership between the Screen Readers and Browsers to

allow client side operations (JavaScript) to identify information necessary for a
non-sighted user to interact with our components and pages.
A Role is a Promise
• By using a role, the author promises that the specific code provides the
interactions expected of that role.

• <ul role=“menu">
<li><a role=“menuitem”>Item</a></li>
</ul>

The role here is a promise that the author has incorporated JavaScript that
provides the keyboard interactions expected for both a menu and
menuitem.
ARIA Roles
• We use roles to tell user agents what we are going to accomplish. It lets a user agent have specific
expectations.

• This includes document landmarks and the WAI-ARIA role taxonomy

• Role Types include:
• Landmark Roles – regions of a page intended for navigation
• Include banner, complementary, contentinfo, form, main, navigation, region and search
• Live Region Roles – notifies that these areas might change and for a user agent to monitor them
• Include alert, log, marquee, status and timer. These may be modified by the live region
attributes including aria-atomic, aria-busy, aria-live and aria-relevant

• Windows Regions – Regions that live outside the browser

• Include alertdialog and alert
Roles Do’s and Don’ts
DO

• Use Roles where necessary to allow users to navigate

• Good
• <form> or <div role=“tab”>
DON’T

• Add roles that duplicate structural HTML or override inherent existing structures
• Bad
• <form role=“form”>
• <td role=“cell”>
• <ul role=“button”>
Cloaking
• The information assistive technologies need about the meaning and purpose of user
interface elements is called accessibility semantics.

• From the perspective of assistive technologies, ARIA gives authors the ability to dress up
HTML and SVG elements with critical accessibility semantics that the assistive
technologies would not otherwise be able to reliably derive.

• Some of ARIA is like a cloak, it can override or cover up the original semantics or content.

<a role="menuitem">Assistive tech users perceive this element as an item in a menu and
not a link.</a>

<a aria-label="Assistive tech users can only perceive the contents of this aria-label, not the
link text">Link Text</a>
Danger of ARIA

• Authors can inadvertently override the accessibility semantics.

• <table role="log"> </table>
• Assistive technology users will not perceive the above as a table.
• The role of “log” tells the browser, this is a log, not a table.
• It’s important to architect our pages in a way that enhances accessibility
semantics, not override them.
No ARIA is Better than Bad ARIA
• Used judiciously, ARIA specifically enhances a non-sighted users’ experience
• But many developers tend to create bad structure (or no structure) and then
throw aria around it in an attempt to rectify the bad design

• It really just makes it worse

• We can add too much to an element with Aria causing too much aural clutter or
duplicative content or take away vital information.

• Use a combination of aria attributes and HTML, hiding items both visually or
aurally from both the visual rendition or from screen readers to achieve the best
accessibility we can.

• Use aria only when you can’t achieve the same outcome using structural HTML
Common States and Properties
• Properties: Attributes that are essential to the nature of an object or represent a
data value associated with the object

• State: Dynamic property expressing a characteristic of an object that may change

in response to a user action or an automated process

• Think opening and closing an accordion or filter block. Both of these need an aria
state that tells a user whether it is expanded or closed.

• Properties are less likely to change than a State, but they can and should when
appropriate.

• There are a whole lot of states and properties in aria, that judiciously used will
enhance accessibility. They are especially useful in components that are not part of
the inherent browser ecosystem such as a multi-select or auto suggest component.
Color Contrast and Color
Blindness
 https://webaim.org/resources/linkcontrastchecker/

https://webaim.org/resources/contrastchecker/
https://contrastchecker.com
https://contrast-ratio.com

http://contrast-finder.tanaguru.com/

https://developer.paciellogroup.com/resources/contrastanalyser/
https://material.io/color/ Color Contrast iOS App

Chrome Plug In

Android Accessibility Scanner

https://color.adobe.com/create/color-accessibility

https://colororacle.org/

https://venngage.com/blog/color-blind-friendly-palette/