This is a full day workshop I gave at AccessU 2015 and an updated version of the same workshop I gave at AccessU in 2013 (also on Slideshare).
As an introduction to mobile accessibility it covers key concepts, user experience, development and some QA. It is intended mostly for a non-technical audience who are looking for an introduction to mobile web accessibility and native apps although it does contain some technical guidance.
2. This
is
a
full
day
workshop
I
gave
at
AccessU
2015
and
an
updated
version
of
the
same
workshop
I
gave
at
AccessU
in
2013.
As
an
introduction
to
mobile
accessibility
it
covers
key
concepts,
user
experience,
development
and
some
QA.
It
is
intended
mostly
for
a
non-‐technical
audience
who
are
looking
for
an
introduction
to
mobile
web
accessibility
and
native
apps
although
it
does
contain
some
technical
guidance.
2
4. Hand
outs
and
slides
• Handouts
available
now
in
http://bit.ly/1e0Wn8g
• Slides
to
follow
• Follow
@iheni
for
URLS
• All
questions
are
good
questions
• Today
is
about
sharing
4
5. Henny
Swan
• User
Experience
and
Design
Lead,
The
Paciello
Group
• Formally
BBC,
Opera
Software,
Royal
National
Institute
of
Blind
People
• Specialize
in
accessible
user
experience,
mobile,
media
players,
strategy
• Member
of
W3C
Mobile
Accessibility
Task
Force.
User
Agent
Accessibility
Working
Group
and
Web
of
Things
Task
Force
6. You
• Name
• Company
• Role
• Your
experience
of
accessibility
• Device
8. Audience:
who
Diversity
in
disability:
• Type
of
impairment(s)
• Severity
of
impairment(s)
• Circumstances
of
acquisition
of
impairment(s)
• Changeable
impairment(s)
8
9. Audience:
who
Diversity
in
disability:
• Assistive
technology
and
settings*
used:
• Vendor
• Version
• Configuration
• Aptitude
in
using
AT
• Attitude
to
using
AT
*
Assistive
technologies
include
screen
readers,
zoom,
text
resizing,
voice
input,
invert
colors
9
10. Audience:
who
We
all
face
being
impaired:
As
a
child…
Unable
to
hold
a
tablet
Unable
to
use
certain
gestures
Unable
to
understand
text
and
iconography
As
an
older
user…
Reduced
sight,
hearing,
cognition
Problems
with
perception
Temporarily
Broken
wrists,
RSI,
carpel
tunnel
Designing
touch
tablet
experiences
for
preschoolers
–
Sesame
Street 10
12. Judy
Dench
Ability:
Advanced
macular
degeneration
and
mild
arthritis
Aptitude:
Hasn’t
really
used
tech
much
but
realizes
she
now
has
to
and
uses
an
iPad
Attitude:
Willing
but
is
too
busy
to
dedicate
the
time
12
13. Gary
Numan
Ability:
Autism
Spectrum
Disorder.
Uses
zoom
and
occasionally
VoiceOver
when
he
is
tired
Aptitude:
Uses
tablets
for
news
and
research,
but
doesn’t
learn
new
sites
easily
Attitude:
Prefers
apps
to
mobile
content
and
an
established
routine
13
14. Sinead
O’Conner
Ability:
Fatigue
from
fibromyalgia,
touch
screens,
tapping
and
scrolling
are
hard
Aptitude:
Average
user,
has
good
days
and
bad
days
Attitude:
Wishes
the
hardware
made
more
sense
14
15. Marlee
Matlin
Ability:
Native
language
is
ASL;
can
speak
and
read
lips;
uses
SMS/IM,
Skype,
and
video
chat
Aptitude:
Good
with
graphic
tools,
and
prefers
visuals
to
text;
poor
spelling
makes
searching
more
difficult
Attitude:
Gets
annoyed
by
lack
of
subtitles
15
16. Stephen
Hawking
Ability:
Suffers
from
acute
Motor
Neurons
Disease,
no
movement
or
speech
Aptitude:
Super
user,
patient,
curious,
but
is
a
busy
man
Attitude:
Tries
anything,
knows
what
he
wants,
determined
-‐
this
is
his
only
line
of
communication
16
17. Barriers
-‐
Input
• Dexterity
and
touch
• Single
handed
• Environment
and
voice
17
18. 18
I’m
going
to
stick
with
my
Nokia
C5.
I
want
my
mobile
to
be
something
that’s
mobile,
as
in
I
can
walk
and
use
it
without
having
to
stop.
-‐
Hugh
Huddy,
blind
Nokia
and
Talks
user
25. Opportunity
-‐
Web
of
Things
• Home
energy
management
• Healthcare
and
fitness
• Google’s
Physical
Web
• Identity
management
and
authentication
• Casting,
audio
and
video
control
25
26. Web
and
mobile
standards
A
significant
but
not
exact
mapping
between
desktop
and
mobile
• Touchscreen
on
both
desktop
and
mobile
• Mobile
devices
with
external
keyboards
• Responsive
design
• User
interface
patterns
from
desktop
used
on
mobile
(links,
tables,
buttons,
menus
etc)
26
27. Legal
requirement
21st
Century
Act,
USA.
By
2013
smartphones:
• must
have
an
accessible
browser
• must
be
accessible
at
the
OS
level
• must
have
free
or
of
“nominal
cost”
soluQons
ImplicaQons
• North
American
mobile
market
influenQal
globally
• Apple,
Google,
MicrosoU,
RIM
SecQon
508
Refresh
• ‘informaQon
and
communicaQon
technology’
must
be
WCAG
2.0
compliant 27
28. Standards
and
guidelines
W3C
guidelines:
• Web
Content
Accessibility
Guidelines
(WCAG)
• How
WCAG
and
UAAG
apply
to
mobile
devices
• Shared
experiences:
Barriers
common
to
mobile
device
users
and
people
with
disabilities
• Mobile
Accessibility
Overlap
• Independant
User
Interface
(Indi
UI)
Working
Group 28
29. Standards
and
guidelines
iOS
guidelines:
• Accessibility
Programming
Guide
for
Developers
• Human
Interface
Guidelines
for
Designers
29
Android
guidelines:
• Making
applications
accessible
• Accessibility
Developers
checklist
• Android
design:
accessibility
30. BBC
Mobile
Accessibility
Standards
and
Guidelines
• Technology
agnostic
• iOS,
Android
and
HTML
techniques
• Test
procedures
30
34. Platform
and
browser
support
Define
the
delivery
context
• Responsive
• Native
app
• Hybrid
34
35. Platform
and
browser
support
Define
supported
devices:
• Reference
pre-‐existing
platform
and
browser
support
plans
• What
devices
have
sufficient
accessibility
support
• What
devices
have
accessible
native
browsers
• What
devices
are
easy
to
upgrade
• Version
support 35
36. Platform
and
browser
support
Define
supported
devices:
• Analyze
web
stats
• Assess
regional
preferences
• Assess
local
legal
requirements
• Research
user
preferences
Output:
mobile
platform
and
browser
support
matrix
with
version
support
logic
36
37. Platform
and
browser
support
Webaim
screen
reader
surveys
• Surveys
screen
reader
user
preferences
of
web
and
mobile
usage
• Every
year
since
2009
• Open
to
anyone
• 2014
survey
results:
• 1456
respondents
• 61%
from
the
US,
21%
UK
and
EU,
Asia
10%…
• 95%
reported
having
a
disability 37
41. TPG
2013
MOBILE
SURVEY
41
http://www.paciellogroup.com/mobile/
42. Breakout
session
Write
a
Mobile
Accessibility
Strategy
for
a
product
including
• Product
name
and
purpose
• Target
audience
• Platform,
access
technology
and
browser
support
• HTML,
native
or
hybrid
42
44. Mobile
accessibility
landscape
iOS
Accessibility
features
and
API
are
the
most
mature
Android
has
some
good
accessibility
features
Google
are
working
to
improve
Current
market
share
favors
iOS
and
Android
devices
over
other
vendors
BlackBerry
Curve
smartphones
have
free
BlackBerry
Screen
Reader
Windows
Phone
8.1
Text
resizing,
High
Contrast
mode,
Narrator,
screen
magnificaQon,
Zoom
44
45. iOS
accessibility
features
45
Seang User
Voiceover Blind,
low
vision,
learning
and
cogniQon
Zoom,
Large
Text Blind,
low
vision,
learning
and
cogniQon
Invert
colors,
Grey
scale Low
vision,
color
blindness,
learning,
cogniQon
Speak
selection Low
vision,
learning
and
cogniQon
Speak
auto-‐text Blind,
low
vision,
learning
and
cogniQon
Hearing
aid
mode Deaf,
hard
of
hearing,
deaf
blind
Customize
closed
captions Deaf,
hard
of
hearing,
everyone
Guided
access Everybody
including
children
&educaQon
Assistive
touch Mobility
Switch
control Mobility,
hands
free
46. iOS
-‐
mapping
accessibility
shortcuts
1. Go
to
Settings
>
General
Accessibility
>
Accessibility
Shortcut
2. Select
shortcuts
3. Triple
click
the
Home
key
to
activate 46
47. iOS
-‐
switch
support
• iOs7+
• Using
an
external
device
or
FaceTime
• Accessed
via
Settings
>
Accessibility
>
Switch
control
47
49. iOS
-‐
VoiceOver
• Supports
36
languages
• Gesture
and
explore
by
touch
support
• Supports
braille
output
• Excellent
browsing
support
49
50. iOS
-‐
activating
VoiceOver
1. Triple
click
the
Home
key
to
activate
2. Dial
to
open
the
Rotor
3. Swipe
up/down
to
navigate
parts
4. Swipe
right/left
for
next
previous
50
51. iOS
-‐
rotor
navigation
1. Dial
gesture
on
screen
2. Select
how
you
want
to
navigate
3. Swipe
up
or
down
51
52. 52
Gesture FuncGon
Switch
VO
on/off Triple
click
the
home
key
Speak
an
element
Single
tap
pActivate
an
element Double
tap
Open
the
Rotor Turn
a
dial
Zoom 3
finger
double
tap
-‐
iOS6+
only
Next
section
in
Rotor Swipe
up/down
Next/previous
item
in
content
order Swipe
right/left
Pass
through
gesture
(drag
&
drop) Double
tap
hold
Play/Pause 2
finger
double
tap
iOS
-‐
basic
VoiceOver
gestures
55. Seang User
Voice
output Blind,
low
vision,
learning
and
cogniQon
HapGc
feedback Blind,
Deaf-‐Blind,
Low
vision,
deaf
Large
text Low
vision,
cogniQon,
learning
Speak
passwords Blind,
low
vision,
cogniQon,
learning
Enhance
web
accessibility Blind
Android
-‐
accessibility
features
56. Chrome:
Force
enable
zoom
Text
size
Text
scaling
Zoom
on
double-‐tap
Minimum
font
size
Inverted
colors
Contrast
A
useful
‘screen
curtain’
equivalent
Shades
app
can
also
do
this
56
Android
-‐
browser
settings
57. Enable
WebScripts
via
Settings >
Accessibility > ‘Enable Accessibility’
Download
the
Eyes
Free
Keyboard
Browsing
Less
reliable
than
iOS
ApplicaQons
Talkback
well
supported
Beware
hybrid
content
Maps,
adverts,
Terms
and
CondiQons,
Help
pages
etc
57
Android
-‐
Talkback
62. Breakout
session
Using
iOS
or
Android
try
using
each
of
the
following:
• Screen
reader
• Zoom
• Head
switch
Refer
to
the
handouts
which
have
set
up
and
gesture
instructions. 62
64. As
a
user
I
want…
• WCAG
Level
AA
compliance
• WAI
ARIA
• Validated
code
Said
no
user
ever!
64
65. Accessibility
and
inclusive
design
Standards
and
guidelines
tend
to
focus
more
on:
…code
over
design
…output
over
outcome
…compliance
over
experience
65
66. – I A N P O U N C E Y, W E B D E V E L O P E R , B B C
“It pains me to say this but web developers might not
be the most important people when it comes to
making accessible websites and web apps.”
68. People
first
• Put
people
before
technology
• Consider
environment
and
context
• Consider
first
time
users
and
repeat
users
• Consider
AT
super
users,
average
users,
or
basic
users
68
71. Focus
Prioritise
key
features
in
the
layout
and
content
order
Remove
unnecessary
elements
Group
elements
logically,
visually
and
in
the
content
order
Progressively
reveal
content
on
user
request
71
72. “ T h e o b v i o u s i s a a b o u t a l w a y s ”
75. Choice
Provide
multiple
ways
to:
• Access
key
tasks,
screens
or
information
• Complete
key
or
complex
tasks
• Complete
non
standard
interactions
75
79. Control
What
ways
can
user
controls
over
content
be
suppressed?
• Orientation
• Pinch
zoom
79
80. Control
What
ways
can
user
controls
over
content
be
suppressed?
• Orientation
• Pinch
zoom
• Right
click
(web)
80
81. Control
What
ways
can
user
controls
over
content
be
suppressed?
• Orientation
• Pinch
zoom
• Right
click
(web)
Support
browser
and
platform
accessibility
features
81
83. Control
iOS7+
closed
caption
customization:
• Font
• Size
• Color
• Background
color
• Background
opacity
• Text
edge
style
• Text
highlight 83
84. Familiarity
BBC
Radio
iOS
app’s
custom
‘dial’.
“Although
the
3
finger
swipe
works
for
exposing
stations,
it’s
not
intuitive…
it
would
be
nice
if
some
alternative
solution
could
be
implemented
as
someone
new
to
the
app
probably
wouldn't
think
of
doing
that,
and
of
course
it
should
be
pointed
out
that
VoiceOver
gives
no
feedback
when
you
do
the
3
finger
swipe”
84
85. Prioritise
features
that
might
be
of
particular
value
for
everyone
• Platform
features
• A
to
Z,
filters,
sort,
manage,
delete
• Web
of
things
Value
85
90. Color
contrast
-‐
desktop
Based
on
15-‐inch
monitor
at
1024x768
resolution
with
a
24-‐inch
viewing
distance
WCAG
2.0
recommends:
• contrast
of
4.5:1,
14pt
text
• contrast
ratio
of
3:1
for
18pt+
90
91. Focus
states
• Use
distinctive
hover/focus
states
• Ideally
use
the
same
hover
state
on
focus
• Selected
states
must
be
unique
91
96. Positioning
-‐
reach
• Optimize
for
use
one
handed
• Important
content
bottom
left
to
right
• Position
important
content
above
page
scroll
96Mobile
First
by
Luke
Wroblewski
100. Keyboard
control
• Via
on
screen
keyboards
and
via
physical
keyboards
• On
touch,
with
VO
and
Talkback
running
‘keyboard
access’
includes
static
and
hidden
content
as
well
as
focusable
elements
• Everything
related
to
content
and
functionality
must
be
focusable
100
102. Touch
events
Mouse
or
touched
events
prevent
unintentional
triggers
when
interacting
• Gives
mouse
users
the
opportunity
to
move
the
cursor
outside
the
element
to
prevent
the
event
from
being
triggered
• Only
triggers
elements
on
touch
when
the
user
lifts
the
finger
off
the
screen,
the
last
position
of
the
finger
is
inside
the
actionable
element,
and
the
last
position
of
the
finger
equals
the
position
at
touch
start 102
103. Touch
target
size
103
“The
fingers
you
have
used
to
dial
are
too
fat.
To
obtain
a
special
dialling
wand,
please
mash
the
keypad
with
your
palm
now.”
104. Touch
target
size
Standard
touch
target
size
of
7-‐10mm
Jacob
Neilson
recommends
9.2
-‐
9.6mm
Android
Touch
target
size
of
48dp/9mm
Spacing
between
UI
elements
8dp
iOS
Touch
target
size
of
44px
/
44px
tall
PosiQoning
Provide
1mm
inacQve
space
around
elements
Balance
enough
informaQon
density
and
targetability
of
UI
Elements
PosiQon
content
appropriately 104
105. Touch
target
size
Group
links
to
the
same
resource
• Larger
touch
target
• Removes
repetition
for
screen
reader
users
• Less
swiping
and
physical
overhead
needed
105
106. Gestures
Easier
/
more
intuitive
Tap
Draw
/
Move
finger
Swipe
Drag
Slide
Double
tap
Harder
/
least
intuitive
Pinch
Device
manipulation
e.g.
tilt
/
shake
Multi-‐touch
Flick
/
Fling
Reference:
Designing
touch
tablet
experiences
for
preschoolers
–
Sesame
Street
107. Gestures
-‐
device
manipulation
• Device
manipulation
=
tilting,
shaking
etc
• Challenge
to
people
who
can
not
hold
a
device
• Discoverability
and
accidental
activation
also
an
issue
• Always
provide
touch
and
keyboard
operable
alternative 107
108. Zoom
/
Magnification
• Consider
mobile
first
when
designing
layout
and
content
relevancy
• Minimise
content
in
comparison
to
desktop
• Provide
a
reasonable
default
size
for
content
and
touch
controls
• Adapt
link
text
length
to
adapt
to
the
viewport
• Position
form
fields
above
rather
than
beside
form
labels
(in
portrait
layout) 108
109. Zoom
/
Magnification
-‐
HTML
Avoid
<meta content=”width=device-width;
initial-scale=1.0; maximum-scale=1.0;
user-scalable=1;” name=”viewport”>
Use
<meta content=”width=device-width;
initial-scale=1.0; maximum-scale=2.0;
user-scalable=1;” name=”viewport”>
iOS
bug:
Scale
and
orientaQon
Jeremy
Keith 109
112. Forms
-‐
labels
• Auto
zoom
cuts
off
left
aligned
labels
• Labels
above
the
field
are
always
in
view
• Label
explicitly
(HTML)
for
larger
touch
zones 112
113. Forms
-‐
viewport
Use
the
correct
viewport:
• Responsive:
<meta
name=”viewport”
content=”width=d
evice-width” />
• Mobile:
make
sure
the
viewport
is
the
width
of
your
layout
(usually
about
320
pixels
• CSS
for
padding
and
large
touch
targets 113
114. Forms
-‐
keyboards
• Default
keyboard
-‐
capitals,
numbers,
special
characters,
punctuation
buried
in
sub
menus
• Use
HTML
text
input
types
to
invoke
task
based
keyboards
114
116. Forms
-‐
sign
up
• Minimise
data
entry
• Gradual
engagement
• Third
party
sign
up
116
117. Forms
-‐
autofill
and
predictive
text
• Support
both
where
logical
• Disable
where
logical
e.g.
for
names,
email
addresses
• iOS5
• autocapitalize=”sentences”
autocapitalize=”words”
autocapitalize=”characters”
117
119. Alternatives
are
used
for…
• Images
• Buttons
• Graphs,
charts,
diagrams
• Audio
• Video
119
120. Editorial
for
alternatives…
• Briefly
describe
the
image
• Do
not
describe
the
role
/
Trait
• Begin
with
a
capitalized
word
• Don’t
end
with
a
period
(.)
• Localized
120
121. Alternative
text
-‐
HTML
Assign
contentDescription
to
all
user
interface
components
e.g.:
• alt=“”
• alt=“Home”
• alt=“Austin University Campus”
121
122. Tooltips
-‐
HTML
• Not
well
supported
on
mobile
and
touch
• Not
always
accessible
on
desktop
• Never
include
primary
information
• If
in
doubt
just
say
no
122
123. Alternatives
-‐
Android
Assign
contentDescription
to
all
user
interface
components
e.g.:
• imageButton
• imageView
• checkbox
Decorative
images
should
not
have
a
contentDescription
123
124. Labels
-‐
iOS
accessibilityLabel
must
be
provided
for
all
interacQve
and
informaQonal
elements
including
images,
buoons,
headings,
staQc
text
and
form
fields
124
125. Hints
-‐
iOS
accessibilityHints
may
be
used
to
provide
further
informaQon
• Describes
what
an
element
does
• Must
not
include
informaQon
about
the
objects
type
(i.e.
Trait)
• Use
sparingly
and
not
for
key
informaQon
Must
be
a
descripQon
not
a
command
e.g.
‘Deletes
programme’
not
‘Delete
programme’
125
126. Traits
-‐
iOS
Assign
accessibilityTrait
to
all
user
interface
components
Traits
describe
control
type
or
behavior
Control
types
are
mutually
exclusive
and
describe
the
nature
of
the
item
More
than
one
behavior
trait
can
be
used
to
describe
what
items
do 126
131. provide
a
logical
content
order
131
Don’t
make
your
content
sound
like
Yoda
132. Headings
HTML
• Headings
indicated
using
H1
to
H6
Android
• No
means
to
indicate
headings
iOS
• Use
accessibilityTraitHeader 132
133. Headings
Headings
and
lists
H1
to
H6
OL
and
UL
NavigaQon
to
headings
and
the
start
of
lists
for
screen
readers
Seven
plus
or
minus
2
The
opQmum
number
humans
process
informaQon
In
taxonomy
this
translates
to
5-‐9
headings
Headings
as
lists
Content
under
a
heading
may
be
removed
on
mobile
Consider
lists
over
headings
Avoid
mixing
both 133
136. Headings
-‐
iOS
• iOS
6+
• UIAccessibilityTraitHeading
• Accessed
via
the
Web
Rotor
136
137. Landmarks
-‐
HTML
Landmarks
reach
the
parts
of
the
page
other
HTML
can
not
reach
• 1
‘main’
per
page
• 1
‘header’
• use
‘navigation’
for
navigation
between
pages
• ‘complementary’
for
reusable
content
• Use
sparingly 137
138. Landmarks
-‐
HTML
HTML5
sectioning
elements
map
to
ARIA
Landmarks
• article
maps
to
role=“article”
• aside
maps
to
role=“complementary”
• footer
maps
to
role=“contentinfo”
• header
maps
to
role=“main”
• nav
maps
to
role=“navigation”
• section
maps
to
role=“region”
138
142. Annotated
UX
Annotate
UX
refers
to
annotating
wireframes,
style
guides
and
designs
for
accessibility.
The
need
for
Annotated
UX
is
threefold…
143. Annotated
UX
Annotate
UX
refers
to
annotating
wireframes,
style
guides
and
designs
for
accessibility.
The
need
for
Annotated
UX
is
threefold:
1. Expose
accessibility
issues
that
originate
from
the
design
144. Annotated
UX
Annotate
UX
refers
to
annotating
wireframes,
style
guides
and
designs
for
accessibility.
The
need
for
Annotated
UX
is
threefold:
1. Expose
accessibility
issues
that
originate
from
the
design
2. Document
accessibility
requirements
prior
to
coding
145. Annotated
UX
Annotate
UX
refers
to
annotating
wireframes,
style
guides
and
designs
for
accessibility.
The
need
for
Annotated
UX
is
threefold:
1. Expose
accessibility
issues
that
originate
from
the
design
2. Document
accessibility
requirements
prior
to
coding
3. Stop
developers
mucking
up
your
designs!
146. Risks
of
not
doing
it
• Designs
come
back
to
you
once
signed
off
with
questions
and
clarifications
• Designs
are
interpreted
and
coded
incorrectly
• Consistency,
value,
choice
and
familiarity
for
the
user
will
be
compromised
149. Breakout
session:
Annotated
UX
Refer
to
either
the
response
wires
or
iOS
wires
in
the
handouts:
1. What
should
be
changed
for
accessibility?
2. Annotate
the
wireframes
for
accessibility
3. How
would
you
document
requirements
in
an
accessible
way?
150.
151.
152. What
else
can
annotated
UX
be
used
for?
Wireframes
Visual
design
Style
guides
Usability
testing
Accessible
prototypes
Requirements
User
stories
Pattern
libraries
Manual
tests
Automated
tests
154. Testing
-‐
HTML
• W3C
developing
a
mobile
checker
• User
agent
switchers
154
155. Remote
debugging
iOS
• iOS
in
Safari
(also
Android)
• iOS
select
Settings
>
Safari
>
Advanced
and
switch
Web
Inspector
on
• Mobile
Safari
Preferences
>
Advanced
and
select
Show
Develop
Menu
in
menu
bar
155
157. Remote
debugging
Android
• Enable
USB
debugging
via
Settings
>
Developer
options
• Note
-‐
On
Android
4.2
and
later,
the
developer
options
are
hidden
by
default.
To
enable
the
developer
options,
select
Settings
>
About
phone
and
tap
Build
number
seven
times.
• Select
USB
debugging
157
158. Remote
debugging
Android
• In
Chrome
go
to
chrome://inspect
• Select
‘Discover
USB
devices
• Conform
allow
USB
debugging 158
159. Remote
debugging
Android
The
chrome://inspect
page
displays
every
connected
device,
along
with
its
open
tabs
and
debug-‐enabled
WebViews
159
165. Manual
testing
• Always
manually
test
websites
and
apps
• Simulators,
automated
tests,
inspecting
code
will
not
spotlight
usability
issues
165
166. Top
tests
for
voice
output
1. Content
and
focus
order
2. Alternatives
exist
and
make
sense
3. Structure
is
communicated
4. Form
labels
and
instructions
5. Notifications
are
provided
166
167. Top
tests
for
zoom
1. Context
is
not
lost
2. Labels
for
forms
are
visible
above
form
inputs
3. Screens
are
not
cluttered
4. Primary
information
is
obviously
positioned
5. Notifications
are
visible
on
screen
167
168. Top
tests
for
greyscale
/
invert
colors
1. Text
is
readable
2. Color
contrast
is
sufficient
3. Color
is
not
relied
upon
to
convey
meaning
168
169. Breakout
session
Using
either
zoom,
switch
or
a
screen
reader
(with
screen
curtain
on
for
iOS)
complete
the
following:
1.
On
the
Airbnb
find
a
place
to
stay
in
Austin
between
September
1st
and
7th,
for
2
people
for
under
$200
2.
Using
both
Twitter
and
Facebook
send
a
Tweet
or
post
a
comment
using
the
#AccessUSummit
hashtag
169
176. Android
design
principles
Enchant
me
• Delight
me
in
surprising
ways
• Real
objects
are
more
fun
than
buttons
and
menus
• Let
me
make
it
mine
• Get
to
know
me
176
177. Android
design
principles
Simplify
my
life
• Keep
it
brief
• Never
lose
my
stuff
• Pictures
are
faster
than
words
• Decide
for
me
but
let
me
have
the
final
say
• Only
show
what
I
need
when
needed
• I
should
always
know
where
I
am
• If
it
looks
the
same
it
should
act
the
same
• Only
interrupt
me
if
it’s
important
177
178. Android
design
principles
Make
me
amazing
• Give
me
tricks
that
work
everywhere
• It’s
not
my
fault
• Sprinkle
encouragement
• Do
the
heavy
lifting
for
me
• Make
important
things
fast
178
179. Alternatives
-‐
testing
Test
1. Switch
on
speech
output
2. Navigate
to
images,
elements
and
objects
either
by
• Explore
by
touch
(Android/iOS)
• Swiping
up/down,
leU
and
right
3. Verify
an
alternaQve
is
provided
4. Verify
the
alternaQve
accurately
describes
the
content
or
funcQon
Expected
results
• Each
meaningful
images
element
and
object
has
an
alternaQve
• AlternaQves
describe
either
the
• content
of
a
non-‐funcQonal
image,
element
or
object
• the
funcQon
of
an
acQonable
image,
element
or
object 179
180. Color
contrast
-‐
mobile
• Only
use
3:1
when
text
is
roughly
equivalent
to
1.2
times
bold
or
1.5
times
(120%
bold
or
150%)
that
of
the
default
platform
size
• Still
wont
guarantee
access
for
low
vision.
Platform
specific
tools
may
need
to
be
used.
180