An interesting and in-depth discussion has been going on in GitHub about the best way to group the buttons in the main Gutenberg toolbar. The main issue is how we balance usability and accessibility.
- Screen readers read pages from left to right, top to bottom
- Sighted readers read web pages in an F-shaped pattern
The result of this is that it is hard to optimise for both, as these are at odds with each other.
This post summarises my perspective on the key points and offers recommendations on how to proceed with issue #1963.
How sighted readers read web pages
Numerous eye tracking studies have analyzed how we read web pages. The 2006 study by NNG found that people read online in an F-shaped pattern. It is interesting to note that while the left-hand side of the page is the main focus, the middle is relatively empty and there is a secondary focus on the right of the page. This is true in general but will be influenced by the specifics of the elements on the page. For example, a big red button will catch the reader’s attention regardless of where it is placed (on an otherwise subdued page).
Extrapolating from these studies, I would expect to see the following pattern in WordPress + Gutenberg editor:
- Most of the attention will be focussed on the left-hand panel. However, as the writer transitions to the task of writing, the left-hand panel will recede (the dark colour serves to connect all of the navigation elements into a single entity, which will recede during the writing task).
- Scanning from left to right, the eye will likely stop around number 2, ignoring most of what is in the gap between 1 and 2 (assuming that the elements in the zone between 1 and 2 have relatively similar visual styling).
- The eye will rest on what is in the top right corner. The reader will expect to see something here that represents a conclusion, or a destination.
As I write this, it comes to mind that we should deploy a remote eye tracking study to validate these hypotheses.
How screen readers read web pages
I am by no means an expert, so will defer to those who are more knowledgeable in this area, like Andrea Fercia (@afercia). What I can make of the discussion here, is that screen readers will read a page from left to right, top to bottom. So for a screen reader, a page laid out that delivers elements that mirror the workflow of the reader is optimal.
For example, there is a lot of discussion around the ideal placement of the “Publish” button. From a screen reading perspective, the optimal place is to have it at the bottom of the page (near where the writer has finished writing, and will be looking to publish). From a sighted reader’s perspective, placing the Publish button at the bottom of the page may render it not visible (below-the-fold). Emotionally, there would be a disconnect between the place where the conclusion is expected to be (top right corner) and the place where the conclusion is (bottom of the page).
Yes, it’s complicated!
Looking at the screenshots below, it’s easy to see how each is optimised for a different use case. The top image (Publish button on the far right) is likely the best layout for sighted readers. The bottom image (Publish button in the middle zone) is likely the best layout for those using screen readers.
A secondary issue that is raised in this discussion is how to best group the buttons in the toolbar (discussion here and here). On this topic, there is less divergence about best practice. There is agreement that buttons should be grouped into logical buckets. Where some of the complexity comes in, is that there are multiple ways in which we can fill these buckets.
- Least important or used: Visual to Text toggle button
- Most frequently used: Undo, Redo, Insert
- Hero button/emotional destination: Publish
- Preview should be in close proximity
- Save should be in close proximity
- Settings button: needs to be somewhere near the right, as this is where the sidebar pops out. Disconnecting the settings button from where the setting slide out will be cognitively jarring, and thus undesirable
These groupings would look something like this on the toolbar: if we optimise for sighted readers, the least frequently used buttons should be placed in the middle zone. If we preference for screen readers, the most frequently used buttons should be placed in the middle zone. In both cases, the destination or hero button should be placed in the top right – and possibly replicated at the very end of the document for screen readers.
Translating the above general groupings into actual elements introduces a degree of necessary subjectivity: we should build product to tangible specs, and not conceptual ideals. The renderings below are my proposal for how to proceed, with the caveat that I would run some user tests with eye-tracking/heatmap analysis on a small sample to validate some of the assumptions.
- Leave the Visual to Text switcher in the overlooked middle zone. This will be an infrequently used button, and can be placed in the zone that will be naturally skipped over by sighted readers
- Fix the position of the frequently used buttons (Undo, Redo, Insert) in the area just to the left of the expanded settings sidebar. This is a high visibility area of the toolbar.
- Use the zone between 1 and 2 for custom buttons. This segment could be made scrollable (we have had success with this in Textbox.io).
- Group things to do with finishing (i.e. the emotional destination) in the top right:
- Publish should be the standout hero – pressing this button is the “high five” moment for a content writer.
- Place settings on the far right, and colour it in the dark colour when on, and light colour when off. Changing the colour from dark grey to black makes the button recede into the decoration of the WordPress page, which is both appropriate, and reduces visual competition between it and the Publish button.
- Place preview in the same logical grouping as Publish, but make it less prominent. Consider making this a dropdown (Preview on desktop, Preview on tablet, Preview on mobile).
- Demote the Save button to a status line below the Publish button. As we are auto-saving, this button is not even needed, but will nonetheless be reassuring to the writer.
- Editor toolbar: controls order and grouping #467
- Consider a new order and grouping for the toolbar controls. Try/toolbar controls order grouping #1963
- F-Shaped Pattern For Reading Web Content
- 5 Usability Lessons from Website Eye Tracking Studies
- Heatmaps for websites: crazyegg