Thoughts on an Accessibility “Get Well” Plan

Published on Jun 29, 2022 (updated Oct 20, 2024), filed under development (feed). (Share this on Mastodon or Bluesky?)

Have you ever 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’re asking me whether this means to forego hiring an accessibility specialist in favor of having accessibility generalists—yes, that would be my preference. This is not to say specialists couldn’t be used for audits and trainings though.

• 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 screen readers) 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 (long: Jens Oliver Meiert), and I’m a web developer, manager, and author. I’ve worked as a technical lead and engineering manager for small and large enterprises, I’m an occasional contributor to web standards (like HTML, CSS, WCAG), and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development and engineering management, but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (I value you being critical, interpreting charitably, and giving feedback.)