annezazu 9:11 pm on November 15, 2023
Tags: , core editor, ,   

Hallway Hangout: Recap of working session on consolidating navigation modes

This is a summary of a Hallway Hangout that was wrangled in the #accessibility channel after a prior hallway hangout on improving 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) in the Site Editor and took the new form of a concrete working session to address a specific problem. It was first announced on October 1st and was open to all.

Attendees:

@alexstine @joedolson @richtabor @annezazu @jerryj @afercia @elblakeo31 @peteringersoll

Video Recording:

Notes/Links:

After some quick intros, we dove into talking about the problem before exploring possible next steps, approaches, and current issues. 

Related issues:

Difference between modes

To kick off, Joe asked Alex to talk through the current pain points and differences between modes. As Alex said, navigation mode is a hackedhacked together feature. The biggest problem we have, the navigation mode is a dynamically updating button. Everytime you press your arrow key or tab key when you’re in navigation mode, it dynamically re-renders. This is a challenging problem to handle with screen readers because it’ll ignore this. For Windows, there’s also a longstanding issue where the arrow keys don’t actually send the keyboard events through the browser so tab is the only viable key. Conversely, List View is much simpler in the way you can navigate with keys and it’s wrapped in a navigation role. You are able to expand rows, have control over what you’re looking at, etc. Another current problem with navigation mode, it’s not entirely clear when there are inner blocks. Alex started to work on this but stopped to focus on list view. 

What are the consequences if we stripped out navigation mode and used list view as the primary way of browsing through blocks?

To date, there has been no modal, tips, etc for keyboard users in the editor. People who are used to this would have no idea it has changed and we need a way to communicate that change, perhaps using a similar approach to the change in template parts to the patterns section. 

Andrea, who helped implement navigation mode, offered some historical context. He shared that if we are going to use navigation mode, we’re going to reintroduce a major issue that existed before introducing the two modes. Imagine that a post contains dozens of blocks. If you want to navigate these blocks in the post content area with the tab key, you are going to have to go through all of the dozens of blocks including the interface of each 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. (dozens of tab stops). Nav mode was originally meant to reduce the number of tab stops when navigating through the blocks in a way that each block was only one tab stop rather than multiple then pressing enter gives the ability to switch the block to edit mode where you can navigate inside the block. This was the original implementation and it made sense when there were no inner blocks. 

Joe noted that List View works the same way where you can go block to block. When you use the tab key you are going through all of these elements. However, there are still a lot fewer elements than going through the blocks themselves. We should be willing to compromise to some degree. Arrow key navigation in List View also does work. It’s 100% accessibility and there are a total of three tabbable elements in list view: tab panel, close button, and list view area itself. 

Alex would like to find a better way to manage focus between block editor and block 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. but that’s a broader discussion. Jerry and Alex have worked on this but it’s a long battle. 

Trying List View + Focus Mode for container blocks as an experiment

Anne pitched trying getting rid of navigation mode and use list view + focus mode as an experiment in 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/. We could then do a call for testing and get a sense of what the experience might be like more practically. Folks were very much onboard with trying this out, especially since in the long run this would reduce the number of mechanisms to maintain. 

The question of how many people are used to using navigation mode came up though, especially since the feedback folks are worried about is more about non screen reader users. Anne is going to try to get some initial data from WordPress.comWordPress.com An online implementation of WordPress code that lets you immediately access a new WordPress environment to publish your content. WordPress.com is a private company owned by Automattic that hosts the largest multisite in the world. This is arguably the best place to start blogging if you have never touched WordPress before. https://wordpress.com/.

Mobile concerns

Rich chimed in that the current primary use for that view is on mobile devices as this makes it easier to select child first nested blocks so it’s easy to tap onto. We never really got to the bottom of this on the call as we all pulled out our phones to investigate and couldn’t figure out how to even evoke the mode. 

Locked blocks and inert

We discussed how to explain disabled blocks in List View which relates to a broader discussion on alternatives to inert. There’s no good way to explain to a blind user what a template looks like when editing a smaller portion like a page. Anne showed an option to toggle on/off a template preview when editing a page in the Site Editor and we discussed a few ways we could enhance that feature to save it as a preference/have it be persistent in some way. 

Focus mode concerns

We discussed Focus Mode and adding it to Container Blocks. A big piece to figure out is how the back button works and ensuring it returns you to where you’d expect in the Site Editor experience.

Gutenberg as a framework concerns

Alex brought up an excellent point around Gutenberg being used as a framework, like with Blocks Everywhere, and how navigation mode is built into it as a package. We need to consider this in removing the navigation mode and it might be that it remains for third party usage. 

Next steps:

@annezazu will follow up on the following: 

  • Open issue around “show template” rather than “template preview”. 
  • Open issue around persistence of “template preview” option and make it a user setting. 
  • Try to get data around usage for navigation mode from WordPress.com 
  • Open issue around where back button goes after focus mode and returning you exactly to edit button ideally. 
  • Add recap of this discussion to the overall discussion issues, including noting how this might impact gutenberg as a framework. 

Known issues:

Finally, @annezazu will create an issue to pitch this as an experiment to try in the Gutenberg repo as a next step. 

#accessibility, #core-editor-3, #gutenberg, #hallwayhangout