Presented by Mark Sadecki and Ari Rizzitano at CSUN ATC 2018.

1. Building an
Accessible
Component Library
Ari Rizzitano and Mark Sadecki
CSUN Assistive Technology Conference
March 23, 2018

2. Introductions
Ari Rizzitano
@arizzitano
Mark Sadecki
@cptvitamin

3. Why Components?
Best Practices
Developer Toolkit
Driving Adoption

4. Why
Components?

5. Our Accessibility
Journey

6. DOJ
Legal
Agreement
Front-loaded
Deliverables
Aggressive
Deadlines
Audits
Reporting
Bug
Identification
Bug
Remediation

7. Phase 1:
Achieve Conformance
Phase 2:
Maintain Conformance

8. “We ship too
many a11y bugs.”

9. “A11Y fixes are hard
and take too long.”

10. “Developers don’t
know how to write
compliant code.”

11. “Can’t we just
hire one expert
to do it all?”

13. “Why do we have 6
different modals?”

14. “Wash, Rinse, Repeat”

15. Enter: the
component
library

16. Modularity

17. Modularity
•UX and brand consistency
•Faster, easier bugfixes
•No reinventing the wheel

18. Encapsulation

19. Encapsulation
•Easier to develop and test
•Consumable by multiple
applications or services
•Highly dynamic functionality
lives in one place

20. Learning

21. Learning
•Lower barrier to entry
•Code shared across teams
•Motivation to help other devs
•Easier to review

22. Best
Practices

23. Genericize as much
accessible functionality
as possible.
A component library is a great way to do this.

24. Best practice for focus
is best practice for perf

25. Encourage focus
management
within
components.

26. Trap focus when
appropriate

27. Use API to enforce
best practices
outside
components.

28. Enforce best practices

29. Full Name
Enter your name…
Enter your full legal name as it appears on your government ID.
This field is required.
Required Props

30. Enforce best practices

31. Reuse behavior
& markup
e.g. for different input types

32. Developer
Toolkit

33. Accessibility Testing
audits
code review
manual acceptance testing
unit tests
linting

34. audits
code review
manual acceptance testing
unit tests
linting
Accessibility Testing

35. Accessibility
linting

36. Immediate linter feedback
helps devs internalize
best practices

37. eslint-plugin-jsx-a11y

38. Solid unit tests
(this one is just common sense)

39. Dogfood!
Test and interact with your component library
the way people with disabilities might use it.

40. Browser extensions
Explore the accessibility tree, check color
contrast, audit your code while working on it

41. Driving
Adoption

42. Many devs view a11y as a
chore. How do we fix this?

43. Paragon
•edX’s (work-in-progress) component library
•Implemented with React and Bootstrap, open
source and released via npm
•15 components (and growing). a11y team built
the first 5 components; developers did the rest
•https://github.com/edx/paragon

44. Make it easy
•Provide a simple development
environment/playground
•Automate build & release
•Maintain an issue board
•Supportive code reviews
•Extensive documentation & demos

45. •Sandbox environment doubles as doc
site (https://storybook.js.org)
•100% test coverage
•Release process is fully automated, so
devs can focus on what they do best
Paragon

46. Make it fun
•Reward first-time contributors
•Pair program as necessary
•Encourage collaboration
•Showcase contributions
•“Accessible code is good code”

47. Party Time

48. Tricks & treats

49. The benefits

50. Proactive
Developers go straight to the source.

51. Collaborative
Developers optimize for clarity and
strive to help colleagues learn.

52. Conscious
a11y use cases become second nature.

53. Thorough
Different integration environments encourage
feature completeness.

54. Be soft on people,
hard on code.

55. Web accessibility
is built on best
practices that
benefit everyone

56. Thank you.
@arizzitano
@cptvitamin