Develop a guide that says what we mean by accessibility and how we do it

[hartsick]

Some questions:

• What would we find useful in a guide?
• What materials do we need to create ourselves vs. assemble from knowledgeable sources
• What internal discussions, process, or trainings would we need to have in order to define what we mean by accessibility and how we do it

Discuss!

The goal of this issue is to identify and break out some actionable stories from the discussion that follows.

[source: 2/7/2019 WG meeting]

[bensheldon]

I propose that we adopt "Inclusive Design" as a broader umbrella than accessibility:

Because so many accessibility errors relating to assistive technologies are markup errors, and because markup errors are so easy to identify, we’ve grown up in an accessibility remediation culture that is assistive technology obsessed and focused on discrete code errors.

Inclusive design has a different take. It acknowledges the importance of markup in making semantic, robust interfaces, but it is the user’s ability to actually get things done that it makes the object. The quality of the markup is measured by what it can offer in terms of UX.

-- Heydon Pickering, Inclusive Design Patterns

In practice, that would mean that changes to styleguide implementation would be specific, e.g. "allow this element to be perceptible to screenreaders", as opposed to general, e.g. "make this element accessible".

WCAG defines 4 principles that I believe are applicable regardless of device or impairment:

**Perceivable** - Information and user interface components must be presentable to users in ways they can perceive. This means that users must be able to perceive the information being presented (it can't be invisible to all of their senses) **Operable** - User interface components and navigation must be operable. This means that users must be able to operate the interface (the interface cannot require interaction that a user cannot perform) **Understandable** - Information and the operation of user interface must be understandable. This means that users must be able to understand the information as well as the operation of the user interface (the content or operation cannot be beyond their understanding) **Robust** - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. This means that users must be able to access the content as technologies advance (as technologies and user agents evolve, the content should remain accessible)

I believe these 4 principles are applicable when discussing design generally, and not just within the context of assistive technologies, e.g. discussing robustness browsers, or operability on very small/slow mobile devices.

I think we should continue to talk about and build against "validity" (e.g. #69), but it should be the same way that we discuss "valid HTML" or "valid CSS" and recognize that checking solely against validity does not imply usability.

---

Here is my thoughts for where to target action on each level:

Atom and Molecule Level:

• HTML validation
• WCAG Validation

Component Level:

• Inclusive design practices
• WCAG Validation

Organism Level

• Inclusive design practices
• QA and Acceptance Testing
• Usability / Prototype testing

Usage Guidelines (e.g. advice for someone applying the styleguide to their project)

• Usability testing (target users and devices)
• Screenreading
• Best/Common Practices
• Plain language
• Content/Action Hierarchy

Tools:

• WAVE Chrome & Firefox Extensions
• axe-matchers gem
• tidy-html5

[hartsick]

Ben, this is really great feedback. Thanks for taking the time to share! Will surface in the Slack channel to get in front of others.