Documenting accessibility is a journey, not a destination

Documenting accessibility is a journey, not a destination

Documenting accessibility is a journey, not a destination

Jan 27, 2025

Equitable design patterns

No one checklist or tool exists to solve every accessibility issue that comes up, I truly wish there was one. Teams are on a journey and what we need changes based on where we’re at.

  • Googling accessibility provides an overwhelming list of checklists and tools designed to help but without context, it’s impossible to sift through what’s valuable.

  • Products and teams go through a process from discovery to implementation and different team members are responsible for different things. Miscommunication can lead to big gaps or duplication of effort.

  • WCAG Guidelines are vast and many issues that may come up are combinations of multiple requirements making it hard to prioritize.

Our team has had luck focusing on where we are in the process and having specific goals for each phase. I appreciate thought leaders within the accessibility community for creating resources to help find the right tool at the right time.

Audit

Most efforts start with reviewing the current state of the product or design system. An audit helps your team define scope and provides a structure to document how close or far you are from your accessibility goal. Anna Cook, M.S. is a wealth of knowledge and provides a great overview of how to audit an existing design system.

Build

Once you're actually designing things, it's time to collaborate on documenting and annotating accessibility within the design assets themselves. Sil Bormüller 👋🏻, always such a resource, recently posted an amazing list of plugins to help designers with requirements during handoff.

Support

After components are built, documentation needs change again. Once you have accessible components, additional guidelines within your design system need to support things like reading order, inclusive content, and technical implementation within layouts and templates. I enjoyed the most recent Design Systems Diaries with Johannes Lehner and Karen Hawkins, CPACC which touches on strategies for shifting your accessibility approach at different product stages.

Success means supporting your team and providing guidance for what they should be focusing on depending on where you’re at.

  • Do people know what they're responsible for? Make sure designers, engineers, and product team members know which parts of the process are their responsibility.

  • Is the team sharing the same goals and tooling? Support your team with clear requirements and the right tools that help folks deliver consistently.

  • Do folks have access to training to level up? Provide your team with resources to help different functions align on shared language and skill development.

No one checklist or tool exists to solve every accessibility issue that comes up, I truly wish there was one. Teams are on a journey and what we need changes based on where we’re at.

  • Googling accessibility provides an overwhelming list of checklists and tools designed to help but without context, it’s impossible to sift through what’s valuable.

  • Products and teams go through a process from discovery to implementation and different team members are responsible for different things. Miscommunication can lead to big gaps or duplication of effort.

  • WCAG Guidelines are vast and many issues that may come up are combinations of multiple requirements making it hard to prioritize.

Our team has had luck focusing on where we are in the process and having specific goals for each phase. I appreciate thought leaders within the accessibility community for creating resources to help find the right tool at the right time.

Audit

Most efforts start with reviewing the current state of the product or design system. An audit helps your team define scope and provides a structure to document how close or far you are from your accessibility goal. Anna Cook, M.S. is a wealth of knowledge and provides a great overview of how to audit an existing design system.

Build

Once you're actually designing things, it's time to collaborate on documenting and annotating accessibility within the design assets themselves. Sil Bormüller 👋🏻, always such a resource, recently posted an amazing list of plugins to help designers with requirements during handoff.

Support

After components are built, documentation needs change again. Once you have accessible components, additional guidelines within your design system need to support things like reading order, inclusive content, and technical implementation within layouts and templates. I enjoyed the most recent Design Systems Diaries with Johannes Lehner and Karen Hawkins, CPACC which touches on strategies for shifting your accessibility approach at different product stages.

Success means supporting your team and providing guidance for what they should be focusing on depending on where you’re at.

  • Do people know what they're responsible for? Make sure designers, engineers, and product team members know which parts of the process are their responsibility.

  • Is the team sharing the same goals and tooling? Support your team with clear requirements and the right tools that help folks deliver consistently.

  • Do folks have access to training to level up? Provide your team with resources to help different functions align on shared language and skill development.

No one checklist or tool exists to solve every accessibility issue that comes up, I truly wish there was one. Teams are on a journey and what we need changes based on where we’re at.

  • Googling accessibility provides an overwhelming list of checklists and tools designed to help but without context, it’s impossible to sift through what’s valuable.

  • Products and teams go through a process from discovery to implementation and different team members are responsible for different things. Miscommunication can lead to big gaps or duplication of effort.

  • WCAG Guidelines are vast and many issues that may come up are combinations of multiple requirements making it hard to prioritize.

Our team has had luck focusing on where we are in the process and having specific goals for each phase. I appreciate thought leaders within the accessibility community for creating resources to help find the right tool at the right time.

Audit

Most efforts start with reviewing the current state of the product or design system. An audit helps your team define scope and provides a structure to document how close or far you are from your accessibility goal. Anna Cook, M.S. is a wealth of knowledge and provides a great overview of how to audit an existing design system.

Build

Once you're actually designing things, it's time to collaborate on documenting and annotating accessibility within the design assets themselves. Sil Bormüller 👋🏻, always such a resource, recently posted an amazing list of plugins to help designers with requirements during handoff.

Support

After components are built, documentation needs change again. Once you have accessible components, additional guidelines within your design system need to support things like reading order, inclusive content, and technical implementation within layouts and templates. I enjoyed the most recent Design Systems Diaries with Johannes Lehner and Karen Hawkins, CPACC which touches on strategies for shifting your accessibility approach at different product stages.

Success means supporting your team and providing guidance for what they should be focusing on depending on where you’re at.

  • Do people know what they're responsible for? Make sure designers, engineers, and product team members know which parts of the process are their responsibility.

  • Is the team sharing the same goals and tooling? Support your team with clear requirements and the right tools that help folks deliver consistently.

  • Do folks have access to training to level up? Provide your team with resources to help different functions align on shared language and skill development.

Jesse James Arnold

Jesse James Arnold

Jesse James Arnold