Accessibility

[tobie]

Making AMP really accessible.

@ampproject/ac: the goal of this issue is to define what we want to achieve in 2020 for that focus area. Please comment below with you suggestions regarding that topic.

• Goals:
  • Improve AMP’s accessibility
  • Make it easier to publish accessible AMP pages
• Outcomes:
  • [x] Documentation for devs on how to make the components that they ship accessible.
  • [x] Audit of existing components. _(See open issues.)_
  • [ ] Accessibility reviews included in Intent to ship (I2S) and intent to prototype (I2P) processes.
• Deliverables:
  • [ ] firm commitment to not ship new features unless they've been vetted/reviewed for A11y
  • [ ] identified linting/testing methods and ensure that the dev team integrates these into their workflow
  • [ ] include recommended browser/assistive tech (AT) combos and have them included on the AMP website
• Ideas for Action:
  • [ ] Add accessibility as a design principles (e.g. “make the content is accessible by every user regardless of their ability”) [#114] (Maybe something for the Long-term Vision TF to consider.)
  • [ ] Add accessibility requirements to AMP validator [#115]. (This requires the components themselves to be accessible, and process and automation to make sure components stay accessible before thinking about such an idea.)
• Resources:
  • UX and a11y WG
  • Please read https://blog.amp.dev/2020/05/04/creating-accessible-sites-with-amp/

See all Accessibility issues

[jorydotcom]

Related Jamboard for Brainstorming: https://jamboard.google.com/d/1rb9r2_GGawD9TGZMoXAr6Kfd0m7bGOut_CBbl3ug_Nw/viewer