Thoughts on an Accessibility “Get Well” Plan

Published on June 29, 2022 (↻ July 1, 2023), filed under Web Development (RSS feed for all categories).

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 companies like Google and as an engineering manager for companies like Miro, I’m close to W3C and WHATWG, and I write and review books for O’Reilly and Frontend Dogma.

With my current move to Spain, I’m open to a new remote frontend leadership position. Feel free to review and refer my CV or LinkedIn profile.

I love trying things, not only in web development, but also in other areas like philosophy. Here on meiert.com I share some of my views and experiences.