Thoughts on an Accessibility “Get Well” Plan

Post from June 29, 2022 (↻ November 23, 2022), filed under Web Development (feed).

Have you wondered how to anchor accessibility in an engineering team, one that isn’t yet producing accessible sites or apps?

The other week, I met with another LivePerson engineering lead on these questions, and later sat down to document options to start with. Here they are, for further refinement and discussion.

Hiring and Staffing

• In general, hire and manage towards accessibility expertise with every developer, rather than hiring or singling out individuals; to me, the latter seems to bring particular problems, including the signal that accessibility was not everyone’s responsibility.

  If you ask me whether this means to forego hiring an accessibility specialist in favor of having accessibility generalists—yes, that’s my preference. This is not to say specialists couldn’t be used for audits and trainings.

• Accordingly, make accessibility part of the team’s hiring profile.

Training

Short-term (goal: increase exposure to accessibility topics, plant concepts):

• Share—forward, present, discuss, apply—guidelines, like WCAG
• Share heuristics, like WCAG and IBM ones [disclosure: author post]
• Share techniques, like Techniques for WCAG 2.1

Mid-term:

• Offer trainings [thanks, Twitter!]
  • Introduction to Web Accessibility
  • Web Accessibility Curriculum Package
  • Web Accessibility by Google
  • a11yphant
  • Practical Accessibility

• Share applicable regulations, like Section 508

Long-term:

• Enable—perhaps require, for certain roles and SDE/SWE levels—accessibility certifications

Tooling

Short-term:

• Collect and document accessibility tools

Mid-term:

• Add automated tests to CI/CD

Processes and Communication

• Explain and keep explaing the importance of accessibility in the profile and skill set of a modern frontend and full stack developer
• Add accessibility requirements to team coding standards
• Add accessibility testing to the Definition of Done
• Assign high priority to accessibility issues (bugs), and manage them accordingly
• Make accessibility testing (test UI with a screen reader) compulsory for new features
• Ask to share and discuss accessibility learnings in technical fora (like Communities of Practice)

❧ What would you add? Share your accessibility “get well” plans!

About Me

I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.

If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!