Accessibility user testing framework

[Febakke]

• Make an article to explain how we work with accessibility
• Discussion-point: How much time should we use to fix components for screen readers or browsers with errors?

Inspiration

• Sparebank 1 have an overview on all components Sparebank 1 designsystem
• USWDS have a checklist for some components
• https://github.com/alphagov/wcag-primer/wiki

Tasks

Preview Give feedback

1. Accessibility test on all components #2355
   0 of 1
   ♿️ accessibility +1
   
2. Add axe testing for our react components #2384
   react ♿️ accessibility +2
   

[Camulos]

Karen Hawkins suggest using test-tokens (in Figma only?) to quickly test the viewport and zoom WCAG requirements.
https://www.accessibilityassociation.org/s/archived-webinar-details?id=a0A4z00001CRXiLEAX

• text size / line height tokens for 200% text size
• frame / layout tokens for 320 px width viewport

The idea of test-tokens may be extended to other requirements as well.

[Camulos]

Testing in Figma:
For both components and full gui-frames:

• Contrast: text-color vs background, verify used color-tokens and manual test contrast if using other colors or strange combinations of tokens
• 200% zoom: Test with 200% text-size tokens, do not change frame size
• 320px: Test content in 320px width frame, use for-mobile-tokens and -component variants if they exist

For full gui-frames:

• map out expected focus-order, is it logical?

Testing content:

Testing code:

• use a11y, axe or other automatic test APIs
• deploy components into reference application, test automatically in context

[Camulos]

Difficult to test outside of context, an reference application containing all components, and variations could be very helpful when doing tests that rely on how the components are being used. Both as a helpful tool for testing the components in context, but also to test documentation.

For example an component might need to have its internal heading at a specific heading-level in relation to the service as a whole. Also a component may need to function correctly as its own defined region or subregion (section, aside, article, heading, footer). inherited colors and tokens needs to be tested.

Automatic tests such as available using APIs from a11y or Axe will give better test results when the components are being deployed in full semantic html-pages, again this might not necessarily tell us that the component has any issues, but it will inform into what should be addressed in the documentation, for example in a "accessibility-considerations when using..."-section.