Project requirements

When setting up requirements for a product, accessibility should be baked in to every step of the process.

  • Ensure there is budget set aside for accessibility training and testing
  • Evaluating accessibility of vendors
  • Writing user personas to include people with disabilities
  • Developers should be chosen with accessibility experience
  • Testers should be aware that accessibility acceptance criteria will be part of their work

Product manager/owners

It is up to the product owner to be accountable for the product’s outcomes.

When 26% of the US population have a disability that requires accommodation, accessibility cannot be considered an afterthought.

  • Clearly share the expectation of going beyond accessibility compliance
    • Prioritize quality experience for everyone over deadlines
    • Redefine MVP: Declare that the product doesn’t work until it works for everyone
  • Add A11yEngineer.com accessibility acceptance criteria to stories as part of the defintion of done
  • Ask for demos of products using assistive technology of your team and any partner product integrations

Infrastructure architects

Accessibility is not just problem to solve for designers or developers. Platforms that support products must facilitate accessibility best practices.

  • Databases should include test accounts for all UI configurations (this sounds obvious, but it’s apparently not)
  • CMS or catalog management tools should include features for adding accessible content like alt text or aria-labels
  • APIs that return content should include relevant accessibility features (ex: search results should include alt text for images)

Vendors and partner organizations

Partner driven features must be compliant as well.

Keep in mind, your customers aren’t concerned with who built specific in your application; they just really need it to work and will not make that differentiation when they complaint.

  • Vendors and 3rd party partner resources should all be briefed on accessibility requirements
  • Vendors should be able to provide a VPAT (Voluntary Product Accessibility Template)
  • The vendor should be able to verify the VPAT either with internal testing documentation or a 3rd party evaluation.

UX/UI research and design

The most important artifact from the design process is the conversation the designer can have with the rest of the team about the experience you want people to have.

  • Alongside personas that include age, location, gender and socioeconomic status create personas for people with disabilities
  • Consider simpler ways to convey content, don’t use a complex interaction when a simple one will do
  • Deliver UX designs annotated with the expected experience for
    • Customers who are blind and low vision
    • People using a switch device or keyboard instead of a mouse
    • Hearing disabilies with captions and transcripts
    • Cognitive differences with plain language

Guide: Design for accessibility

UI Developers

Accessibility isn’t just a UX design problem; for people using a keyboard and screenreader, the code is the UX.

Even when skilled and motivated, developer teams need processes and tools that support building products in an accessible way.

Accessibility in agile

The currency of product development is the user story; if accessibility can’t convert itself to a user story, then its fulfillment is open to interpretation.

While the WCAG spec covers any situation and UI, product teams operate on testable requirements. The WCAG spec is massive and focuses on accessibility testing with the conceptual P.O.U.R. principles rather than with acceptance criteria that explicitly define how to test a known component.

For example, what constitutes a working checkbox that satisfies a user story? Without a strict definition of that functional requirement, developers can’t be expected to create an accessible checkbox.

Definition of ready

Accessibility requirements must be passed from the product management team to the developers in the form of acceptance criteria before any development work can begin.

I can help your team understand what these criteria mean, and coach them on how to write code that fulfills those criteria.

For teams without access to an accessibility expert to write user stories, accessibility is wide open to interpretation.

In solving this problem, I often found myself in developer grooming sessions, repeating the same testing instructions, screenreader expectations and code examples, which only builds undocumented local team knowledge — it doesn’t change organizational processes.

Best practices

  • Don’t begin working on a story until accessibility acceptance criteria are defined
  • Test with the keyboard as you code
  • Test with different screenreader combinations
  • Testing using automated tools for valid markup and programmatic accessibility errors

Testers

  • Test according to the acceptance criteria
  • Confirm that an experience is logical and makes sense

Deployment pipelines

  • CI/CD pipelines should engage automated accessibility tools