WordPress Accessibility Team position on default full screen mode in the editor

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 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) implications this new default setting will have.

As a starting point, the WordPress Accessibility team is opposed to this change as it breaks some 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/. 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 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/ 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 betaBeta 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 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. and how many users will use the editor. The related ticket was opened and merged only few hours before WordPress 5.4 RCRelease Candidate 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/CoreCore 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 releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. 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.

#core-editor, #gutenberg

Revising the WordPress Editor: Gutenberg and Accessibility

One of the three top priorities for development in the next releases of WordPress is to enhance and modernize the editor. This is an important project to give users the ability to create rich and diverse content without requiring extensive knowledge of code. From an 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) perspective, this is both an incredible opportunity to build a powerful and flexible experience for all users and an enormous risk that we could end up reducing the effectiveness of the editor for users with disabilities, or require them to use a 2nd-class editor without these enhanced editing capabilities.

We in the WordPress accessibility community embrace the challenge of creating a great new experience, and want to assure the community that we are going to do everything we can to make sure that any new editor experience is as accessible as we can possibly make it.

The most fundamental part of democratizing publishing is the ability to write and publish content. Without that feature, WordPress is not achieving its coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. mission. There are always challenges in creating content accessibly, but it is not an unachievable goal.

It’s still early in the process, and there are many ideas floating around about how the new editing experience should be structured and how its interface should behave. The concerns for accessibility are universal, however. The new editor should consider accessibility to be a priority both in how content is created and in the nature of the content that is created.

While the accessibility team wants the final implementation to be exceptional and accessible, we don’t want to limit the possibilities by imposing restrictions before they are necessary. However, there are some concepts that should be kept in mind early on that will significantly impact accessibility during development.

Fundamentals of Accessibility to Consider

  1. Some common user interface interactions are extremely difficult to use non-visually. Drag and drop is an interaction that poses significant difficulties, since it is very difficult to disclose in audio how the dragged object and the potential targets are interacting. This doesn’t mean that the editor can’t use these interactions, but if they are used, there will need to be an alternative method to do the same task which is accessible.
  2. Fundamentally, all outputted code is organized in a linear manner. The experience of the content for keyboard users and for screen reader users will also always be linear. Ensuring that the content authoring process encourages a linear path will make the process easier for all users.
  3. Whenever possible, the user interface should encourage people to create semantically valid code; encouraging the use of correct headings (e.g., being content aware to know which headings are valid for a new content 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.); encouraging the addition of alt attributes, or defining table headings appropriately for tabular data.

Updating the editor is a great opportunity to explore some of the requirements articulated in the Authoring Tool Accessibility Guidelines (ATAG). These requirements discuss how an editor should allow users to navigate the structure of their content and how the editor should encourage the creation of accessible content. A richer editor experience, with integrated prompts and formatting tools, has the potential to suggest best practices throughout the content authoring process. This would be an important growth step for WordPress.

It should be self-evident that the new editor experience needs to meet the standards established for accessibility in WordPress core. The editor is the central experience of WordPress content creation, so planning ways to consider accessibility at every stage through the process is crucial to the success of the Editor project.

Help develop the new editor

If you’re interested in helping with the new Editor project, follow the development conversations in #core-editor and share your thoughts and ideas. You can also follow the GitHub project for the editor, where you can file tickets or follow specific issues like keyboard shortcuts, drag and drop, and the mobile interface. Weekly chats are in #core-editor, Wednesdays at 18:00 UTC.