Accessibility Team Community Summit Notes

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:

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

Summary on make/accessibility

Takeaways from Paris

#accessibility, #summit-2017