During the last weekly meeting, the team discussed the recent change of default to the full-screen mode in the editor. There is a general concern about the usability and accessibility 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) implications this new default setting will have.
As a starting point, the WordPress Accessibility team is opposed to this change as it breaks some WCAG 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/. success criteria:
- Success criteria 3.2.3: Consistent navigation
“The intent of this Success Criterion is to encourage the use of consistent presentation and layout for users who interact with repeated content within a set of Web pages and need to locate specific information or functionality more than once.”
- Success criteria 3.2.4: Consistent identification
“The intent of this Success Criterion is to ensure consistent identification of functional components that appear repeatedly within a set of Web pages. A strategy that people who use screen readers use when operating a Web site is to rely heavily on their familiarity with functions that may appear on different Web pages.”
The main issue is that the fullscreen mode (when it’s activated by default) removes the top bar and admin menus. Navigation should stay consistent in the whole admin experience. There is another similar issue in WordPress admin, but this change happened years ago. This is not a reason to reproduce such a mistake.
If this change is here to stay, it would be nice to add a modal to explain how to restore the normal mode as this is not easily discoverable for the moment.
The current mechanism to exit full screen is a “Go Back” button using the WordPress Logo that sends the user to the posts list. It is worth noting that users are not necessarily coming from the posts list, and the “go back” button (WordPress logo) is not relevant as it takes the users back to a screen that wasn’t necessarily visited before.
There is also a concern about the date on which this change was introduced. If it had been introduced during the development cycle, the Accessibility team could have provided proper information to the Gutenberg 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/ team on the accessibility issues concerning this feature.
This change breaks the rule decided for WP 5.4: new features and enhancements can’t land during beta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. cycle. While the full-screen feature itself is not a new feature, the change to including it as the default behavior constitutes a significant change to the UI 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. and how many users will use the editor. The related ticket was opened and merged only few hours before WordPress 5.4 RC A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. 1.
If this feature is going to stay in WordPress 5.4, the accessibility team believes it will need a post mortem on Make/Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. The goal would be to avoid this situation (including changes that late in the release cycle) being repeated in future releases and to make sure important changes introduced in WordPress are accessibility compliant.
Note also that this change was discussed in the #core Slack channel during the March 9, 2020 devchat meeting and the majority of the attendees appeared to be opposed to it. In conclusion @chanthaboune was going to give feedback to the project lead. As no decision has been communicated for now, the accessibility team assumes this change is probably going to stay in WordPress 5.4.