These are the weekly notes for the Accessibility Team meeting that happens on Fridays. You can read the full transcript on our Slack channel and find the meeting’s agenda here.
Review the accessibility of the Gutenberg search block
To solve the Gutenberg issue to improve the customization of the search block, a first pull request to change some display options of the search block was merged. Unfortunately, the new implementation allows users to create search forms which are highly inaccessible. After some discussion, the Accessibility Team recommends the following:
- every search form has to have a label, that can be visually hidden if the search form can be identified as such by other means;
- every search form should have a submit button to identify it as such;
- the default options for the search block should include:
- a visible label,
- a text button, and
- no placeholder;
- it’s worth doing an exploration about the possibility of throwing warnings in case a user reduces the accessibility of a search form.
Review the accessibility of new and existing sidebars in Gutenberg
In order to systematically address some problems regarding new and existing sidebars in Gutenberg, it was suggested that team members had a look at some related issues and pull requests before the meeting.
During the meeting, the discussion focused mainly on identifying why a sidebar may not be the best pattern in some situations. It’s worth having a look at full discussion on Slack about sidebars accessibility, even if it’s quite technical; following are the main takeaways of the discussion.
- Regarding the use of a sidebar to change the settings of a specific block: it’s important to keep a logical information architecture to give assistive technology users a consistent and reliable mechanism to move between the block and the sidebar.
- The main concern is the lack of proximity (both in the DOM and visually) that can impact especially on users with disabilities (among others: people who rely on keyboard navigation, screen reader users, low-vision users who need text enlarging).
- Relevant controls should be placed in a meaningful sequence (both visually and in the DOM); the DOM should not be changed to match a visual design that is not helpful.
- Sidebars should have a global context; settings for a specific item in a collection (a block, a media item, a widget…) should be inline with them.
- Interface changes have a big impact on assistive technology users and, as such, should be carefully weighted. For example, the inserter component was changed from a popover with modal behaviour to a sidebar; this means that people used to interact in a certain way with the inserter had to re-learn how to use features they were used to.