Learn how project managers and product managers can ensure their projects are accessible and usable by everyone, including people with disabilities.

1. Angela M. Hooker
Reflections | Projections
Conference
September 2020
How to Put
the “PM” in
Accessibility

2. @AccessForAll
#PMinAccessibility

3. 74%

4. Projects that fail …
74%

5. … of tech projects fail
74%

6. What does
accessibility really
mean, and why is it
important?

7. Whatever the method or
the medium … accessibility
supports everyday living.

8. Meet the OG
Steves and
their life-
changing
contributions…

9. Who and what
disabilities are we
talking about?

10. Disability types
and accessibility
concerns
Deaf and hard-of-hearing
Vision impairments
Cognitive impairments
Dyslexia
Seizure and neurological
Intellectual disabilities
Mental health (general)

11. Disability types
and accessibility
concerns (cont.)
Anxiety and depression
Post-traumatic stress disorder (PTSD)
Motor disability
Autism
Elderly and aging
Situational limitations
Low-language proficiency or non-
native language speakers

12. Your ability to
produce
accessible
works indicates
your skill level
as a PM.

13. Why do you build in
accessibility from
the start?

14. So, how do you build
accessibility into
projects?

15. Get your
leadership’s
support.

16. Work with an
accessibility
consultant.

17. Budget.
Timeline.
People.
Resources.

18. Include
multiple
accessibility
reviews
throughout
your timeline.

19. Put
accessibility
requirements
in your
contracts.

20. Choose
standards
and the level
of
compliance
you’ll achieve.

21. Choose
technologies
carefully.

22. Document all
your team’s
accessibility
work.

23. Get
accessibility
training for
your team.

24. Encourage
innovation.

25. How do you coach
your team and
oversee their work?

26. Start with personas.

27. Content
writers

28. Designers

29. Engineers
and
developers

30. Usability
testing

31. Did I say
documentation?

32. Let’s review.

33. Thank you!
@AccessForAll
linkedin.com/in/angelahooker
angela.m.hooker@gmail.com

34. • Do the technologies you’ve chosen support accessibility?
• Investigate compliance statements.
• Check well-known implementations of those technologies.
• Review these technologies, if needed.
• Is there enough time for accessibility reviews throughout the
project timeline?
• Have you factored in budget for accessibility consultations (if you
need outside help)?
• Have you considered the specific needs of people with each
disability type and people in situational limitations?
Top tasks for PMs (1 of 2)

35. • Choose the accessibility standards you’ll follow for the project.
• Ask potential vendors for proof that they are experienced in
accessibility.
• Include accessibility requirements in requests for proposals,
contracts, statements of work, etc.
• When you select a supplier, state in your contract that they
must give proof that their work conforms to your chosen
accessibility standards when the project is complete.
• State in the contract that your team—and not the supplier—
will have the final say on whether the supplier has met the
standards.
Top tasks for PMs (2 of 2)

36. • Write simply and clearly.
• Use plain language principles.
• Aim for a sixth-grade reading level.
• Consider people with cognitive impairments, low-language
proficiency, mental health concerns, plus non-native language
speakers, neurodiverse people, etc.
• Test your content with people with disabilities; ask if they can
complete a task based on the content.
Top tasks for content writers

37. • Consult user personas before you design.
• After you’ve designed each component, page, etc., work with
your accessibility consultant to map out how people with each
type of access need (and people without access needs) will use
each part of your project’s interface and complete tasks.
• Choose fonts that support the best readability (avoid fonts that
are too thin or ambiguous; avoid too many fonts per page;
remember that font use/repetition conveys structure/hierarchy).
• Watch out for flat design issues. Sometimes the lack of depth
makes it hard to perceive parts of an interface.
• Don’t follow the crowd—innovate!
Top tasks for designers (1 of 2)

38. • Use motion with caution, as it can make some people ill or,
worse, induce seizures.
• Mark up your design for developers. Walk them through each
component/page.
Top tasks for designers (2 of 2)

39. • Work with the designers and the accessibility consultant to plan
for all content states, interactions, etc.
• Use checklists to help you remember accessibility principles, but
know that using a checklist doesn’t make your work accessible.
• Write user stories, related to each accessibility standard in the
Microsoft Accessibility Standards, so that you meet each user
need that each standard addresses.
• Build out the design.
• Use semantic code.
• Code for device and platform independence.
• Support keyboard accessibility.
Top tasks for developers (1 of 2)

40. • Use HTML before relying on other technologies, such as ARIA,
to create compliant works.
• Validate your code to find common errors, or be sure your
development environment checks your code for errors. Don’t
worry about issues that the W3C recommends but validators
mark as errors (including ARIA, CSS, etc.).
• Test your code with accessibility tools throughout your
development process—not just at the end.
Top tasks for developers (2 of 2)

41. • Integrating Accessibility in the Organization’s Web Development Life
Cycle, Denis Boudreau
• Accessibility for Project Managers, Ben Logan
• Just Ask: Integrating Accessibility Throughout Design, Shawn Lawton
Henry
• Managing Accessibility Compliance in the Enterprise, Karl Groves
• (Personas) Understanding Disabilities and Impairments: User Profiles,
GOV.UK
• Do Your D&I Efforts Include People with Disabilities, Harvard Business
Review
• Motivating Accessibility Change, WebAIM
Resources