Accessibility Team Community Summit Notes

Review and update the accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/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 a11yAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) 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 HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites.
  • ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. 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 GithubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/, 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 blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. things? Are we okay with keeping that statement: WCAGWCAG WCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) https://www.w3.org/TR/WCAG21/. 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-CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways., GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/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