ampproject / ampproject/meta-ac
Accessibility
- Dominant language
- No language data
- Stars
- 24
- Forks
- 13
- PR merge metrics
- No merged PRs in 30d
Description
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](https://github.com/ampproject/amphtml/issues/created_by/tetralogicalhelpdesk).)_
- [ ] 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**](https://github.com/ampproject/meta-ac/projects/2?card_filter_query=label%3A%22focus+%2F+accessibility%22)
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the linked accessibility blog post, the UX and a11y WG resources, and the open issues listed for the component audit. The issue is complete when the remaining accessibility goals and deliverables have clear decisions, including review requirements, linting or testing methods, and browser/assistive-technology guidance.
Written by the indexing model from the issue text.
Assessment
- Domain
- accessibility
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100