Component Accessibility Status: design research and jams

[laurenmrice]

Acceptance criteria

We need to show the following criteria on the website:

Required test information

• Has default AVT tests.
  • (There are no violations when running the automated Equal Access Checker on default component state.)
• Has complex AVT tests.
  • (There are no violations when running the automated Equal Access Checker on more complex component states/variants.)
• Has keyboard nav AVT tests.
  • (There no violations when running automated keyboard navigation tests using Jess/Michaels' tabbing guidelines.)
• No screenreader violations. We may holdoff on this until a later version.
  • (Manual process, leverage Ram's expertise and time.)

Additional information

• Show which framework has been tested. (ex: React)
• Provide a link out for someone to find the actual test(s) per component.
• Be able to describe or explain the difference between a default, complex, and keyboard test.

Design tasks

• Design jam with design team to conduct research of how other design systems display a11y content.
  • Figma link to research
• Design jam with design team to sketch out possible ways of displaying the content we need to show on the website.
  • Figma link to sketches

---

Past design work done on this topic

• Platform Asset page
• Carbon v9 component status page
• Component status page iterations

Design systems

• In the research jam, explore other design systems for ways they show a11y status information.

Sketching

• Do we use a table, cards, tags, status indicators to show this information?
• Do we have a dedicated page for this and also display a status relating to it on individual component pages?
• If we only display a status indicator, like an icon, should it also have text next to it to convey its meaning?
  • Work with devs to get an output of JSON from Playwright that could automate our coverage status.

Dev exploration

• Dev has come up with an initial prototype of a way this information could be displayed.