Accessibility, markup & CSS improvements

[chrisvxd]

~Following #247~

We should do a pass to address accessibility, markup and primarily CSS issues, and related problems.

This is blocked by ~#247~ and ~#265~. It blocks #139, which should be done with CSS properties.

⚠️ Ignore demo app ⚠️

Tasks

CSS

• [x] Fix Inter config
• [x] Update to 12-tint Measured colour palette
• [x] Use trick to alpha channel hex colours without rgba or alpha hex
• [x] Focus states
• [x] Touch states (not :hover)
• [ ] Systematise CSS properties (aka use tokens) to support theming
  • [ ] colours
  • [ ] typography
  • [ ] spacing
• [ ] Add dark mode variants for all relevant use tokens (toggle on system)
• [ ] Revisit breakpoints following #372

Accessibility audit

• Contrast
• Alternative text
• Keyboard support
• Markup

[chrisvxd]

@monospaced let's use this to track and implement broad improvements. Please drop a comment with anything you've already identified for improvement, or anything that comes up during #247.

[adampage]

For the accessibility audit, I‘d recommend having a look at the W3C’s Authoring Tool Accessibility Guidelines (ATAG) standard. ATAG is a nice companion to WCAG since it identifies some distinct success criteria applicable to CMS UIs.

Beyond its coverage for the accessibility of the interface itself, I also appreciate that ATAG has a whole section on supporting authors (encouraging them, even) to produce accessible content. 😅 Puck’s fantastic heading analyzer plugin is a heartening example of where you’ve already done work in this space.

Warning: ATAG was last published in 2015, so please forgive it for potentially being out-of-touch with modern content management concepts and techniques.