Where do you start when making your content mobile? This presentation tackles how people with disabilities use the mobile web and applications, putting together a mobile support strategy, responsive web design, iOS and Android development covering design, development and testing.

1. Henny
Swan
@iheni
|
www.iheni.com
|
henny@iheni.com
Introduc)on
to
Mobile
Accessibility
Tuesday, 21 May 13

2. Me
2
Tuesday, 21 May 13

3. Me
2
Tuesday, 21 May 13

4. Me
2
Tuesday, 21 May 13

5. Me
2
Tuesday, 21 May 13

6. Me
2
Tuesday, 21 May 13

7. Me
2
Tuesday, 21 May 13

8. Me
2
Tuesday, 21 May 13

9. Me
2
Tuesday, 21 May 13

10. Me
2
Tuesday, 21 May 13

11. Me
2
Tuesday, 21 May 13

12. Me
2
Tuesday, 21 May 13

13. You
3
Tuesday, 21 May 13

14. 4
Discovery
Design
&
Build
Deploy
Tuesday, 21 May 13

15. 5
Discovery
Design
&
Build
Test
Tuesday, 21 May 13

16. Who
Disabled,
ageing,
young,
legacy
tech
You
What
Mobile
web,
RWD,
Apps,
Hybrids
Pla@orms
Devices
How
Guidelines
Technology
and
device
support
Test
plans
6
Discovery
Discovery
Tuesday, 21 May 13

17. Who
7
Tuesday, 21 May 13

18. People
first,
disability
second
People
not
defined
by
disability
People
are
not
defined
by
assisEve
tech
May
have
mulEple
or
changing
impairments
Beware
disability
silos
Design
for
different
acEvity
flows:
I
am
a
first
Eme
user
/
I
am
a
repeat
user
I
am
on
the
move
I
am
task
focused
I
am
on
the
sofa
Challenge
your
assumpEons
about
disabled
users
8
Who
Discovery
Tuesday, 21 May 13

19. Design
for
disability,
not
in
spite
of
it
9
Who
Discovery
Tuesday, 21 May 13

20. 10
The
mul)faceted
user
Repeat
user
Task
based
user
First
)me
user
AA
‘Lean
back’
user
Design
for
the
MulEfaceted
User
by
Stephanie
Troeth
Tuesday, 21 May 13

21. 11
The
mul)faceted
user
Repeat
user
Task
based
user
Low
vision
First
)me
user
Old
AA
Limited
data
Hard
of
hearing
Screen
reader
user
Mobility
Travelling
On
the
sofa
‘Lean
back’
user
Dexterity
Children
Tuesday, 21 May 13

22. 12
The
mul)faceted
user
Repeat
user
Task
based
user
Aspergers
Low
vision
First
)me
user
Second
language
Old
AA
Limited
data
Hard
of
hearing
Deaf
Poor
connec)on
Screen
reader
user
Zoom
user
Blind
Voice
input
user
Mobility
Travelling
On
the
sofa
Depressed
Young
‘Lean
back’
user
Cap)ons
Scrolling
Dexterity
Children
Cogni)on
Tuesday, 21 May 13

23. 13
The
mul)faceted
user
Repeat
user
Task
based
user
Aspergers
Low
vision
First
)me
user
Second
language
Old
AA
Limited
data
Hard
of
hearing
Deaf
Poor
connec)on
Screen
reader
user
Zoom
user
Blind
Voice
input
user
Mobility
Travelling
On
the
sofa
Depressed
Young
‘Lean
back’
user
Cap)ons
Scrolling
Touch
Keyboard
D
Pad
Dexterity
Children
Cogni)on
Apps,
Hybrid
Web
Mobile
Tablet
TV
Windows
Android
iOS...
Tuesday, 21 May 13

24. I’m
going
to
s=ck
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,
Nokia
and
Talks
user
14
Tuesday, 21 May 13

25. Flip
phone
A
phone
that
flips
open
and
answers
automaEcally
may
be
useful
for
blind,
low
vision
or
users
with
mobility
impaired
users
Monoblock
/
sEck
For
people
with
arthriEs
or
poor
dexterity
useful
to
avoid
the
need
for
added
movements
like
sliding
or
flipping
open
the
phone
to
use
it.
15
Who
Discovery
Source:
www.MobileAccessibility.info
Tuesday, 21 May 13

26. Slide
or
slip
Useful for people with limited or low vision
or who are blind, as they will answer
automatically upon sliding open
Touch
and
Smartphone
May
be
useful
to
people
who
are
deaf
or
hard
of
hearing
and
who
use
larger
screen
sizes
for
texEng
or
video
calling
.
16
Who
Discovery
Tuesday, 21 May 13

27. What
17
Tuesday, 21 May 13

28. Mobile
is
by
defini)on
is
disabling
18
Tuesday, 21 May 13

29. Screen
size
iPhone
is
1/12
a
typical
desktop
screen
size
40
pixel
finger
is
big
on
small
targets
Reach
Fonts
and
colour
Poor
support
on
older
phones
Small
text
Fixed
text
Input
Dexterity
and
touch
Environment
and
voice
Single
handed
Barriers
mulEplied
x
10
for
diverse
users 19
Restric=ons
on
mobile
Discovery
Tuesday, 21 May 13

30. Mobile
is
by
defini)on
is
enabling
20
Tuesday, 21 May 13

31. Mobile
over
desktop
Faster
innovaEon
Portability
LocaEon
services
Maps
Tailored
content
Device
integraEon
Contacts
Camera
Maps
Accessibility
support
Built
in
&
third
party
Se[ngs
Second
screen
21
Opportuni=es
on
mobile
Discovery
Tuesday, 21 May 13

32. While
engaging
with
content
on
ne
device,
e.g.
TV,
addiEonal
contextual
informaEon
is
displayed
on
a
companion
device
e.e.
mobile
or
tablet
EPG
The
app
synchronises
content
via
listening
to
the
TV
Select
camera
angles
for
awards
shows
/
sport
Audio
descripEon
/
Enriched
commentary
at
The
Olympic
Opening
Ceremony
Massive
opportuniEes
for
people
with
disabiliEes
Delivery
of
access
services
-­‐
signing,
AD,
capEoning
Using
a
device
as
a
remote
Shared
but
tailored
experiences
22
Second
screening
&
accessibility
Discovery
Tuesday, 21 May 13

33. While
engaging
with
content
on
one
device,
e.g.
TV,
addiEonal
contextual
informaEon
is
displayed
on
a
companion
device
such
as
a
mobile
or
tablet
EPG
The
app
synchronises
content
via
listening
to
the
TV
Select
camera
angles
for
awards
shows
/
sport
Audio
descripEon
/
Enriched
commentary
at
The
Olympic
Opening
Ceremony
Massive
opportuniEes
for
people
with
disabiliEes
Delivery
of
access
services
-­‐
signing,
AD,
capEoning
Using
a
device
as
a
remote
Shared
but
tailored
experiences
23
Second
screen
&
accessibility
Discovery
Tuesday, 21 May 13

34. ¥Ho
24
PlaSorm
accessibility
support
/
seUngs User
profiles
Voice
output Blind,
low
vision,
cogniEve
Zoom Low
vision,
cogniEon,
mobility
Black
&
White,
Inverse
colors,
brightness Low
vision,
cogniEon
Headphone Hearing,
cogniEon
Speak
text Low
vision,
cogniEon
Voice
input Blind,
low
vision,
cogniEon,
mobility
External
&
virtual
keyboards Blind,
mobility
CapEoning Deaf,
cogniEon
Audio
descripEon Blind,
low
vision
Accessibility
sePngs
&
support
Discovery
Tuesday, 21 May 13

35. iOS
Accessibility
features
and
API
are
the
most
mature
Android
has
some
good
accessibility
features
Google
are
working
to
improve
Current
market
share
favours
iOS
and
Android
devices
over
other
vendors
BlackBerry
Curve
smartphones
have
free
BlackBerry
Screen
Reader
Symbian
Phones
have
accessibility
features,
including
text-­‐to-­‐speech,
but
pla@orm
currently
has
no
accessibility
API.
Windows
Phone
8
Phones
appears
to
have
accessibility
features
but
no
accessibility
API
25
Mobile
accessibility
landscape
Discovery
Tuesday, 21 May 13

36. Se[ng User
Voiceover Blind,
low
vision,
learning
and
cogniEon
Zoom,
Large
Text Blind,
low
vision,
learning
and
cogniEon
Invert
colours Low
vision,
colour
blindness,
learning,
cogniEon
Speak
selecEon Low
vision,
learning
and
cogniEon
Speak
auto-­‐text Blind,
low
vision,
learning
and
cogniEon
Hearing
aid
mode Deaf,
hard
of
hearing,
deaf
blind
Guided
access Everybody
including
children
&educaEon
AssisEve
touch Mobility
iOS
accessibility
sePngs
Discovery
Tuesday, 21 May 13

37. Speech
output
Available
in
36
languages
Supports
zoom
and
VoiceOver
iOS6
+
Gesture
and
explore
by
touch
Supports
Braille
output
27
iOS
VoiceOver
Discovery
Tuesday, 21 May 13

38. 1. Triple
click
the
Home
key
to
acEvate
2. Dial
to
open
the
Web
Rotor
3. Swipe
up/down
to
navigate
parts
4. Swipe
right/led
for
next/previous
content
28
iOS
VoiceOver
Discovery
Tuesday, 21 May 13

39. Explore
by
touch
Drag
finger
across
screen
Items
read
by
VO
Double
tap
to
acEvate
Gestures
Swipe
up/down
to
jump
secEons
Swipe
right/led
for
next/previous
content
Rotor
Web
and
Apps:
Lines,
Links,
Form
Controls,
Tables,
Lists,
Landmarks,
Non-­‐Visited
Links,
Bugons,
Text
Fields,
Images,
StaEc
Text,
Zoom,
In-­‐page
links,
Search
Fields,
Same
Item,
Headings,
Speech
Rate,
Volume,
Hints
(on/off),
Characters,
Words,
VerEcal
NavigaEon,
PunctuaEon
Apps:
Headings,
Speech
Rate,
Volume,
Hints
(on/off),
Characters,
Words,
VerEcal
NavigaEon,
PunctuaEon
29
Naviga=ng
with
iOS
VoiceOver
Discovery
Tuesday, 21 May 13

40. 30
iOS
VoiceOver
gestures
Gesture Func)on
Switch
VO
on/off Triple
click
the
home
key
Speak
an
element Single
tap
pAcEvate
an
element Double
tap
Open
the
Rotor Turn
a
dial
Zoom 3
finger
double
tap
-­‐
iOS6+
only
Next
secEon
in
Rotor Swipe
up/down
Next/previous
item
in
content
order Swipe
right/led
Pass
through
gesture
(drag
&
drop) Double
tap
hold
Play/Pause 2
finger
double
tap
Discovery
Tuesday, 21 May 13

41. 31
3
finger
triple
tap
Screen
curtain
Tuesday, 21 May 13

42. 32
iOS
clip
Discovery
Tuesday, 21 May 13

43. Se[ng User
Voice
output Blind,
low
vision,
learning
and
cogniEon
HapEc
feedback Blind,
Deaf-­‐Blind,
Low
vision,
deaf
Large
text Low
vision,
cogniEon,
learning
Speak
passwords Blind,
low
vision,
cogniEon,
learning
Enhance
web
accessibility Blind
Android
accessibility
sePngs
Discovery
Tuesday, 21 May 13

44. Force
enable
zoom
Text
size
Text
scaling
Zoom
on
double-­‐tap
Minimum
font
size
Inverted
colours
Contrast
A
useful
‘screen
curtain’
equivalent
Shades
app
can
also
do
this
34
Android
na=ve
browser
sePngs
Discovery
Tuesday, 21 May 13

45. NaEve
browser
(Webkit)
Poor
support
for
screen
readers
Ideal
Web
Reader
Self
voicing
thin
client
Browser,
text
messages,
contacts,
phone
Chrome
(4+)
Zoom
on
links
Force
enable
zoom
Firefox
Quick
navigaEon
keys
Find
in
page
35
Browsers
on
Android
Discovery
Tuesday, 21 May 13

46. Quick
navigaEon
keys
Requires
a
physical
keyboard,
bluetooth
connected
or
Eyes-­‐free
keyboard
Arrow
around
browser
content
Don’t
work
with
the
browser
UI
Don’t
work
when
focus
is
on
entry
or
password
field
in
a
form
Explore
by
touch
also
supported
36
Firefox
on
Android
Discovery
Tuesday, 21 May 13

47. Support
Gingerbread
2.3-­‐
very
basic
Ice
Cream
Sandwich
4.0
a
bit
beYer
Jelly
Bean
4.1+
much
beYer
Screen
readers
TalkBack
Spiel
Mobile
Speak
Mobile
Reader
All
available
from
the
Play
Store
37
Speech
output
on
Android
Discovery
Tuesday, 21 May 13

48. Pre
Ice
Cream
Sandwich
Download
Talks
Enable
WebScripts
via
Settings >
Accessibility > ‘Enable Accessibility’
Download
the
Eyes
Free
Keyboard
Browsing
Voice
output
sEll
not
well
supported
Can
use
Firefox
for
tesEng
ApplicaEons
Talkback
well
supported
Beware
hybrid
content
Maps,
adverts,
Terms
and
CondiEons,
Help
pages
etc
38
Naviga=ng
with
Android
Talkback
Discovery
Tuesday, 21 May 13

49. 39
Android
clip
Discovery
Tuesday, 21 May 13

50. Play)me!
40
iOS
Triple
click
the
Home
Key
Se[ngs
>
General
Accessibility
>
VoiceOver
ON
Android
Se[ngs
>
Accessibility
>
Talkback
on
Tuesday, 21 May 13

51. How
41
Tuesday, 21 May 13

52. Mobile
website
A
separate
mobile
Website
Different
user
experience
-­‐
good
or
bad
thing?
Responsive
website
A
site
that
adapts
screen
size
and
content
Widest
potenEal
reach
NaEve
app
Pla@orm
specific
applicaEons
Benefits
from
device
capabiliEes
May
contain
Web
content
Beger
accessibility
support
Hybrid
NaEve
and
Web
Easier
to
maintain 42
Delivery
Discovery
Tuesday, 21 May 13

53. Stand-­‐alone
mobile
apps
will
only
be
considered
once
the
core
web
service
works
well
on
mobile
devices,
and
if
specifically
agreed
with
the
Cabinet
Office.
UK
Government
Digital
Strategy
We
are
not
‘appy,
not
‘appy
at
all
43
Tuesday, 21 May 13

54. No
internaEonally
accepted,
independent
set
of
guidelines
(a
la
WCAG)
for
mobile
FragmentaEon
within
mobile
No
‘Baseline
browser’
support
for
mobile
Mobile
Web
Best
PracEces
agempted
it
with
the
Default
Delivery
Context
Usable screen width - 120 pixels, minimum.
Markup language support - XHTML Basic 1.1
Character encoding - UTF-8
Image format support - JPEG GIF 89a.
Maximum total page weight - 20 kilobytes.
Colours - 256 colours, minimum.
Style Sheet Support - CSS Level 1 and CSS Level 2 @media
Scripts - No support for client side scripting.
44
Guidelines
and
resources
Discovery
Tuesday, 21 May 13

55. W3C
WAI
Mobile
Web
Best
PracEces
(MWBP)
Web
Content
Accessibility
Guidlines
(WCAG
Shared
experiences:
Barriers
common
to
mobile
device
users
and
people
with
disabiliEes
Mobile
Accessibility
Overlap
Mapping
between
MWBP
and
WCAG
Independant
User
Interface
(Indi
UI)
Working
Group
-­‐
Indie
Events
1.0
-­‐
Indie
UI
User
Context
1.0
Android
Android
UI
accessibility
Android
Design
Pagerns
Accessibility
Android
Training:
ImplemenEng
Accessibility
Android:
Developing
Accessible
ApplicaEons
Google
Eyes
Free
Project
45
Guidelines
and
resources
Discovery
Tuesday, 21 May 13

56. iOS
iOS
Human
Interface
Guidelines
Accessibility
for
iPhone
and
iPad
apps
by
Mag
Gemmal
Nokia
Nokia
user
experience
for
touch
checklist
(PDF)
Nokia
user
experience
checklist
for
keyboard
Windows
Mobile
Design
Guidelines
for
Windows
Mobile
Touch
InteracEon
Design
OrganisaEonal
Funka.nu
BBC
Mobile
Accessibility
Guidelines
46
Guidelines
and
resources
Discovery
Tuesday, 21 May 13

57. Challenges
2010
Products
developing
in
silos
No
globally
accepted
guidelines
BBC
Accessibility
Standards
and
Guidelines
didn’t
cover
mobile
or
apps
Mobile
more
divers
and
faster
changing
than
desktop
No
graded
mobile
browser
support
(Yahoo!
and
BBC)
EvoluEon
Technology
specific
guidelines
vs
technology
agnosEc
guidelines
Built
around
how
teams
work
Built
to
cross
reference
BBC
Global
Experience
guidelines
and
Editorial
Guidelines
Benefits
Consistency
across
products
Consistency
across
Web,
Hybrid
and
NaEve
apps
Beger
labelling
47
BBC
Mobile
Accessibility
Guidelines
Discovery
Tuesday, 21 May 13

58. 71
technology
agnosEc
standards
and
guidelines
Standard
=
testable
Guidelines
=
not
easily
tested,
aspiraEonal
Technology
specific
techniques
and
examples
HTML
Android
iOS
EvaluaEon
criteria
Steps
VerificaEon
criteria
48
BBC
Mobile
Accessibility
Guidelines
Discovery
Tuesday, 21 May 13

59. Define
a
delivery
context
Mobile
site,
responsive,
app,
hybrid
Define
supported
devices
Reference
pre-­‐exisEng
test
plans
What
devices
have
accessibility
support?
What
devices
have
accessible
naEve
browsers?
What
devices
are
easy
to
upgrade/free
assisEve
support
Are
any
accessible
devices
missing?
Establish
version
support
matrix
Analyse
web
stats
%
users
<
than
1%
Assess
regional
preferences
Assess
laws
Locally
Globally
Research
user
preferences 49
Device
support
plan
Discovery
Tuesday, 21 May 13

60. BB
Decision
Tree
for
Degrada=on
of
Browser
Versions,
BBC
Browser
support
Guidelines
50
Browser
support
Tuesday, 21 May 13

61. 51
Webaim
Screen
Reader
Survey
2012
Discovery
Tuesday, 21 May 13

62. 52
Webaim
Screen
Reader
Survey
2012
Discovery
iOS
device
usage
is
significantly
increasing
and
well
above
the
standard
populaEon
Screen
reader
users
represent
a
notable
porEon
of
the
iOS
device
user
market
Usage
of
Android
devices
is
well
below
that
of
non-­‐disabled
user
In
the
past
17
months:
iOS
devices
increased
from
32.6%
to
58.5%
Android
usage
increased
slightly
from
4%
to
7.9%
Nokia
device
usage
fell
drasEcally
from
42.4%
to
20.3%
Tuesday, 21 May 13

63. 53
Law
Discovery
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”
soluEons
ImplicaEons
North
American
mobile
market
influenEal
globally
Apple,
Google,
Microsod,
RIM
SecEon
508
Refresh
‘informaEon
and
communicaEon
technology’
must
be
WCAG
2.0
compliant
Tuesday, 21 May 13

64. Breakout
session:
Put
together
a
Mobile
Accessibility
Strategy
1.
What
mobile
devices,
plaEorms
and
access
tech
would
you
support?
2.
How
would
you
maintain
and
keep
this
up
to
date?
54
Tuesday, 21 May 13

65. 55
Discovery
Design
&
Build
Deploy
Tuesday, 21 May 13

66. 56
Responsive
design
and
accessibility
‘Responsive’ means design and development should
respond to the person’s behaviour and environment based on
screen size, platform and orientation.
By
definiEon
accessibility
should
be
complemented
by
responsive
design.
What
do
you
think
the
benefits
of
responsive
design
are
on
desktop?
Design
&
Build
Tuesday, 21 May 13

67. 57
Responsive
design
overview
Responsive
design
Creates
a
core
experience
Allows
content
and
funcEonality
to
adapt
to
screen
size
and
device
capability
Uses
CSS3
media
queries
to
enhance
fluid
layouts
One
code
base
Easier
to
maintain
Beger
consistency,
familiarity
and
ease
of
use
Generally
more
task
based
=
geared
towards
diverse
users
Progressive
enhancement
Mobile
first
Data
driven
design
Core
content
is
HTML,
HTML5
Design
&
Build
Tuesday, 21 May 13

68. 58
Responsive
design
overview
Use
Web
Standards
as
intended
Supports
accessibility
Supports
interoperability
For
example
code
a
bugon
as
a
bugon
not
a
styled
link
Screen
readers
announce
traits
i.e.
bugons,
link,
image
etc
User
expectaEon
is
a
link
opens
a
resource,
a
bugon
triggers
an
acEon
On
Desktop
ENTER
is
used
for
links,
SPACEBAR
for
bugons
Use
standard
controls
over
custom
implementaEons
Vulnerable
to
accessibility
failures
e.g.
incorrect
traits
May
require
non
standard
user
input
which
leads
to
usability
fails
for
diverse
users
Detect
features,
not
devices
Design
&
Build
Tuesday, 21 May 13

69. 59www.caniuse.com/waiaria
Tuesday, 21 May 13

70. 60www.caniuse.com/#cats=HTML5
Tuesday, 21 May 13

71. 61
Responsive
design
overview
“Cu[ng
the
mustard”
(BBC
Responsive
news)
Impossible
to
test
across
all
browsers
on
desktop
and
devices
Hard
to
keep
up
-­‐
mobile
contracts
update
every
12-­‐18
months
New
browsers
come
in
to
play
every
day
Websites
accessed
globally
Design
&
Build
HTML5
browsers
IE9+
Firefox
3.5+
Opera
9+
Safari
4+
Chrome
1+(?)
iPhone
and
iPad
iOS1+
Android
phones
and
tablets
2.1+
Blackberry
OS6+
Windows
7.5+
Mobile
Firefox
(all
versions?)
Opera
Mobile
(most
versions?)
HTML4
browsers
IE8-­‐
Blackberry
OS5-­‐
Nokia
S60
v6-­‐
Nokia
S40
(all
versions)
All
other
Symbian
variants
Windows
7
phone
(pre-­‐Mango)
…and
many
more
that
are
too
numerous
to
men=on
Tuesday, 21 May 13

72. 62
iOS
development
overview
Use
standard
UIKit
components
AutomaEcally
accessible
to
VoiceOver
Traits
pre-­‐assigned
Hints,
where
necessary,
pre-­‐assigned
Only
need
to
customise
the
label
UIKit
components
offer
roughly
80%
accessibility.
The
other
20%
is
very
much
around
making
what
is
accessible
usable
Progressively
enhance
with
new
accessibility
features
in
later
versions
Design
&
Build
Tuesday, 21 May 13

73. 63
iOS
development
overview
Interface
Builder,
accessibility
panel
Allows
you
to
enable
accessibility
Add
labels,
traits
and
hints
Design
&
Build
Tuesday, 21 May 13

74. 64
Android
development
overview
Use
standard
library
components
AutomaEcally
accessible
to
TalkBack
Correctly
idenEfied
Only
need
to
customise
the
label
Design
&
Build
Tuesday, 21 May 13

75. 65
Principles
of
mobile
accessibility
(BBC)
Provide
core
content
in
an
accessible
website
Use
apps
on
top
of
this
Use
web
and
pla@orm
standards
as
intended
e.g.
code
links
as
links,
not
bugons
Use
standard
components
NaEvely
accessible
Use
progressive
enhancement
Support
lower
end
devices
Enhance
apps
with
accessibility
improvements
in
device
version
updates
Be
consistent
and
conEnuos
Within
reason,
respect
the
delivery
context
Labels
Design
&
Build
Tuesday, 21 May 13

76. 66
Android
design
principles Design
&
Build
Enchant
me
Delight
me
in
surprising
ways
Real
objects
are
more
fun
than
buYons
and
menus
Let
me
make
it
mine
Get
to
know
me
Simplify
my
life
Keep
it
brief
Pictures
are
faster
than
words
Decide
for
me
but
let
me
have
the
final
say
Only
show
what
I
need
when
I
need
it
I
should
always
know
where
I
am
Never
lose
my
stuff
If
it
looks
the
same
it
should
act
the
same
Only
interrupt
me
if
it’s
importantMake
me
amazing
Give
me
tricks
that
work
everywhere
It’s
not
my
fault
Sprinkle
encouragement
Do
the
heavy
liiing
for
me
Make
important
things
fast
Tuesday, 21 May 13

77. 67
iOS
Human
Interface
Principles Design
&
Build
Aesthe=c
Integrity
Aesthe=c
integrity
is
not
a
measure
of
how
beau=ful
an
app
is.
It’s
a
measure
of
how
well
the
appearance
of
the
app
integrates
with
its
func=on.
Consistency
Consistency
in
the
interface
allows
people
to
transfer
their
knowledge
and
skills
from
one
app
to
another.
A
consistent
app
is
not
a
slavish
copy
of
other
apps.
Direct
manipulaEon
When
people
directly
manipulate
onscreen
objects
instead
of
using
separate
controls
to
manipulate
them,
they're
more
engaged
with
the
task
and
they
more
readily
understand
the
results
of
their
ac=ons
(mul=touch)
hYp://developer.apple.com/library/ios/#documenta=on/userexperience/conceptual/mobilehig/Principles/Principles.html
Tuesday, 21 May 13

78. 68
iOS
Human
Interface
Principles Design
&
Build
Feedback
Feedback
acknowledges
people’s
ac=ons
and
assures
them
that
processing
is
occurring.
People
expect
immediate
feedback
when
they
operate
a
control,
and
they
appreciate
status
updates
during
lengthy
opera=ons.
Metaphors
When
virtual
objects
and
ac=ons
in
an
app
are
metaphors
for
objects
and
ac=ons
in
the
real
world,
users
quickly
grasp
how
to
use
the
app
User
control
People,
not
apps,
should
ini=ate
and
control
ac=ons.
Although
an
app
can
suggest
a
course
of
ac=on
or
warn
about
dangerous
consequences,
it’s
usually
a
mistake
for
the
app
to
take
decision-­‐making
away
from
the
user.
Tuesday, 21 May 13

79. 69
Alterna=ves
Needed
for
Images,
objects,
elements
Media
e.g.
capEons,
audio
descripEon,
transcripts
Editorial
Short,
concise,
descripEve
Important
informaEon
first
Avoid
similar
alternaEves
for
different
funcEonality
e.g.
‘Play’
and
‘Playlist’
FuncEon
over
content
e.g.
‘Contact
us’
not
‘Picture
of
a
mobile
phone’
Describe
image
type
if
appropriate
‘Portrait
of...’
‘Cartoon
of...’
Ownership
Editorial
MarkeEng
-­‐
this
is
branding
ader
all
Design
&
Build
Tuesday, 21 May 13

80. 70
Alterna=ves
&
HTML
Always
provide
an
alt
agribute
alt=”Super useful alt text provided by marketing no
less!”
alt=”” ensures
image
is
ignored
by
assisEve
tech
title
and
abbr
Desktop
Unavailable
to
some
screen
readers
on
desktop
Unavailable
to
keyboard
only
users
Mobile
Unavailable
visually
on
touch
Not
recognised
by
speech
output
on
mobile
Design
&
Build
Tuesday, 21 May 13

81. 71
Alterna=ves
&
Android
Assign
contentDescription
to
all
user
interface
components
e.g.
ImageButton
ImageView
CheckBox
DecoraEve
images
should
not
have
contentDescription
Design
&
Build
Tuesday, 21 May 13

82. 72
Alterna=ves
&
iOS
Implement
basic
accessibility
On
all
meaningful
content
and
funcEonality
Enables
VoiceOver
to
voice
and
interact
with
the
element
via
xCode
a.
Call
the
view’s
setter
method
setIsAccessibilityElement:YES
b.
Override
the
view’s
isAccessibilityElement
method
and
return
YES
via
Interface
Builder,
Accessibility
Panel
a.
Select
the
object
b.
Check
“Accessibility
–
Enabled”
c.
Assign
a
Label
Design
&
Build
Tuesday, 21 May 13

83. 73
Alterna=ves
&
iOS
Assign
accessibilityLabel
to
all
user
interface
components
Must
start
with
a
capital
Must
not
end
with
a
period
(.)
Must
not
include
informaEon
about
the
type
of
object
i.e.
‘Play’
not
‘Play
bugon’
Design
&
Build
Tuesday, 21 May 13

84. 74
Alterna=ves
&
iOS
Assign
accessibilityTrait
to
all
user
interface
components
Traits
describe
control
type
or
behaviour
Control
types
are
mutually
exclusive
and
describe
the
nature
of
the
item
More
than
one
behaviour
trait
can
be
used
to
describe
what
items
do
Design
&
Build
Tuesday, 21 May 13

85. Trait DescripEon
Bugon Used
for
acEons
i.e.
Play,
Add,
Download,
Favourite
Link Use
to
open
views,
pages
resources
Search
field Search
Keyboard
key Used
on
controls
which
insert
predefined
text
for
example
iOS
traits
for
Type Design
&
Build
Tuesday, 21 May 13

86. 76
BuYons
or
links? Design
&
Build
Tuesday, 21 May 13

87. Trait DescripEon
StaEc
text Text
that
is
readable
but
not
selectable
Image If
image
is
interacEve
combine
with
Bugon
or
Link
Plays
sound Used
with
bugon
traits,
mutes
of
reduces
VO
volume
Selected Used
on
checkboxes,
status
read
by
VO
Summary
element Describes
situaEon
or
state
when
an
app
starts,
use
sparingly
Updates
frequently Download
progress
bars,
buffering
Not
enabled Indicates
item
is
not
currently
interacEve
Starts
media
session Silences
Voiceover,
used
when
recording
Adjustable Sliders
e.g.
volume
and
Emeline,
hint
included
iOS
traits
for
Behaviour
Tuesday, 21 May 13

88. Item DescripEon Usage
Magic
tap
accessibilityPerformMagicTap
Two
finger
double
tap
to
perform
a
key
acEon
i.e.
Pause/Play
Trigger
play
from
programme
views,
answer
a
call
Header
accessibilityTraitHeader
Turn
text
into
headings.
Previously
only
view
headings
idenEfied
as
headings
Add
headings
throughout
ALL
pages
Focus
accessibilityLayout
ChangedNoEficaEon
(or
Screen)
Set
focus
on
anything
other
than
first
item
in
content
order
Set
focus
on
the
heading
and
NOT
the
Back/Done
bugons
Announcement
accessibilityAnnouncment
Force
VO
to
say
something
when
an
acEon
is
complete
Visual
cue
also
needed
as
an
alternaEve
for
non
VO
users
Grouping
shouldGroupAccessibilityChildren
Groping
related
items
Parent
child
relaEonships
iOS
traits
for
Behaviour
Tuesday, 21 May 13

89. 79
Alterna=ves
&
Hints
accessibilityHints
may
be
used
to
provide
further
informaEon
Describes
what
an
element
does
Must
not
include
informaEon
about
the
objects
type
(i.e.
Trait)
Use
sparingly
and
not
for
key
informaEon
Must
be
a
descripEon
not
a
command
e.g.
‘Deletes
programme’
not
‘Delete
programme’
Design
&
Build
Tuesday, 21 May 13

90. 80
Label:"Done,"
back"to…."
Trait:"Bu1on"
Label:"[Program"name,"
Episode"number]"
Trait:"Sta>c"text"
Label:"Sub>tles"
On/Off"
Trait:"Bu1on"
Label:"Enter/
Exit"Full"screen"
Trait:"Bu1on"
Label:"Play"/
Pause"
Trait:"Bu1on"
Label:"["00.07"of"59.37"]"swipe"up"or"
down"to"adjust"
Trait:"Adjustable"
Label:"Show/
Hide"more"
Trait:"Bu1on"
iOS
Labels,
Hints
&
Traits Design
&
Build
Tuesday, 21 May 13

91. 81
Tests
-­‐
alterna=ves
Test
01
Switch
on
speech
output
02
Navigate
to
images,
elements
and
objects
either
by
02.1
Explore
by
touch
(Android/iOS)
*
02.2
SelecEng
Images/bugons
from
the
Web
Rotor
and
swiping
up/down
(iOS)*
03
Verify
an
alternaEve
is
provided
04
Verify
the
alternaEve
accurately
describes
the
content
or
funcEon
Expected
results
Each
meaningful
images
element
and
object
has
an
alternaEve
AlternaEves
describe
either
the
content
of
a
non-­‐funcEonal
image,
element
or
object
the
funcEon
of
an
acEonable
image,
element
or
object
Design
&
Build
Tuesday, 21 May 13

92. 82
Colour
&
Contrast
What
is
an
appropriate
contrast
raEo
for
mobile?
WCAG
AA
contrast
of
4.5:1
MWBP
Default
Delivery
Context
-­‐
256
colour
minimum
Nokia
design
guidelines
5:1
BBC
Mobile
Accessibility
Guidelines
exceed
WCAG
AA,
close
to
AAA,
7.1
Challenge
for
RWD
Contrast
raEo
of
7.1
v’s
brand
and
markeEng
Works
beger
on
devices
than
desktop
-­‐
considered
too
restricEve
IndicaEng
links
with
colour
Design
&
Build
Tuesday, 21 May 13

93. 83
Tests
-­‐
colour
contrast
Test
01
Select
samples
of
text
and
links
by
01.1
Checking
contrast
during
UX
(see
0.3)
01.2
Taking
a
screenshot
(Home+power
bugon
on
iOS/
Power
and
volume
bugon
on
Android)
and
email
or
syncing
the
picture
to
a
desktop
Analyser.
03
Verify
the
luminosity
and
contrast
requirements
are
met
via
the
Colour
Contrast
Analyser*
Expected
results
01
Contrast
between
text
and
background
meet
minimum
colour
contrast
(luminosity)
raEo
requirements
indicated
by
the
requirements
*
Any
colour
contrast
checker
can
be
used
but
only
one
used
as
a
benchmark
Design
&
Build
Tuesday, 21 May 13

94. 84
Colour
&
Meaning
Provide
alternaEves
for
colour
and
meaning
Visually
Font
weight
Line
weight
Borders
Gradients
Art
style
Colour
intensity
Subtle
animaEons
Audibly
Announce
changes
of
state
Design
&
Build
“Selected,
TV,
tab,
one
of
5”
Tuesday, 21 May 13

95. Firefox
Mobile
Safari
Colour
&
Meaning Design
&
Build
Tuesday, 21 May 13

96. Firefox
Mobile
Safari
Colour
&
Meaning Design
&
Build
TEST
ON
REAL
DEVICES!
Tuesday, 21 May 13

97. 87
Tests
-­‐
colour
&
meaning
Test
01
AcEvate
speech
output
/
invert
colours
02
Locate
images,
objects
and
elements
that
use
colour
03
Determine
if
colour
is
the
sole
means
of
communicaEng
informaEon
04
Verify
speech
output
announces
the
meaning
conveyed
with
colour
there
is
an
alternaEve
visual
means
of
indicaEng
meaning
Expected
results
Colour
used
to
convey
meaning
is
announced
by
screen
readers
Colour
used
to
convey
meaning
is
indicated
visually
without
colour
Design
&
Build
Tuesday, 21 May 13

98. 88
Touch
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
PosiEoning
Provide
1mm
inacEve
space
around
elements
Balance
enough
informaEon
density
and
targetability
of
UI
Elements
PosiEon
content
appropriately
Design
&
Build
Android
Tuesday, 21 May 13

99. 89
Tests
-­‐
touch
target
size
Test
01
IdenEfy
touch
targets
02
Measure
size
03
Verify
the
size
meets
the
requirements
Expected
results
All
touch
targets
meet
or
exceed
the
minimum
requirement
When
should
this
test
be
carried
out?
Design
&
Build
Tuesday, 21 May 13

100. 90
Touch
Spacing
and
read-­‐tap
symmetry
Balance
informaEon
density
and
targetability
of
UI
Elements
Spacing
between
groups
of
links
e.g.
www.bbc.co.uk/tv
Design
&
Build
Mobile
Desktop
Tuesday, 21 May 13

101. 91
Touch
Group
links
to
the
same
resource
Larger
touch
zone
Less
audible
repeEEon
for
screen
reader
users
Less
swiping
needed
=
less
physical
overhead
Design
&
Build
Tuesday, 21 May 13

102. 92
Touch
Grouped
links
with
HTML
Treated
inconsistently
by
screen
readers
Some
only
announce
the
first
element
Some
only
announce
the
heading
Depends
on
reading
mode
(tabbing,
read
all,
arrowing)
Main
concern
is
VoiceOver
repeats
the
link
Basic
rule:
place
key
informaEon
first
Accessibility
and
HTML5
block
level
links
-­‐
Simply
Accessible
Design
&
Build
<a href="http://feathermelbourne.eventbrite.com/">
<h3 class="summary">Melbourne</h3>
! <span><em>Supported by WIPA</em></span>
! <span>July 25, 2011</span>
! <span class="button">Purchase Tickets</span>
! <img src="star.png" title="Melbourne" alt="" />
</a>
Tuesday, 21 May 13

103. 93
Tests
-­‐
Grouped
links
Test
01
AcEvate
the
screen
reader
02
Navigate
to
acEve
screen
objects,
elements,
and
controls
that
have
textual
and
image
components
03
Verify
that
the
text
is
not
announced
twice
04
Verify
that
there
are
not
two
equivalent
acEonable
items
announced
for
each
item
Expected
results
Object,
elements,
and
controls
with
images
and
text
labels
are
announced
only
together
Design
&
Build
Tuesday, 21 May 13

104. 94
Touch
Consider
reach
One
handed
Important
content
bogom
led
to
right
Design
&
Build
Luke
Wroblewski’s
book
Mobile
First
Tuesday, 21 May 13

105. 95
Best
PracLces:
Designing
Touch
Tablet
Experiences
for
Pre
Schoolers
Source:
hYp://www.sesameworkshop.org/assets/1191/src/Best%20Prac=ces%20Document%2011-­‐26-­‐12.pdf
Tuesday, 21 May 13

106. 96
Touch
-­‐
most
intui=ve
gestures
Tap
Universally
familiar
Draw
/
Move
finger
SomeEmes
hard
not
to
lid
a
finger
Can
also
support
parEal
compleEon
Swipe
Provide
visual
indicaEons
of
where
to
swipe
Consider
using
swipe
and
tap
on
an
arrow
Design
&
Build
xxxx
Tuesday, 21 May 13

107. 97
Touch
-­‐
most
intui=ve
gestures
Drag
Possible
difficulEes
with
on-­‐screen-­‐finger-­‐conEnuity
Can
support
parEal
compleEon
Slide
Less
familiar
than
dragging
Needs
explicit
instrucEons
e.g.,
VO,
strong
visual
indicaEon
of
end
point,
a
large
hotspot,
supporEve/explicit
highlighEng
Design
&
Build
“Familiar
faces
to
take
you
new
places”
Tuesday, 21 May 13

108. 98
Touch
-­‐
least
intui=ve
gestures
Pinch
Needs
good
dexterity
Use
it
on
non-­‐essenEal
acEons
Tilt/Shake
Tablet
size
and
weight
make
it
hard
to
control
Limit
it
to
smaller
devices
MulE-­‐Touch
MulEple
fingers
on
screen
at
once
Oden
used
unintenEonally,
limited
dexterity
Flick/Fling
Use
interchangeably
with
tap/and
or
drag
Double
Tap
Children
expect
immediate
response
Use
it
to
prevent
accidental
navigaEon
e.g.
leaving
an
acEvity
Design
&
Build
Tuesday, 21 May 13

109. 99
Zoom
Support
pinch
zoom
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
orienta=on
Jeremy
Keith
Design
&
Build
Tuesday, 21 May 13

110. 100
Structure
and
content
order
Android
No
means
(that
I
am
aware
of)
to
indicate
headings,
lists
etc
Content
order
needs
to
be
hard
coded
iOS
iOS
3
-­‐
5
only
the
screen
Etle
was
announced
as
a
heading
iOS
6
accessibilityTraitHeader
Content
order
handled
naturally
but
can
be
hard
coded
HTML
Structure
and
content
order
are
a
core
component
accessibility
Same
rules
as
desktop
Design
&
Build
Tuesday, 21 May 13

111. 101
Structure
and
content
order
Headings
and
lists
H1
to
H6
OL
and
UL
NavigaEon
to
headings
and
the
start
of
lists
for
screen
readers
Seven
plus
or
minus
2
The
opEmum
number
humans
process
informaEon
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
Design
&
Build
Tuesday, 21 May 13

112. 102
Structure
and
content
order
WAI
ARIA
Landmarks
application, banner, complementary,
contentinfo, form, main, navigation,
search
NavigaEon
to
parts
of
a
page,
for
screen
reader
HTML5
secEoning
elements
body, section, nav, article, aside,
hgroup, header, footer, address,
main
Not
well
supported
by
desktop
or
mobile
screen
readers
Design
&
Build
Tuesday, 21 May 13

113. 103
Structure
and
content
order
Screen
readers
announce
Landmarks
differently
Jaws
“NavigaEon
region
start”
/
“NavigaEon
region
end”
NVDA
2012.3
“NavigaEon
region
start”
nothing
at
the
end
iOS
VoiceOver
“Landmark
start”
/
“Landmark
end”
but
announces
next
item
in
the
content
order
TalkBack
“NavigaEon”
but
nothing
at
the
end
Design
&
Build
Tuesday, 21 May 13

114. content
a
logical
order
provide
104
Tuesday, 21 May 13

115. provide
a
logical
content
order
105
Don’t
make
your
content
sound
like
Yoda
Tuesday, 21 May 13

116. 106
Iden=fy
Landmarks
Content
order
Place
Landmarks
before
the
relevant
heading
Heading
can
be
visible
or
hidden
aria-­‐label
<role="navigation"
aria-label="Channels">
Design
&
Build
Tuesday, 21 May 13

117. 107
Responsive
landmarks
Tuesday, 21 May 13

118. 108
Responsive
landmarks
Tuesday, 21 May 13

119. 109
Landmarks
&
collapsed
naviga=on
Closed
Open
Design
&
Build
VoiceOver
/
TalkBack
says:
“Landmark
start,
Channels
navigaFon,
Open
Menu,
BBC
One,
BBC
Two,
BBC
Three,
BBC
Four,
TV
Guide,
A-­‐Z,
Categories,
Arts,
CBBC...”
Tuesday, 21 May 13

120. 110
Landmarks
&
collapsed
naviga=on
Closed
Open
Design
&
Build
left: -999em;
position: absolute
VoiceOver
/
TalkBack
says:
“Landmark
start,
Channels
navigaEon,
Open
Menu”
or
“Open
Menu”
Tuesday, 21 May 13

121. 111
Structure
and
content
order
ConsideraEons
for
responsive
Structure
originates
with
UX
(or
we
might
as
well
all
go
home...)
Mobile
first
-­‐
adding
in
is
easier
than
subtracEng
Balance
informaEon
and
verbosity
Annotate
UX
Headings,
lists,
landmarks
Content
and
focus
order
Keyboard
/
swipe
interacEon
Focus
states
Summary
An
H1
follows
role=“main”
and
the
main
content
follows
an
H1
An
H2/3/4 follows
role=“complementary”
An
H2 (3/4) follows
role=“navigation”
Duplicated
links
grouped
in
one
<a href>
Design
&
Build
Tuesday, 21 May 13

122. 112
Responsive
naviga=on
One
Responsive
Barlesque
BBC
Framework
including
the
header
and
footer
Design
&
Build
Tuesday, 21 May 13

123. 113
Responsive
naviga=on
-­‐
case
study
Structure
Landmarks
-­‐
Banner,
NavigaEon
and
Search
Hidden
headings
-­‐
H2
Accessibility
links,
H2
BBC.co.uk
navigaEon
Visible
focus
Strong,
branded
visible
focus
Design
&
Build
Tuesday, 21 May 13

124. 114
Responsive
naviga=on
Issues
Search
repeated
3
times
-­‐
landmark,
label,
placement
text
“BBC.co.uk
navigation”
makes
no
sense
Design
&
Build
Tuesday, 21 May 13

125. 115
Responsive
naviga=on
More
panel
Added
hidden
span
to
“More”
i.e.
“Open
More
BBC
sites”
/
“Close
More
BBC
sites”
Set
focus
to
first
item
in
the
list
“TV”
Panel
remains
open
until
closed
More
is
an
H2
inside
the
panel
Design
&
Build
Tuesday, 21 May 13

126. 116
Responsive
skip
links
Do
they
have
a
place
on
mobile?
On
touch
screens
they
feel
redundant
Not
necessary
for
collapsable
navigation
Possibly
necessary
on
keypad
devices
Design
&
Build
Tuesday, 21 May 13

127. 117
Clear
naviga=on
Page
Etles
content
or
purpose
of
the
screen
Act
as
a
reverse
breadcrumb
Avoid
Done/Back
Design
&
Build
2
3
1
YouTube
iOS
App
Tuesday, 21 May 13

128. 118
Forms
Use
programmaEcally
readable
instrucEons
Add
‘required’
to
the
<label>
<label for="name">Your Name (required)</label>
Progressively
enhance
with
HTML
<input type=“text required>
(iOS5+)
Using
both
techniques
do
not
result
in
‘required’
being
read
twice
Design
&
Build
Tuesday, 21 May 13

129. 119
Keyboard
focus
Don’t
forget
keyboard
users,
D-­‐Pad
users
and
external
keyboard
users
HTML
Provide
a
logical
code
order
PosiEve
and
negaEve
tab
order
not
well
supported
on
iOS
and
Android
Be
aware
of
this
for
responsive
sites
Design
&
Build
Tuesday, 21 May 13

130. 120
Keyboard
focus
-­‐
Android
Enable
focus-­‐based
navigaEon
on
components:
android:focusable="true”
setFocusable
isFocusable
RequestFocus
Force
focus
order
if
it
is
not
logical:
nextFocusDown
nextFocusLeft
nextFocusRight
nextFocusUp
Design
&
Build
Tuesday, 21 May 13

131. 121
Keyboard
focus
-­‐
visible
iOS
No
means
of
providing
a
focus
(that
I’m
aware
of)
Android
Provided
by
default
for
standard
controls
Must
be
added
to
custom
controls
using
style
sheets
state_focused=“true”
HTML,
think
‘focus’
first
a:hover, a:focus, a:active {
background-color: #ff9;
}
Design
&
Build
Tuesday, 21 May 13

132. 122
No=fica=ons
NoEficaEon
may
be
necessary
due
to
Layout
changes
Content
removal
due
to
orientaEon
changes
i.e.
a
menu
opens
in
Layout
List
of
links
may
change
to
drop
downs
Use
standard
platform
notifications
Familiar
behaviour
across
apps
Baked
in
accessibility
Ensure
there
are
both
visual
and
audible
notifications
How
Only
notify
the
user
if
changes
are
not
self
evident
ARIA
announcements
System
alerts
iOS
-­‐
UIAccessibilityLayoutChangedNotification
Android
-­‐
update
the
contentDescription
Design
&
Build
Tuesday, 21 May 13

133. 123
Screen
reader
detec=on
Detect
if
a
screen
reader
is
running
Hide
content
specifically
for
sighted
users
i.e.
splash
screen
instrucEons
Serve
alternaEves
i.e.
a
video
player
that
doesn’t
autoplay
Use
rarely
HTML
Not
possible
iOS
UIAccessibilityIsVoiceoverRunner
Android
isScreenReaderActive
Design
&
Build
Tuesday, 21 May 13

134. Breakout
session:
How
accessible
is
Facebook
and
how
would
you
fix
it?
1.
HTML
2.
Android
3.
iOS
124
Tuesday, 21 May 13

135. 125
Discovery
Design
&
Build
Deploy
Tuesday, 21 May 13

136. 126
Workflow
Discovery
RWD,
hybrid,
naEve
app
etc
Device
support
plan
Test
plan
In
house,
technical,
user,
automated
Secure
and
allocate
budget
early
on
DefiniEon
Requirements
Guidelines:
pre-­‐exisEng,
internal,
customised
Who
owns
what
(originates
with,
implemented
by)
User
stories
Sign
off
process
Training
requirements
Editorial,
UX,
Development,
QA
teams
Deploy
Tuesday, 21 May 13

137. 127
Workflow
DefiniEon
conEnued
Wireframes
Annotate
for
structure,
content
order,
keyboard
interacEon
Done
by
UX
collaboraEng
with
development
UX
Review
and
document
Deploy
DefiniEon
of
Done
-­‐
ensure
accessibility
is
one
aspect
Minimal
Viable
Product
Maintenance
plane
Deploy
Tuesday, 21 May 13

138. 128
Defini=on
of
Done
Code
adheres
to
internal
code
standards
Core
content
adheres
to
accessibility
requirements
Content
passes
Automated
tests
User
tests
Manual
tests
User
Acceptance
Criteria
Core
content
is
available
to
Available
to
screen
readers
Available
with
colours
inverted
Usable
with
zoom
Usable
with
screen
readers
and
zoom
Usable
without
JavaScript
Deploy
Tuesday, 21 May 13

139. 129
Minimal
Viable
Product
All
core
content
and
funcEonality
is
Available
to
screen
readers
Available
with
colours
inverted
Usable
with
zoom
Usable
with
screen
readers
and
zoom
Not
reliant
on
JavaScript
ExempEons
Pixel
perfecEon
FuncEonality
the
offers
an
alternaEve
route
to
already
accessible
core
content
Effects,
animaEons,
transiEons
AddiEonal
features
can
be
added
later
i.e.
font
switchers
if
content
is
already
flexible
“Beauty
is
only
skin
deep”
-­‐
Me
Deploy
Tuesday, 21 May 13

140. 130
My
rule
of
thumb
Any
relaunch
exceeds
exisEng
levels
of
accessibility
Version
one
has
no
Showstopper/Blocker
issues
and
all
other
issues
prioriEsed
in
the
Backlog
Showstopper
=
affects
producEon
so
adversely
that
it
must
be
fixed
or
addressed
immediately
Blocker
=
This
issue
blocks
further
progress
or
another
issue.
It
may
be
blocking
Release
Deploy
Tuesday, 21 May 13

141. 131
Tes=ng
-­‐
HTML
Responsive
design
Hard
to
test
for
all
devices
OpEmise
then
test
on
the
most
common
devices
Tools
FireEyes,
includes
a
responsive
tesEng
features
Default
user
agent
switching
ValidaEng
HTML
WebAim
Toolbar
Deploy
Tuesday, 21 May 13

142. 132
Tes=ng
-­‐
Android
Android
Emulator
Virtual
device
in
Android
SDK
Configurable
to
mimic
different
devices
Contains
a
debug
console
Deploy
Tuesday, 21 May 13

143. 133
Tes=ng
-­‐
Android
Android
Lint
Tool
Finds
missing
ContentDescription
Finds
missing
input
types
on
text
fields
Quick
fix
window
Write
custom
tests
Deploy
Tuesday, 21 May 13

144. Tes=ng
-­‐
Android Deploy
Tuesday, 21 May 13

145. Tes=ng
-­‐
iOS
iOS
Accessibility
Inspector
Displays
accessibility
informaEon
of
accessible
elements
Simulates
Voiceover
interacEon
Runs
in
the
iOS
Simulator
When
running
the
AI
hijacks
single
click
to
focus,
double
click
to
acEvate
A
good
development
tool
but
not
suitable
for
final
tesEng
Deploy
Tuesday, 21 May 13

146. Tes=ng
-­‐
scenarios
Complete
keys
tasks:
with
voice
output
with
zoom
with
voice
output
and
zoom
with
inverse
colours
on
Mobile
Accessibility
tests
Deploy
Tuesday, 21 May 13

147. Switch
off
the
screen
iOS
-­‐
Screen
Curtain
Android
-­‐
browser
se[ngs
>
Brightness
or
use
Shades
Voice
output
tests
Are
images
labelled?
Is
content
order
logical?
Are
changes
of
state
announced?
Are
bugons
used
for
acEons?
Are
links
used
to
open
pages?
Are
form
elements
labelled?
Are
appropriate
keyboards
used?
Tes=ng
screen
reader
support Deploy
Tuesday, 21 May 13

148. Text
is
readable?
Large
areas
of
empty
space
are
not
present?
Labels
and
form
inputs
are
not
separated
by
large
areas
of
empty
space?
Pop
ups
do
not
obscure
the
whole
screen?
Tes=ng
low
vision Deploy
Tuesday, 21 May 13

149. Visible
text
matches
audible
labels?
Bugons,
images
of
text
etc
Is
visible
and
voice
output
focus
are
in
sync?
Tes=ng
zoom
and
voice
output Deploy
Tuesday, 21 May 13

150. Is
text
readable?
There
is
sufficient
contrast?
Visible
navigaEon
cues
are
clear?
Meaning
is
clear?
Tes=ng
inverse
colours Deploy
Tuesday, 21 May 13

151. 01
Establish
a
mobile
accessibility
strategy
02
Define
requirements
(Guideline,
MVP,
DOD)
03
Establish
test
plans
04
Establish
training
needs
05
Map
requirements
to
wireframes
and
UX
Wrap
up Deploy
Tuesday, 21 May 13

152. To
be
con(nued...
henny@iheni.com
142
Tuesday, 21 May 13