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.

1. Introduction
to
mobile
accessibility
Henny
Swan

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

3. Agenda
• Requirements
and
planning
• User
experience
• Development
• QA
and
testing
3

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

7. MOBILE
ACCESSIBILITY
LANDSCAPE

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

11. Audience:
Personas
• Persona
resources
from
the
W3C
Mobile
Accessibility
Task
Force
11

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

19. Barriers
-­‐
orientation
• Forced
orientation
• Mounted
tablets
• Limited
scrolling
• Content
changes
19

20. Barriers
-­‐
Zoom
and
text
resize
• Pinch
zoom
being
disabled
• Loss
of
context
• Floating
toolbars
• Pop
ups
20

21. Barriers
-­‐
Zoom
21
• Fixed
position
content

22. Barriers
-­‐
Zoom
22
• Snap
scrolling

23. Barriers
–
cognitive
overload
• Inconsistent
design
• Excess
clutter
• Ambiguous
labels
• Ambiguous
icons
• Poor
error
handling
• Where
am
I?

24. Opportunity
-­‐
platform
features
• Geolocation
• Camera
• Contacts
• Phone
24

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

31. 31

32. 32

33. 33

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

38. WebAim
screen
reader
survey
38

39. WebAim
screen
reader
survey
39

40. WebAim
screen
reader
survey
40

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

43. MOBILE
ACCESSIBILITY
FEATURES

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

48. Switch
control
in
iOS8
-­‐
Luis
Perez
48

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

53. 53
3
finger
triple
tap
Screen
curtain

54. 54

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

58. 58
Android
-­‐
Talkback

59. Zoom
OS-­‐level
features
• Set
default
text
size
• Magnifies
entire
screen
•
Magnifying
lens
view
under
user's
finger
• 3
finger
scroll
59

60. Zoom
Browser-­‐level
features
• Set
default
text
size
of
text
in
the
browser
• Reader
mode
(not
universally
supported)
• Pinch
zoom
60

61. Zoom
Browser-­‐level
features
• Magnifying
lens
view
under
user's
finger
• Force
enable
zoom
(Chrome,
Android)
61

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

63. USER
EXPERIENCE

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

67. Principles
of
accessible
UX
67

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

69. 69
iOS
start
up
screens

70. 70
Android
start
up
screens

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 ”

74. Focus
74

75. Choice
Provide
multiple
ways
to:
• Access
key
tasks,
screens
or
information
• Complete
key
or
complex
tasks
• Complete
non
standard
interactions
75

76. Choice
76

77. Control
What
ways
can
user
controls
over
content
be
suppressed?
77

78. Control
What
ways
can
user
controls
over
content
be
suppressed?
• Orientation
78

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

82. Control
82

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

86. Value
86
GeolocationPhoneCamera

87. Value
Web
of
Things
• Health
• Home
• Entertainment
87
• Energy
• Education
• Security

88. Breakout
session
What
features
might
you
add
to
your
product
to
provide
a
better
user
experience
for
diverse
users?
88

89. DESIGN

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

92. Visual
cues
• Navigation
must
be
visually
explicit
• Distinguish
interactive
elements
92

93. Visual
cues
What’s
wrong
with
the
visual
cues
on
this
screen?
93

94. Visual
cues
-­‐
iconography
Question
mark,
home,
burger
for
home,
disc
for
save,
back
arrow
etc
94
GridAdd List Menu

95. Visual
cues
-­‐
conventional
positioning
95

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

97. Consistent
layout
-­‐
platforms
97
Netflix
on
desktop

98. Consistent
layout
-­‐
Platforms
98Main
menu
when
open Sign
out
at
the
foot
of
the
page

99. KEYBOARD
AND
TOUCH

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

101. 101

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

110. 110

111. FORMS

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

115. Keyboards
115

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

118. ALTERNATIVES

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

127. Traits
-­‐
iOS
• None
• Button
• Link
• SearchField
• Image
• Selected
• PlaysSound
• KeyboardKey
• StaticText 127
• SummaryElement
• NotEnabled
• UpdatesFrequently
• StartsMediaSession
• Adjustable
• AllowsDirectInteraction
• CausesPageTurn
• Header

128. 128

129. STRUCTURE

130. content
a
logical
order
provide
130

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

134. Headings
-­‐
HTML
134

135. Headings
135

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

139. 139

140. 140

141. ANNOTATED
UX

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

147. Annotated
UX
–
iPlayer
BBC
One
homepage

148. Annotated
UX
–
iPlayer
native
Android
app

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?

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

153. TESTING

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

156. Remote
debugging
156

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

160. Remote
debugging
Android
Select
Inspect
on
the
tab
you
want
to
inspect
160

161. Testing
-­‐
Android
Android
emulator
• Virtual
device
in
the
Android
SDK
• Configurable
to
mimic
different
devices
• Contains
a
debug
console
161

162. Testing
-­‐
Android
• Lint
• Finds
missing
contentDescriptions
• Finds
missing
input
types
on
text
fields
• Quick
fix
window
• Write
custom
scripts
to
test
162

163. xCode
iOS
Simulator
163

164. 164

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

170. Want
to
suggest
your
site?
170

171. THANK
YOU

173. Thank
you
• Hand
outs
and
slides
at
• hswan@paciellogroup.com
• @iheni
• www.iheni.com
173

174. iOS
Design
Principles:
Direct
manipulation
174

175. iOS
Design
principles:
feedback
175

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