Review and update the accessibility coding Standards
Considering the shift towards JS-based interfaces, we should consider to review and update the accessibility coding Standards.
Announcing dynamic content
We have:
- wp.a11y.speak()
- a non WP dependant solution: a11y-speak()
For complex interaction wp.a11y.speak() may not be the best solution. When in doubt discuss solutions with the a11y team.
Resources
- Accessibility handbook has not enough recourses
- How to handle ARIA for screen readers
- Fact is that traditional web apps reload gives feedback, that JS only apps can not provide. Are there tools we can leverage to help standards adoption?
- JS interfaces still should be build with semantic HTML
- React tends to use divs, but that’s not React itself, that’s bad programming
- 10UP now released a complete library for WP . It’s in Github, so this is expandable
- For the handbook we should refer to existing libs or someone to build them
- There is a need for good information and components that are accessible
Workflow
Important: The a11y team needs to do more teaching and sharing, instead of fixing things themselves. Specifications within accessibility tickets should contain code examples
- We should share accessible components
- Is it possible to abstract cases and give examples of good practices
- Part of the standard tooling should be testing software react/axe
- Give 10 point list of things to check
- We should publish about for example audio feedback, focus management, ARIA
Discussion
- Should we block things? Are we okay with keeping that statement: WCAG 2.0.
- Have things met the standard? Probably not.
- What happens in tickets if it’s raised that it doesn’t work for WCAG?
- How do we help in that situation? Someone should review major patches.
- We don’t want to be a blocker. Accessibility has purification levels. Shoot high, but compromise.
- What happens when someone blocks a ticket. It depends, no one really has.
- Where’s the acceptable bar? Should work with keyboard only (arrow keys, etc. too). Semantic elements too. Labeled. This is a baseline expectation.
- Struggled to know when/where discussions take place sometimes.
How to involve more developers with accessibility tickets
- This is about how to bring more people into this team?
- Why do some people stick around and others not stick around? Interesting, important. Time is valuable.
- How do we maximize people’s time? Maybe story points, like in Scrum.
- People don’t know how best to contribute.
- Something like “good first bug” but for accessibility.
- Short interview/onboarding for people interested.
- Better way to manage priorities. Maybe spreadsheet to try it?
- Non-Core items: Testing, theme reviews, tickets, documentation, support, education
- Maybe use more keywords for this? Make list public so people know.
- Best way to address is when teams ask for help.
- Accessibility slows progress down when it comes at the end.
- We need a mental shift of where accessibility fits. We need to let them know they can do it.
- Works properly vs. get working.
- Get people from outside community. Make a list and ask. Things they can do and achieve. Make a list of people we could bring in.
- MITs: Settings API, Gutenberg, Media Views, Unified Search – Who?
How to proceed with the handbook
- Make two pages: Tools and resources. Also, how to get involved.
- Would potentially be easier to maintain.
- Has been hard to get done because everyone is busy.
Good examples of ARIA, etc.
- How to test resources.
- List of what we’re working on.
What topics?
- ARIA
- Keyboard accessibility
- Color contrast
- Semantics
How should we divide topics?
- By topic or need? Probably both.
- Try to find resources that go beyond accessibility as it relates to disabilities.
Who can work on this?
- Make small workgroup
- Do Google Spreadsheet