Accessibility Team Meeting notes: May 10, 2019

Meeting transcript on Slack

WPCampus 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) Audit

Discussion about how to organize both 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/Accessibility and Design teams to handle accessibility issues (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/ issues but also fundamental issues found in the editor).

The accessibility team main concern is that the Gutenberg team would maybe going to focus on GitHub issues (which is understandable) and ignore the wider UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing./usability issues uncovered in the report.

The idea is not to ignore GitHub issues but to find ways to handle broader fundamental issues with the editor.

@mapk: “One super helpful way to understand the usability issues from the report would be to actually see the tests performed”. The question to be asked to WP Campus (@bamadesign).

The Gutenberg team asked to open issues for these general issues to they can be milestoned. There is a need for a starting point.

@afercia noted many (if not all) of the broader accessibility/usability issues reported in the Accessibility Audit were already reported by the team: Report on the Accessibility Status of Gutenberg (October 29).

@karmatosed: “I’ll add that whilst we all need to learn and iterate, there’s been a large move on that front. I want to for example call out the work of @lukepettway and others coming to the design meeting. @bemdesign has been incredible coming to design 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) audit triages”. Which is a good starting point to work together on design principles in the editor and in WordPress in general.

According to the Gutenberg Team, it would be useful to use concrete examples for each issue so it can be better surfaced/discussed/addressed.

@afercia: “I’d like to outline is that these broader issues can’t be solved with technicalities. There’s no ARIA, no focus management, no JS tricks that can solve these broader issues.”

@audrasjb said moving from the main editor to the sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. and go back to the editor is an example of very difficult tasks the users have to do to manage their post when they use assistive technologies.

@matveb: said it also shows something everyone was aware, but never reached a good solution for.

@afercia listed some examples:

These two examples are more related to the general design rather than technical implementation. Settings should be easily reachable starting from the 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.. Ideally, they should follow the block in the DOM order. That makes the whole idea of sidebar an accessibility anti-pattern.

@joedolson: “Getting a shared understanding of the essential characteristics of interaction flow for users of assistive technologyAssistive technology Assistive technology is an umbrella term that includes assistive, adaptive, and rehabilitative devices for people with disabilities and also includes the process used in selecting, locating, and using them. Assistive technology promotes greater independence by enabling people to perform tasks that they were formerly unable to accomplish, or had great difficulty accomplishing, by providing enhancements to, or changing methods of interacting with, the technology needed to accomplish such tasks. https://en.wikipedia.org/wiki/Assistive_technology is a valuable step in getting a better process; discussing the technical issues with the sidebar/block interaction helps us get closer to that.”

@matveb: “I’d like to understand if the problem is even more fundamental between trying to accommodate editing and navigation under a single view mode […] it can be an essential paradigm for framing the conversation”

@afercia said other similar editors have a clear distinction between “view” and “edit” mode.

@joedolson: “Understanding the problems with jumping between disparate objects using the keyboard is a big part of it. Keyboard are largely dependent on linear flow, moving one step at a time between neighboring focusable objects. Keyboard shortcuts, while possible, are extremely difficult to make 1) perceivable, 2) understandable and 3) robustly supported, which makes them hard to depend on. So recognizing that elements that aren’t sequential is very difficult to navigate between is important. The problem isn’t in making the keyboard navigation better, but placing related elements next to each other in the DOM.”

In conclusion, it was decided to add a 15 minutes timeslot in the accessibility meeting time dedicated to having an open floor period where anybody can show up and chat on any accessibility topic.