This document provides an overview of a presentation on integrating accessibility into an organization's web development life cycle. The presentation covers: 1) making the case that accessibility planning is an increasingly important issue due to legal requirements and inclusiveness; 2) how accessibility responsibilities should be shared across roles rather than seen as a separate task; and 3) common pitfalls to avoid, such as treating accessibility as an afterthought or relying too heavily on automated tools.

1. Administrative Track – AccessU 2012
Integrating accessibility in the
organization's Web Development
Life Cycle
John
Sla)n
AccessU
2012
Denis
Boudreau,
AccessibilitéWeb
Aus8n
–
May
15th,
2012
Brought
to
you
by

2. 2012. Some Rights Reserved.
 BY
-­‐
AAribu8on
 NC
-­‐
NonCommercial
 SA
-­‐
ShareAlike
2.5
Canada
Brought
to
you
by
/
2

3. Trainer
Denis
Boudreau

Over
11
years
in
Web
Accessibility

President,
AccessibilitéWeb

Co-­‐editor,
SGQRI
008
standards

Invited
Expert,
W3C
Brought
to
you
by
/
3

4. Summary
General overview
1. Planning
accessibility?!
2. Organiza8onal
change
3. Role-­‐based
accessibility
4. a11y
in
the
produc8on
lifecycle
Brought
to
you
by
/
4

5. Brought
to
you
by
Planning accessibility?!
/
5

6. Planning accessibility?!
An increasingly important issue
Obviously,
it’s
all
about
the
people!
• Catering
for
various
user
needs
• Technologies
have
us
cornered
• Avoiding
them
becomes
increasingly
harder
• Towards
a
more
inclusive
society
But
we
can
skip
this,
right?
Brought
to
you
by
/
6

7. Planning accessibility?!
An increasingly important issue
In
Web
business
today
• Mandatory
requirements
(govt,
legal...)
• What’s
going
on
in:
• Canada
-­‐
federal,
provincial,
CRTC...
• USA
-­‐
sec8on504,
Sec8on508,
ADA...
• The
rest
of
the
world?
• Not
quite
there
yet!
Brought
to
you
by
/
7

8. Planning accessibility?!
An increasingly important issue
Within
organiza)ons
as
well...
• Same
mandatory
requirements
(govt,
legal...)
• Providing
usable
online
services
• Being
the
best
corporate
ci8zens
organiza8ons
can
be
• Avoiding
becoming
the
next
TARGET
(literally!)
• S8ll,
not
quite
there
yet!
Brought
to
you
by
/
8

9. Planning accessibility?!
How do we go about doing this?
Who’s
responsible
for
a11y
in
a
project?
• Most
will
think
it's
a
technological
challenge
• Fewer
think
it's
a
communica8on
concern
• All
are
both
right
AND
wrong
Ul)mately,
who
answers
for
a11y
in
the
organiza)on?
Brought
to
you
by
/
9

10. Planning accessibility?!
Not just an extra requirement to be added
a11y
is
(should
be)
everyone’s
concern
• Everyone,
whether
it’s
IT
or
COM,
has
a
role
to
play
• Exis8ng
stakeholders
need
to
play
their
part
• Assigning
responsibility
to
various
people
• Sharing
the
tasks
to
produce
accessible
results
• Needs
to
be
integrated
in
the
exis8ng
workflow
• Can’t
be
seen
as
just
another
exper8se
to
bring
in
Brought
to
you
by
/
10

11. Planning accessibility?!
Avoiding the common accessibility pitfalls
Some
piOalls
worth
avoiding
• Ignore
the
tranversal
aspect
of
accessibility
• View
accessibility
as
a
final
quality
control
step
• Rely
on
a
champion
instead
of
team
efforts
• Care
about
the
checklist
and
nothing
else
• Expec8ng
automated
tools
to
do
the
work
• Underes8mate
the
technological
plakorm
impacts
Brought
to
you
by
/
11

12. Planning accessibility?!
The accessibility expert to the rescue!
a11y:
what
organiza)ons
usually
do
• Consider
the
accessibility
requirements
• Develop
the
project
(and
hope
for
the
best)
• Make
sacrifices
and
concessions
all
along
• Call
for
an
audit
at
the
very
end
of
the
project
• Ask
for
confirma8on
on
the
efforts
that
were
made
• Cross
their
fingers
(and
again,
hope
for
the
best)
Brought
to
you
by
/
12

13. Planning accessibility?!
The accessibility expert to the rescue!
a11y:
what
organiza)ons
usually
get
• A
100+
page
report
on
the
project’s
conformance
level
• Countless
recommenda8ons
for
a11y
remedia8on
• A
biAer
feeling
of
general
failure
despite
all
efforts
• Frustra8on,
anger
-­‐
possibly
harsh
consequences
too
• If
lucky,
a
few
empathe8c
good
words
(no
extra
charge)
Brought
to
you
by
/
13

14. Planning accessibility?!
What it all comes down to
Accessibility
doesn’t
just
happen
• It
needs
to
be
planned
from
the
start
to
happen
• There’s
only
so
much
you
can
achieve
“by
accident”
• Seman8c
HTML
+
CSS
can
only
get
you
so
far
• But
what
about:
• Keyboard
naviga8on,
user
tes8ng,
color
choices?
• The
underlying
technology
the
project
is
based
on?
Brought
to
you
by
/
14

15. Planning accessibility?!
The Quebec government 2006 audit
Establishing
metrics
• Prior
to
deciding
the
government
needed
a
standard
• Asked
to
measure
the
conformance
level
of
20
sites
• Results
showed
accessibility
features
naturally
caps
• Easy
wins:
seman8c
structure,
valid
html,
css
layout
• Harder
gains:
screen
reader
support,
keyboard
nav
• a11y
compliance
is
something
one
needs
to
work
for
Brought
to
you
by
/
15

16. Planning accessibility?!
What it all comes down to
Accessibility
work
usually
means...
• Being
asked
to
work
on
contents:
• That
were
never
really
meant
to
be
accessible
• That
were
never
planned
appropriately
• That
were
always
looked
at
from
a
single
perspec8ve
• That
were
based
on
flawed
technologies
from
day
1
Brought
to
you
by
/
16

17. Planning accessibility?!
What it all comes down to
Accessibility
work
usually
means...
• Being
asked
to
work
against:
• Organiza8on
status
quo
• Stakeholders
on
the
defensive
(and
righkully
so)
• Impossible
or
immutable
deadlines
• With
limited
or
non
existent
budgets
Brought
to
you
by
/
17

18. Planning accessibility?!
What it all comes down to
And
we
really
wonder
why
there
are
so
FEW
good
examples
of
aTrac)ve,
accessible
websites?
Can
we
even
name
five
“serious”
websites
today?
Brought
to
you
by
/
18

19. Planning accessibility?!
Changing all that around
Good
news
is,
this
can
all
change
today!
• So
what
needs
to
be
done
to:
• Reach
standards
compliancy?
• Improve
user
access
to
content?
• Overcome
this
challenge
on
a
budget?
• Tackle
accessibility
once
and
for
all?
• Come
out
of
this
one
piece?
Brought
to
you
by
/
19

20. Planning accessibility?!
A governance issue, first and foremost
a11y
is
NOT
a
technical
issue
(that’s
easy)
• Accessibility
is
primarily
a
governance
issue
• The
organiza8on
needs
to:
• Realize
that
a11y
only
reveals
deeper,
broader
issues
• Iden8fy,
prevent
and
avoid
the
common
pikalls
• Embrace
inclusion
has
a
corporate
value
• Provide
its
resources
with
the
necessary
means
Brought
to
you
by
/
20

21. Planning accessibility?!
A governance issue, first and foremost
Yes,
this
will
mean
money.
Maybe
even
lots
of
it.
Sorry
if
I’m
burs)ng
bubbles.
Brought
to
you
by
/
21

22. Planning accessibility?!
A governance issue, first and foremost
Real
life
experiences
• A
recent
accessibility
project
in
the
banking
world
• How
we
went
from:
• “WCAG
2.0
AA”
to
“DBM
1.0”
(doing
bare
minimum)
• Everybody
was
super
mo8vated
and
willing!
• Middle
management
were
really
suppor8ve!
• Most
people
were
even
thrilled!
Brought
to
you
by
/
22

23. Planning accessibility?!
A governance issue, first and foremost
Can
anybody
guess
what
happened?
Brought
to
you
by
/
23

24. Planning accessibility?!
A governance issue, first and foremost
Life
happened.
From
WCAG
2.0
to
“DBM
1.0”
• A
combina8on
of
factors:
• Tight,
hard,
immutable
deadlines
• Misunderstanding
from
upper
management
• Lower
than
expected
legal
requirements
• Unexpected
impacts
on
the
budget
• Lack
of
communica8on
between
team
leaders
• False
impression
that
“this
accessibility
stuff
is
easy”
• Accessibility
audit
results
showing
otherwise...
Brought
to
you
by
/
24

25. Planning accessibility?!
A catalyst for change
Web
accessibility
as
a
catalyst
for
change
• Takes
more
than
just
goodwill
to
make
it
happen
• Upper
management
has
a
huge
role
to
play
• Changes
need
to
be
made
for
a11y
to
be
successful
• People
need
to
accept
and
embrace
these
changes
• Accessibility
as
a
springboard
for
a
larger
cultural
shis
• This
means
“figh8ng”
a
natural
resistance
to
change
Brought
to
you
by
/
25

26. Brought
to
you
by
Organizational change
/
26

27. Organizational change
Organizational change 101
Accessibility
calls
for
profound
habit
changes
• Organiza8ons
aren’t
used
to
consider
the
extra
costs
• Training,
longer
delays,
addi8onal
QA
tes8ng...
• People
aren’t
used
to
having
their
skills
challenged
• Loss
of
control,
frustra8on,
anxiety,
self-­‐confidence...
• Unbalancing
the
ecosystem
inevitably
brings
resistance
Brought
to
you
by
/
27

28. Organizational change
Organizational change 101
The
five
stages
of
accessibility
• Denial
• Anger
• Bargaining
• Depression
• Acceptance
Brought
to
you
by
/
28

29. Organizational change
Organizational change 101
The
process
of
aligning
how
people
work
and
behave
to
fit
specific
changes
in
business
Current
Transi8on
New
strategy,
organiza8onal
State
State
structure
or
systems.
(as
is)
Increasing
comfort,
(to
be)
control
&
confidence
Helps
organiza8ons
successfully
transi8on
from
a
current
state
to
a
new,
desired
state.
Brought
to
you
by
/
29

30. Organizational change
Organizational change 101
This
is
why
accessibility
calls
for
profound
change
management
and
cultural
shi_s
in
organiza)ons
for
things
to
run
smoothly.
Brought
to
you
by
/
30

31. Organizational change
Organizational change 101
How
most
people
resist
change
• Confronta)on
-­‐
direct
inadmissibility
of
the
change
• Rejec)on
-­‐
fear
of
losing,
anxiety
towards
change
• Avoidance
-­‐
lack
of
mo8va8on
towards
change
• Faking
-­‐
seemingly
adop8ng
without
implemen8ng
Brought
to
you
by
/
31

32. Organizational change
Organizational change 101
Most
people
will
naturally
resist
change
• Four
typical
answers
to
change
include:
• The
cri)c
-­‐
who
opposes
the
change
• The
vic)m
-­‐
who
panics
in
front
of
the
change
• The
bystander
-­‐
who
ignores
the
change
• The
navigator
-­‐
who
is
empowered
by
the
change
Brought
to
you
by
/
32

33. Organizational change
Organizational change 101
Helping
people
become
navigators
is
the
key
• Things
we
know
will
help:
• Communicate
the
threat
of
not
changing
• Involve
team
in
decision
making
(where
possible)
• Minimize
uncertainty
as
much
as
possible
• Celebrate
successes
in
moving
towards
the
goal
• Keep
explaining
why
the
organiza8on
is
changing
• Be
as
transparent
as
possible
in
applying
the
changes
Brought
to
you
by
/
33

34. Organizational change
Organizational change 101
For
people
to
willingly
go
on
with
the
change,
they
must
understand
what’s
in
it
for
them.
Brought
to
you
by
/
34

35. Organizational change
Organizational change 101
Helping
people
view
change
as
an
opportunity
• Involve
the
team
early
on
in
the
process
• Create
opportuni8es
for
people
to
rise
up
• Communicate
constantly
on
milestones
• Plan
properly
from
the
very
start
• Don’t
ever
let
up
-­‐
always
keep
the
pace
Organiza)ons
who
fail
to
do
this
make
change
become
a
burden.
Brought
to
you
by
/
35

36. Organizational change
Organizational change portfolio
Handling
the
4
streams
• Communica8on
stream
• Learning
stream
• Organiza8on
stream
• Performance
stream
Credit:
Luc
Galoppin,
2008
Brought
to
you
by
/
36

37. Organizational change
Organizational change portfolio
Communica)on
stream
• Not
change
progaganda
• Manage
expecta8ons
and
support
change
during
its
complete
lifecycle
• Stay
in
touch
with
the
team
• Answer
very
simple
ques8ons:
“who
are
we?”
(iden8ty)
and
“what
are
we
here
for?”
(what’s
in
it
for
me)
Credit:
Luc
Galoppin,
2008
Brought
to
you
by
/
37

38. Organizational change
Organizational change portfolio
Learning
stream
• Upgrade
the
knowledge
and
skillsets
of
the
organiza8on
in
terms
of
context
(why),
content
(what),
ac8ons
(how)
• Address
three
basic
ques8ons:
mo8va8on,
knowledge,
skills
• Go
beyond
the
classroom
and
aim
for
learning
rather
than
just
training
Credit:
Luc
Galoppin,
2008
Brought
to
you
by
/
38

39. Organizational change
Organizational change portfolio
Organiza)on
stream
• Define
and
implement
a
new
organiza8on
structure
that
reflects
the
changes
at
hand
• Define
and
establish
new
work
responsilibi8es
in
order
to
make
the
change
happen
• Provide
concrete
support
from
the
organiza8on
(winning
condi8ons)
Credit:
Luc
Galoppin,
2008
Brought
to
you
by
/
39

40. Organizational change
Organizational change portfolio
Performance
stream
• Translate
the
principles
of
the
business
case
(accessibility)
into
concrete
new
ways
of
working
within
the
team
• Include
detailed
work
instruc8ons
for
expected
changes
• Establish
meaningful
and
measurable
goals
Credit:
Luc
Galoppin,
2008
Brought
to
you
by
/
40

41. Brought
to
you
by
a11y in the41
/
production lifecycle

42. Web development lifecycle
Moving forward with accessibility
Planning
accessibility
in
the
lifecycle
• Spreading
requirements
over
the
whole
team
• Prevent
clueless
errors
and
expensive
omissions
• Provide
clear,
defined
paAerns
and
strategies
• a11y
should
be
about
teamwork
and
workflow
• Collec8ve
ownership
of
a11y
requirements
• Dropping
the
silos
and
really
working
together
Brought
to
you
by
/
42

43. Web development lifecycle
What this comes down to
Efficiently
integra)ng
accessibility
within
the
development
lifecycle
is
all
about
being
able
to
plan
the
right
interven)on,
at
the
right
)me,
by
the
right
people.
Brought
to
you
by
/
43

44. Web development lifecycle
Spreading responsibilities evenly
Making
the
accessibility
goal
a
team
effort
• Involvement
of
the
whole
team
• Turning
this
into
a
posi8ve
pursuit
of
quality
• Breaking
down
the
requirements
into
exis8ng
roles
• Working
with
the
forces
available
• Never
trying
to
reinvent
the
wheel
• Benefiung
from
the
already
available
exper8se
• The
best
resources
for
the
job
are
already
out
there
Brought
to
you
by
/
44

45. Web development lifecycle
A lot cheaper to get it right the first time!
To
prevent,
rather
than
to
cure
• Planning
a11y
properly
brings:
• More
efficient
use
of
everyone's
8me
• Significant
reduc8ons
in
terms
of
costs
• Significant
benefits
in
produc8on
• Significant
gains
in
customer
and
internal
rela8ons
• Integra8ng
a11y
as
part
of
the
organiza8on's
culture
• So
exper8se
remains
when
resources
leave
Brought
to
you
by
/
45

46. Brought
to
you
by
Role-based accessibility
/
46

47. Role-based accessibility
A generic model - overview
Typical
web
development
lifecycle
AN
AR
ID
GD
CS
SE
PR
FE
BE
QA
MA
Project
Management
AN
-­‐
Analysis
PR
-­‐
HTML/CSS
prototyping
AR
-­‐
Architecture
FE
-­‐
Front
end
development
ID
-­‐
Interac8on
design
BE
-­‐
Back
end
development
GD
-­‐
Graphics
design
QA
-­‐
Quality
control
CS
-­‐
Content
strategy
MA
-­‐
Maintenance
SE
-­‐
Search
engine
op8miza8on
Brought
to
you
by
/
47

48. Role-based accessibility
Putting it all together
A
few
ques)ons
to
ask
ourselves
• How
do
various
stakeholders
relate
to
accessibility?
• Who
“owns”
a
specific
accessibility
requirement?
• How
can
accessibility
requirements
be
shared?
• How
can
I
adapt
a
generic
model
to
my
organiza8on?
Brought
to
you
by
/
48

49. Role-based accessibility
A generic model - overview
a11y
and
the
analysis
phase
AN
AR
ID
GD
CS
SE
PR
FE
BE
QA
MA
Project
Management
Covers
tasks
and
related
quality
control
normally
associated
with
analysis
of
the
project’s
strategic
orienta8ons,
analysis
of
the
op8ons
for
technology
plakorms,
or
func8onal
analysis
of
Web
interfaces.
Brought
to
you
by
/
49

50. Role-based accessibility
A generic model - overview
a11y
and
the
analysis
phase
Principles
Applicable
Success
Criteria
Level
A
Level
AA
Level
AAA
Perceivable
-­‐-­‐
-­‐-­‐
-­‐-­‐
Operable
-­‐-­‐
-­‐-­‐
2.2.3,
2.2.4,
2.2.5
Understanding
3.2.1,
3.3.1
3.3.3,
3.3.4
3.3.5,
3.3.6
Robust
-­‐-­‐
-­‐-­‐
-­‐-­‐
Total
(9)
2
2
5
Brought
to
you
by
/
50

51. Role-based accessibility
A generic model - overview
a11y
and
the
architecture
phase
AN
AR
ID
GD
CS
SE
PR
FE
BE
QA
MA
Project
Management
Covers
tasks
and
related
quality
control
normally
associated
with
the
architecture
of
the
informa8on
(web
content)
and
the
architecture
of
the
data.
Brought
to
you
by
/
51

52. Role-based accessibility
A generic model - overview
a11y
and
the
architecture
phase
Principles
Applicable
Success
Criteria
Level
A
Level
AA
Level
AAA
Perceivable
1.3.1
-­‐-­‐
-­‐-­‐
Operable
2.4.2
2.4.5,
2.4.6
2.4.8,
2.4.10
Understanding
-­‐-­‐
3.1.2
3.1.3,
3.1.4
Robust
-­‐-­‐
-­‐-­‐
-­‐-­‐
Total
(9)
2
3
4
Brought
to
you
by
/
52

53. Role-based accessibility
A generic model - overview
a11y
and
the
interac)on
design
phase
AN
AR
ID
GD
CS
SE
PR
FE
BE
QA
MA
Project
Management
Covers
tasks
and
related
quality
control
normally
associated
with
the
planning
of
web
interfaces,
content
changes,
interac8vity
and
other
interface-­‐related
contents
of
the
pages.
Brought
to
you
by
/
53

54. Role-based accessibility
A generic model - overview
a11y
and
the
interac)on
design
phase
Principles
Applicable
Success
Criteria
Level
A
Level
AA
Level
AAA
Perceivable
1.3.1,
1.3.3,
1.4.1,
1.4.2
1.4.4
1.4.7,
1.4.8
Operable
2.1.1,
2.1.2,
2.2.1,
2.2.2,
2.4.5,
2.4.6
2.1.3,
2.2.3,
2.2.4,
2.2.5,
2.3.1,
2.4.4
2.3.2,
2.4.8,
2.4.9
Understanding
3.2.1,
3.2.2,
3.3.1,
3.3.2
3.2.3,
3.2.4,
3.3.3,
3.3.4
3.1.3,
3.1.5,
3.2.5,
3.3.5,
3.3.6
Robust
4.1.2
-­‐-­‐
-­‐-­‐
Total
(36)
15
7
14
Brought
to
you
by
/
54

55. Role-based accessibility
A generic model - overview
a11y
and
the
graphics
design
phase
AN
AR
ID
GD
CS
SE
PR
FE
BE
QA
MA
Project
Management
Covers
tasks
and
related
quality
control
normally
associated
with
the
graphic
design
of
interfaces,
the
related
graphic
declina8ons,
the
specific
design
of
naviga8on
elements,
context
changes
and
other
general
design
of
the
main
content
of
the
pages.
Brought
to
you
by
/
55

56. Role-based accessibility
A generic model - overview
a11y
and
the
graphics
design
phase
Principles
Applicable
Success
Criteria
Level
A
Level
AA
Level
AAA
Perceivable
1.3.1,
1.3.3,
1.4.1,
1.4.2
1.4.3,
1.4.4,
1.4.5
1.4.6,
1.4.7,
1.4.8,
1.4.9
Operable
2.1.1,
2.1.2,
2.2.2,
2.3.1,
2.4.5,
2.4.6,
2.4.7
2.2.3,
2.2.4,
2.3.2,
2.4.8
2.4.1
Understanding
3.2.1,
3.3.1,
3.3.2
3.2.3,
3.2.4,
3.3.3
3.2.5,
3.3.5,
3.3.6
Robust
-­‐-­‐
-­‐-­‐
-­‐-­‐
Total
(32)
12
9
11
Brought
to
you
by
/
56

57. Role-based accessibility
A generic model - overview
a11y
and
the
content
strategy
phase
AN
AR
ID
GD
CS
SE
PR
FE
BE
QA
MA
Project
Management
Covers
tasks
and
related
quality
control
normally
associated
with
producing
the
site’s
textual
contents,
equivalent
alterna8ve
for
non-­‐text
content
and
other
general
text
elements
presented
in
the
pages.
Brought
to
you
by
/
57

58. Role-based accessibility
A generic model - overview
a11y
and
the
content
strategy
phase
Principles
Applicable
Success
Criteria
Level
A
Level
AA
Level
AAA
Perceivable
1.1.1,
1.2.1,
1.2.2,
1.2.3,
1.2.5
1.2.7,
1.2.8
1.3.1,
1.3.3
Operable
2.1.1,
2.1.2,
2.4.2,
2.4.4
2.4.6
2.4.9
Understanding
3.3.1
3.1.2
3.1.3,
3.1.4,
3.1.5,
3.1.6
Robust
-­‐-­‐
-­‐-­‐
-­‐-­‐
Total
(21)
11
3
7
Brought
to
you
by
/
58

59. Role-based accessibility
A generic model - overview
a11y
and
the
search
engine
op)miza)on
phase
AN
AR
ID
GD
CS
SE
PR
FE
BE
QA
MA
Project
Management
Covers
tasks
and
related
quality
control
normally
associated
with
providing
text
equivalents
for
non-­‐text
contents
and
making
contents
on
a
web
page
more
easily
indexable
by
search
engines.
Brought
to
you
by
/
59

60. Role-based accessibility
A generic model - overview
a11y
and
the
search
engine
op)miza)on
phase
Principles
Applicable
Success
Criteria
Level
A
Level
AA
Level
AAA
Perceivable
1.1.1,
1.2.1,
1.2.2,
1.2.3,
1.2.4,
1.2.5,
1.4.5
1.2.6,
1.2.7,
1.2.8,
1.2.9
1.3.1
Operable
2.1.1,
2.1.2,
2.2.1,
2.2.2,
2.4.5,
2.4.6,
2.4.7
2.1.3,
2.2.3,
2.4.8,
2.4.9,
2.4.1,
2.4.2,
2.4.3,
2.4.4
2.4.10
Understanding
-­‐-­‐
-­‐-­‐
-­‐-­‐
Robust
-­‐-­‐
-­‐-­‐
-­‐-­‐
Total
(28)
14
6
9
Brought
to
you
by
/
60

61. Role-based accessibility
A generic model - overview
a11y
and
the
HTML/CSS
prototyping
phase
AN
AR
ID
GD
CS
SE
PR
FE
BE
QA
MA
Project
Management
Covers
tasks
and
related
quality
control
normally
associated
with
the
produc8on
of
all
web
site
master
templates
(HTML
and
CSS).
Brought
to
you
by
/
61

62. Role-based accessibility
A generic model - overview
a11y
and
the
HTML/CSS
prototyping
phase
Principles
Applicable
Success
Criteria
Level
A
Level
AA
Level
AAA
Perceivable
1.1.1,
1.3.1,
1.3.2
1.4.3,
1.4.4,
1.4.5
1.4.6
Operable
2.1.1,
2.1.2,
2.4.1,
2.4.2,
2.4.5,
2.4.6,
2.4.7
2.1.3,
2.4.8,
2.4.10
2.4.3
Understanding
3.1.1,
3.3.2
3.2.4
3.1.3,
3.2.5
Robust
4.1.1,
4.1.2
-­‐-­‐
-­‐-­‐
Total
(25)
12
7
6
Brought
to
you
by
/
62

63. Role-based accessibility
A generic model - overview
a11y
and
the
front
end
development
phase
AN
AR
ID
GD
CS
SE
PR
FE
BE
QA
MA
Project
Management
Covers
tasks
and
related
quality
control
normally
associated
with
the
development
of
contribu8on
tools,
HTML
and
CSS
integra8on,
and
the
programming
of
proposed
scripts
and
applica8ons
on
the
web
site.
Brought
to
you
by
/
63

64. Role-based accessibility
A generic model - overview
a11y
and
the
front
end
development
phase
Principles
Applicable
Success
Criteria
Level
A
Level
AA
Level
AAA
1.1.1,
1.2.1,
1.2.2,
1.2.3,
1.3.1,
1.2.4,
1.2.5,
1.4.3,
1.4.4,
1.4.5
1.2.6,
1.2.7,
1.2.8,
1.2.9,
1.4.6,
Perceivable
1.3.2,
1.3.3,
1.4.1,
1.4.2
1.4.7,
1.4.8,
1.4.9
2.1.1,
2.1.2,
2.2.1,
2.2.2,
2.3.1,
2.4.5,
2.4.6,
2.4.7
2.1.3,
2.2.3,
2.2.4,
2.2.5,
2.3.2,
Operable
2.4.1,
2.4.2,
2.4.3,
2.4.4
2.4.8,
2.4.9,
2.4.10
3.1.1,
3.2.1,
3.2.2,
3.3.1,
3.3.2
3.1.2,
3.2.3,
3.2.4,
3.3.3,
3.3.4
3.1.3,
3.1.4,
3.1.6,
3.2.5,
3.3.5,
Understanding
3.3.6
4.1.1,
4.1.2
-­‐-­‐
-­‐-­‐
Robust
Total
(60)
25
13
22
Brought
to
you
by
/
64

65. Role-based accessibility
A generic model - overview
a11y
and
the
back
end
development
phase
AN
AR
ID
GD
CS
SE
PR
FE
BE
QA
MA
Project
Management
Covers
tasks
and
related
quality
control
normally
associated
with
the
development
of
server
side
programing
and
database
management.
Brought
to
you
by
/
65

66. Role-based accessibility
A generic model - overview
a11y
and
the
back
end
development
phase
Principles
Applicable
Success
Criteria
Level
A
Level
AA
Level
AAA
Perceivable
1.1.1,
1.3.1,
1.3.2
-­‐-­‐
-­‐-­‐
Operable
2.1.1,
2.1.2,
2.2.1,
2.2.2,
2.4.5,
2.4.6,
2.4.7
2.1.3,
2.2.3,
2.2.4,
2.2.5,
2.4.3,
2.4.4
2.4.9,
2.4.10
Understanding
3.2.1,
3.2.2,
3.3.1,
3.3.2
3.1.2,
3.2.4,
3.3.3,
3.3.4
3.1.3,
3.1.4,
3.2.5,
3.3.6
Robust
4.1.1,
4.1.2
-­‐-­‐
-­‐-­‐
Total
(32)
15
7
10
Brought
to
you
by
/
66

67. Role-based accessibility
A generic model - overview
a11y
and
the
quality
control
phase
AN
AR
ID
GD
CS
SE
PR
FE
BE
QA
MA
Project
Management
Covers
tasks
normally
associated
with
general
valida8ons
at
the
very
end
of
the
project,
before
launching.
Brought
to
you
by
/
67

68. Role-based accessibility
A generic model - overview
a11y
and
the
quality
control
phase
Principles
Applicable
Success
Criteria
Level
A
Level
AA
Level
AAA
1.1.1,
1.2.1,
1.2.2,
1.2.3,
1.3.1,
1.2.4,
1.2.5,
1.4.3,
1.4.4,
1.4.5
1.2.6,
1.2.7,
1.2.8,
1.2.9,
1.4.6,
Perceivable
1.3.2,
1.3.3,
1.4.1,
1.4.2
1.4.7,
1.4.8,
1.4.9
2.1.1,
2.1.2,
2.2.1,
2.2.2,
2.3.1,
2.4.5,
2.4.6,
2.4.7
2.1.3,
2.2.3,
2.2.4,
2.2.5,
2.3.2,
Operable
2.4.1,
2.4.2,
2.4.3,
2.4.4
2.4.8,
2.4.9,
2.4.10
3.1.1,
3.2.1,
3.2.2,
3.3.1,
3.3.2
3.1.2,
3.2.3,
3.2.4,
3.3.3,
3.3.4
3.1.3,
3.1.4,
3.1.5,
3.1.6,
3.2.5,
Understanding
3.3.5,
3.3.6
4.1.1,
4.1.2
-­‐-­‐
-­‐-­‐
Robust
Total
(61)
25
13
23
Brought
to
you
by
/
68

69. Role-based accessibility
A generic model - overview
a11y
and
the
project
management
phase
AN
AR
ID
GD
CS
SE
PR
FE
BE
QA
MA
Project
Management
Integra8ng
the
concept
of
transversality,
planning
accessibility
at
each
step,
alloca8ng
responsibili8es,
ensuring
the
criteria
are
met
at
every
milestone,
understanding
the
difference
between
accessible
and
conforming
content,
being
aware
of
the
tools’
limita8ons
and
working
around
them,
assessing
the
impact
of
technology
plakorms
on
the
overall
project.
Brought
to
you
by
/
69

70. Role-based accessibility
A generic model - overview
a11y
and
the
maintenance
phase
AN
AR
ID
GD
CS
SE
PR
FE
BE
QA
MA
Project
Management
Making
sure
that
all
relevant
knowledge
transfer
from
the
produc8on
team
is
passed
on
to
the
maintenance
team,
so
the
accessibility
efforts
put
into
the
project
dont
start
degrading
the
minute
content
is
being
updated
on
the
website.
Adap8ng
the
workflow
to
the
reality
of
the
maintenance
team,
based
on
the
roles
defined
previously.
Brought
to
you
by
/
70

71. WAI-Engage Wiki
Accessibility Responsibility Breakdown
Role-­‐based
accessibility
• Looking
at
WCAG
2.0
SC
by
roles
• Get
involved
in
the
community:
comment,
contribute,
use
• Make
this
your
own
and
bring
it
into
your
organiza8on!
• hAp://is.gd/5CoJd4
Brought
to
you
by
/
71

72. Summing it up
Integrate a11y at every step of the process
Get
subject
maTer
experts
in
your
lifecycle
to
integrate
a11y
in
their
work
so
the
right
ques)ons
are
being
asked
at
the
right
)me
by
the
right
people.
• Planning
a11y
from
the
very
early
stages
• Planning
sufficient
and
consistent
support
• Itera8ves
rounds
of
a11y
valida8on
to
remain
on
target
• From
ini8al
wireframes
to
final
html
templates
• Recommenda8ons
to
guide
the
remedia8on
process
• Ensure
autonomy
through
knowledge
transfer
Brought
to
you
by
/
72

73. Thank You!
Denis
Boudreau,
President
Coopéra)ve
AccessibilitéWeb
1751
Richardson
street,
suite
6111
Montreal
(Quebec),
Canada
H3K
1G6
Toll
Free:
+1
(877)
315-­‐5550
Email:
db@csaw.ca
Web:
www.accessibiliteweb.com
TwiAer
:
@AccessibiliteWb
/
@dboudreau
Brought
to
you
by
/
73