Accessibility regression: The selected block isn't outlined any longer

[afercia]

Describe the bug A selected block needs to be outlined to give users a clear indication of which block is being edited and what its boundaries are.

This was previously discussed at length. For example, in #10559 created by @Ryokuhi from the accessibility team for a similar problem with the "top toolbar" setting. In that issue a consensus was reached and it was agreed to make the selected blocks have an outline.

In WordPress 5.4 selected blocks do have a visible outline, which is actually made of:

• a 1 pixel border
• a ticked box shadow on the left

Screenshot:

In WordPress 5.5 the "outline" is gone. Screenshot:

Looking at the screenshot above, it's pretty evident that as a user:

• I wouldn't know which block I'm being editing
• is that a single block with some text separated by line breaks?
• or maybe it's three separated blocks?

[afercia]

I'd like to note that in #10559 and also previously, it was mentioned that if users want a lighter UI, there's "Spotlight mode" for that. The default mode shouldn't compromise accessibility over "clean user interface" (whatever that means).

I'd also like to note that changing, I would say unilaterally changing, important features that were already agreed upon doesn't encourage collaboration and trust across teams.

[afercia]

Previously: #10559 (closed then reopened), #12254, #11737, #12478, #14095, #13700, #14145, #14197, #15269.

[skorasaurus]

+1; I've been meaning to report this.

5.5 is the first version of WordPress (relying on the Gutenberg built into the core version), that the outline does not appear.

This regression first appeared in one of the previous releases of Gutenberg (as a plugin) although I can't remember immediately which one.

[folletto]

I'm not sure why this is labelled regression. The initial decision of having sharp borders was because the concept of blocks was novel, thus we needed something to make it sharper and more clear as million of users were to be onboarded on a paradigm shift. It wasn't for accessibility reasons. The counter example is simple here: no text editor highlight the paragraph. The cursor is enough to know where the user is, and if a paragraph-level selection is necessary, one selects the paragraph.

The current approach already provides more than that, by showing block-level guidance and selectors as needed, as well as (if one uses that mode) the toolbar right above the block. Plus there's hover status, focus status, select mode, and multi-select, all which correctly highlight the block as they operate at block level.

There's no need of further indicators for the interface to be functional, and I find misleading to categorize this as an "accessibility" problem when it's mostly an opinion.

As far as opinion go, I got first-hand a lot of feedback on how much admin debris (as Tufte refers to) the Gutenberg interface is having, thus we need to scale that down.

Plus, I'm being puzzled because you keep mentioning "a consensus was reached" when reading these threads that's clearly not the case, and if anything, people already replied over and over on why this "issue" you keep raising isn't an issue.

—

I also just realized from your links above that you're the reason why Top Toolbar had a regression and the block outlines was reintroduced there. Top Toolbar was a mode specifically designed for people focused on writing, and now it regressed again to show borders around, thus breaking from the goal it was designed for. This is, more properly, a regression.

[pattonwebz]

The cursor is enough to know where the user is, and if a paragraph-level selection is necessary, one selects the paragraph.

For me the cursor has never been enough to know where I am on the page. Have you ever had to move your cursor, just to find out where it is? I have to do that more times a day that I can count and the border made it very easy for me to narrow down my current placement.

[folletto]

Do you have the same issue on all text editors?

[pattonwebz]

Do you have the same issue on all text editors?

I do and if they all had good indicators of focus on the current element that would be better for me. Sadly not all editors do and many of those are not very good for me to use :(

[folletto]

I understand. What could be options that for you would work? I'm not sure if adding a border around a block would be the direct answer there. For example, if it's a long paragraph, you'd still have that same kind of issue right?

So maybe we can review if there are other ways to approach that. Starting with the problem is always very helpful to explore than potential solutions. :)

[pattonwebz]

I do have a similar issue with very long blocks like you thought I might. I don't really know what a better solution for it is. The border is the best one I found so far.

Happy to be a tester though if we can figure out other solutions to try. It is hard to know what is better without trying it out but testing various different things takes a lot of dev and testing time. There isn't really an ideal solution I can think of off the top of my head :thinking:

[TimothyBJacobs]

The initial decision of having sharp borders was because the concept of blocks was novel, thus we needed something to make it sharper and more clear as million of users were to be onboarded on a paradigm shift.

Is this indicating that the borders are no longer necessary because this is no longer a novel concept?

The counter example is simple here: no text editor highlight the paragraph. The cursor is enough to know where the user is, and if a paragraph-level selection is necessary, one selects the paragraph.

I think the difference is that Gutenberg is always in a block-level control context. In Pages for instance, if you make a change in the "Format" dialog while the cursor is in a paragraph, the change happens to the word underneath your cursor. In Google Docs, the change only applies to the cursor for any new values typed.

[folletto]

Is this indicating that the borders are no longer necessary because this is no longer a novel concept?

Novelty doesn't have to do anything with it. It's about maturity of an application. We over-emphasize things on purpose at the beginning, to facilitate onboarding.

the change only applies to the cursor for any new values typed.

Yet, this is also the case for some controls, right? Many actions are still based on cursor position, and don't operate at block level.

So probably a better way to frame this is to think in terms of toolbar actions, and highlight differently if the toolbar action (hover or focus, for accessibility reasons) would act on the cursor, or would act on the block as a whole.

This would be beneficial because it would also avoid the scenario where both the block and the cursors are visible, so it's not obvious on which of the two the action is going to trigger.

[pablohoneyhoney]

It’s appropriate to note that this was openly iterated upon since Nov 2019, with subsequent improvements. Any interface is susceptible to evolve as they grow in complexity.

I wouldn't know which block I'm being editing

In the screenshot shared, it seems clear that the word “labore” is selected and that is what’s currently editable, not the entire paragraph.

Since its inception almost 3 years ago, it's been apparent that the block had an extensive use of borders, with paradoxically unclear focus. In this screenshot, focus is on the alignment button in the toolbar.

It seemed relevant to revisit those block borders to emphasize focus, providing clarity as to what has functional focus and what doesn't. The updated design aims to show clear focus outlines when it is considered most relevant to the current task: the action of moving, transforming, dragging, etc, all highlight the block with an outline. It’s worth discussing if other actions should do so as well. For example, copying an entire block flashes the outline to indicate the whole block was copied as opposed to part of its content.

The select tool (the same as pressing the Escape key) also brings the outline into focus. This is useful to indicate, for example, what happens if the user presses Delete. It’s an important distinction for paragraphs since pressing Backspace can delete text or remove the entire block depending on what is actually selected, so it’s necessary to not use a block outline spuriously without awareness of context.

There’s more work to be done to further refine all the cases and ensure the block boundary is there when you need to see it. As everything, this is an iteration.

Comparing the previous version also shows that focus is indeed clearer in most cases. In both these examples below, the image block itself has focus, which means if you press the Delete key, the block gets removed. There isn't a clear focus indication in the left image.

Like the image, the spacer block benefits from focus indication and removal of borders.

[mapk]

Thanks for that explanation, @pablohoneyhoney. 👍

Following that, I really like a suggestion that @folletto made in Slack the other day.

If we can find a way to differentiate from buttons that act on the entire block (i.e. moving, switching type), and buttons that act only on cursor or selection (i.e. bold)

That being said, the Block Transform button and Movers, when hovered, show a block border indicating their actions will affect the entire block. I think this is a great start!

However, there are other buttons in the toolbar that also affect the entire block, so iterations there may be helpful as well.

[azaozz]

The addition of the blue border/outline interferes with resizing images by dragging the resize "handles". There is a thicker border on hover and while dragging which now overlays the new blue "box" border. Seems better to remove the old, thicker border.

Another "visual bug" is that the placeholder text for the image caption is stuck to the new "box" on the left.

[pattonwebz]

It’s appropriate to note that this was openly iterated upon since Nov 2019, with subsequent improvements. Any interface is susceptible to evolve as they grow in complexity.

Those huge threads are unwieldy and uninviting to those who are outside the group of decision makers. If you could use a more user focused method to announce questions and decisions that would be a huge improvement. As it stands I think only the current developer group participates in those type of discussion threads.

[folletto]

It's a difficult balance to strike there. Broad, architectural decisions tend to go long.

Do you have suggestions on how we can try to make these more approachable?

[pattonwebz]

One way to reach a wider developer group would be posts on the make blog. I would see announcements and calls for thoughts on open questions there.

It doesn't reach you a vastly wide group of end users sadly but it does reach more people overall.

The stakeholders here are end users but informed opinions could still be provided by a wider developer group if they were posted on the core side. That is the place the software ultimately lives after development concludes.

[mrfoxtalbot]

This outline is particularly useful when interacting with complex nested blocks, such as columns, but even in the case of theoretically simpler blocks -such as groups- it helps making it clear that the currently selected block includes all the blocks included within the dotted line.

A middle ground might be to only use it for “parent” blocks, and omit this line for those blocks with a clearly defined border (images, spacers…).

[folletto]

Note that the "middle ground" you mention is already the interaction pattern we are working toward: the control highlights the specific part that is actually interacting with. Pablo explained it better above, but in short: if the action is text-level, it will just act on the text (no block highlight); if the action is block-level, the block is highlighted. So yes, parent block actions that act on the block as a whole should show all the block being marked.

If it's not happening, that's something we can iterate on and fix! :)

[mrfoxtalbot]

I noticed that after I added my comment, but I was not sure. Thank you so much for taking the time to clarify, @folletto :)

[joedolson]

To make a comparison to a standard textarea, you would be expected to have a focus state on the entire textarea that indicates that the textarea is selected. This is separate from a selection of the textarea's contents or a cursor; each of those represents something slightly different. The same should be true here, as well: there should be constant focus, showing which block is active and two variable selection/cursor indicators, showing the specific selection & the location of the cursor.

Eliminating the constant of focus on the grounds that there is the ability to activate a function that shows what you will act on is very limiting to the user's context awareness & confidence.

[folletto]

That's not a correct comparison however. Gutenberg is a full document editor, not a single textarea in a form. The right comparison is with document editors, like Pages, Word, or Google Docs. It's important to notice that some of these also provide a block-like structure like Medium, Ghost, or Paper. Even editors that aren't primarily text allow multiple paragraphs without per-paragraph markings, like InDesign or Keynote.

Why none of these tools, some of them with large accessibility work done on them, provide block-level highlight?

I might be mistaken, but my explanation is this one: because when writing an article, the focus in writing text is on the whole article. People write, edit, cut paragraphs in half, merge them back, rewrite them, move them up and down, and so on. The paragraph in isolation is not the focus (even if I acknowledge it is for some). The document is. And Gutenberg for millions of people is still a text editor.

Then again, I might be mistaken as said. This is one of the things that are very hard to assess as they are very strongly context dependent. The cursor is a marker, and selection is too, so it technically fulfills WCAG guidelines. Yet I don't want to make a "strict adherence" to the guidelines case here, otherwise the cursor is enough: different shape, sharp contrast, different color, even animated.

We are also speaking here mostly of one type of block: text blocks. Nobody is arguing that other kinds of blocks, more complex, layout, and so on, shouldn't have a selection around them.

Which is why we improved exactly this in the past few months, and now we have a text-level and a block-level way to deal with things. It fulfills this difference, and avoids the ambiguity of having both a cursor and a block selected, and not knowing what is going to be affected. Am I operating on the block? Am I operating on text? I think this ambiguity and confusion to be far more limiting to the user's context awareness & confidence.

Anyhow, I get this won't convince everyone, so I think there are two ways forward:

1. If we are ok with the highlight to match what's being edited, and for text being about writing, we need to fix the situations where the right selection is not shown: block-level stuff should show block borders, text-level stuff should work at cursor and highlight level.
2. If we decide that no, a block highlight is always needed, we can explore other ways to highlight that don't divide blocks (thus keeping text flowing across paragraphs and ease readability). We should also make sure that "Top Toolbar" works as it was intended: to be a text-first modality for writers, so without borders, to still provide the right environment for all the users that still use Gutenberg to write and find more usable a text-first approach, without paragraph interruptions.
3. Another option would be to introduce a "High Contrast" mode. This would have the additional benefit of being the standard approach on many software tools, so it's already expected from users.

I'm sure there might be other options — these are the ones that I've been reviewing more in detail.

[Updated] I forgot to write option 3 lol.

[joedolson]

It's fine for you to conceive of Gutenberg as a single focusable document editor. However, regardless of the intent, the practical user interaction is as a series of discrete editable regions, and knowing the limits of the region you're in is valuable.

• A visible cursor does not contribute in any way to meeting WCAG guidelines
• A selection does not contribute to meeting WCAG guidelines, because it only exists when content is selected. It is not a "focus" indicator, it is a "selection" indicator - these are totally different things.

The border that indicates which block is focused does not have to be the same as the design that indicates what selection is being acted on; that's a nice feature that is useful whether the whole block has a focus state or not. It would be ideal for these two indicators to complement each other.

I certainly agree that we should not use WCAG as the sole criteria to judge accessibility on; it is only the minimum acceptable level of accessibility.

When you say "when writing an article, the focus in writing text is on the whole article" you're talking about focus in the sense of attention: what somebody is paying attention to or working on is the whole article. However, when we talk about focus from the accessibility sense, we are always referring to programmatic focus: where is the current active point of focus in the DOM. This is what we expect for focus to meet accessibility criteria.

[amandarush]

Just to add to what @joedolson and @afercia have said in this thread, however much designers or developers may view the entire Gutenberg interface as a single experience, and editing an article within that as a unified thing, assistive technology doesn't see things that way, and neither do most users. In the specific examples of Keynote ETC., assistive technology like VoiceOver interprets it in discrete pieces. Same with Microsoft Word on Windows, which gets its own document object model for screen readers like Jaws and magnifiers like Zoomtext Fusion to work with. Gutenberg is on the web, not a native app, so that means things like Active Accessibility and UI Automation on Windows and/or Apple's equivalent are not available for use by developers or designers. Given this, you have to use what's available, and in this case, that's making sure that the selected block has an outline so that users can tell what they're doing and where the boundaries ofr that block are.

[folletto]

In the specific examples of Keynote ETC., assistive technology like VoiceOver interprets it in discrete pieces. Same with Microsoft Word on Windows, which gets its own document object model for screen readers like Jaws and magnifiers like Zoomtext Fusion to work with.

This seems something we can look into.

Can you outline the differences in how VoiceOver deals with a full document, compared to what happens in Gutenberg?

[paaljoachim]

Giving animated examples of todays interactions with various blocks. Bottom line is that there are hit/hot zones one clicks into and it goes into edit mode. One has to often times click multiple times outside the text content areas to select the main block.

Selecting and editing brainstorming The following are suggestions that can be improved upon. Call them initial brainstorming ideas.

Image Block.

Selected.

Placeholder: Write caption... --> Is on the left. Placeholder can be moved to the center (I made this centering Image Block caption issue: https://github.com/WordPress/gutenberg/issues/24238 ).

Suggestion: Adding an outline to the placeholder: "Write caption..."

Caption is centered. If the user clicks into the area the mouse becomes a cursor. It is like so today but the border is invisible.

---

Media & Text Block

Selected.

Suggestion: Adding an outline to the placeholder "Content..."

---

Quote Block

Selected.

Suggestions:

With outline.

Outline stretched across.

---

Paragraph Block

Selected -> Edit.

The difficulty here is that select and edit are mixed into one. Writing some text and clicking the Paragraph Block, it automatically goes into edit mode. For instance clicking outside the hot zone areas for text in the Quote Block shows the outline of the block as seen above. One can not click outside (that I know of) the Paragraph or the Heading Block to select the blocks in this way. One can use the esc key and that will show an outline of the Paragraph/Heading Blocks, or hover over the block type.

Clicking esc shows it like so:

Hovering over the Block type shows the outline.

Here is an example outline similar to how I showed the Quote Block.

The problem... with outlining the Paragraph/Heading blocks is that the outline can become distractive while writing. What if moving the cursor outside the block content area while the block is selected automatically shows the outlined area? As it would create a defined area one can easily see while not typing and the cursor is not focused inside the content area.

A suggestion for all blocks. Select a block. Move cursor outside the block area to have border/outlines appear around editable areas. Move cursor inside the block area and see the outlines disappear for each individual area that can be edited. This would be very helpful for the Group Block that contain inner blocks. As it is very difficult to select the parent Group Block today https://github.com/WordPress/gutenberg/issues/20453. Yes one can use the Breadcrumbs or hover the Block Type and see the Select Parent icon above it, but I would think that this method is not easily accessible.

[afercia]

Gutenberg is a full document editor, not a single textarea in a form.

This is an interpretation. A personal opinion that is not based on the way blocks actually work, semantically and functionally. Under all aspects, each editable block is, semantically and functionally, the equivalent of a textarea element with "rich text" capabilities.

Thinking at the block as a document "canvas" à la Google Docs is certainly possible but it's not the way the block editor works. The only way to make the block editor as accessible as possible is to reconduct as much as possible its user interface to the semantics and expected interaction provided by native HTML and/or ARIA widgets. That's it, simply put.

I read many other considerations here and in my opinion they mostly lack some good context or they're based on assumptions and incorrect information. I'm not going to reply to those considerations to not make this conversation longer than necessary and also because the tone and language that has been used in some of the comments above makes me feel uncomfortable.

Besides the technical aspects, I'd like to touch the ethical aspect implied in this discussion.

The WordPress community aims to be inclusive and welcomes diversity. Many persons in the community fully embrace these principles. Personally, I make these principles an important part of my personal and professional life. I'm pretty sure many others here do the same and we're all glad, and also privileged, to be part of this community.

What makes me feel very, very, uncomfortable is that, while the WordPress community is inclusive, the software is not. Not yet, at least. And I'm sorry to say that most of the design feedback I read here on this issue is not inclusive. Actually, what some persons are de facto advocating for on this issue is exclusion.

Today, it's about exclusion towards persons with low vision, cognitive impairments, etc. who benefit from a clear indication of focus. Tomorrow, it could be exclusion towards other "categories" of persons. I'd like to invite everyone to think deeply at the direction the block editor is going to take. The choices we're making now will have a huge impact on the block editor, and the WordPress community, for the years to come.

[folletto]

I totally agree with the conclusion, that's why we don't have to forget people with cognitive abilities either, which benefit from clearer pages, with less distractions, and less intrusive elements.

Thanks for your opinion.

[amandarush]

I totally agree with the conclusion, that's why we don't have to forget people with cognitive abilities either, which benefit from clearer pages, with less distractions, and less intrusive elements. Thanks for your opinion.

Did you test these assertions with actual people with cognitive or low-vision disabilities? My suspicion is no based on the years and years I've been advocating for and practicing web accessibility but I figured I'd go out on a limb and ask just in case of the very slight possibility I might be wrong. Everyone in this thread who is asking you to put back the outline around selected block isn't doing this because we want to be jerks and ruin the masterpiece. We're doing it because all of us have worked with users with these disabilities, and we've watched them struggle unnecessarily because that totally awesome idea implemented by that designer without these disabilities hasn't been tested with these users to find out if it's perceivable, operable, understandable and robust for everyone including those users, and we know based on experience that the solution we're proposing is the simplest way to achieve POUR which also comes with the bonus of having been tested with these users over and over and over and over again. Speaking as someone who has used WordPress for a very long time and who has benefited from the numerous accessibility gains that have been realized over the years I've been involved with it, I think those benefits should be extended to all users, and for the life of me I can't understand why there is still so much resistance to this stuff when it comes to Gutenberg specifically.

[StommePoes]

@paaljoachim pasted an animation showing a user clicking "in" and "out" of hot spots/hit areas.

Try this with screen magnification. Finding where a hit area even is (to click in it, or out of it, or to avoid it) when you can't see it is an amazing experience. Highly recommend. Set your mag level to, like, 6.

Using Windows High Contrast back when GMail was still using background-coloured divs to indicate a fake "bottom-border" of their input fields (before their customers/users tested their final product for free and had them finally/thankfully reverse that decision) meant that, for me, there was nothing at all to denote the field (because bg colours do not appear in WHC. Usually for good reason). I could see the label. I could not see the field, although I knew it was there. Somewhere.

Maybe the best description of the sensation would be: you're moving around in your bedroom in the dark, looking for something. It's your room, so you mostly know where everything is. But you're still wasting time fumbling for the thing where you sorta know where it is, because you don't want to wreck your night vision or the possibility of getting back to sleep by turning on the light.

That fumbling, hitting things with your hand you don't intend to or not finding that thing you're looking for... when I'm filling out any kind of form or editor, this is the last sensation I want. Perhaps the argument is that for some of the youth with the amazing vision, the outlines are causing this sensation while editing.

Idea: Add a single control to the user settings so people who don't want to see where anything is can turn all the outlines off (this lets all groups have the editing experience they want). There's a reason games have levels so you can choose how many monsters are trying to kill you.

[amandarush]

This seems something we can look into. Can you outline the differences in how VoiceOver deals with a full document, compared to what happens in Gutenberg?

No, this isn't something you can look into, because in short, you don't have access to any of the neat tricks assistive technology can take advantage of at the operating system level when dealing with native applications like Microsoft Word ETC. The following is from John Carson, who spent 20 years working for the developer/manufacturer of Jaws and now Zoomtext Fusion, who did the initial work when the Microsoft Active Accessibility API was first introduced so that things like Microsoft Word could be used by people who use screen readers, and who quite literally taught me everything I know about the internals of screen readers when I want to work for Jaws HQ 10 years after he started.

It is painfully obvious that individuals making such a statement has no clue on accessibility and how it obtains information to be converted to text to speech ((TTS) from the tools available from Microsoft Office applications, and if they had any knowledge of these tools for accessibility then they would not suggest for screen reader users to try Voiceover which is severely limited with MS products.

Let me explain basically how screen readers obtain information to be converted to TTS to provide feedback for screen reader users.

The following methods may not be used by all screen readers, however, screen readers as well as screen magnifiers that have a TTS component will utilize a combination of the tools available. First is a technique called screen scraping by utilizing components of video/video chain and what is commonly used now is mirror driver technology. Second is Microsoft Active Accessibility (MSAA) and/or UI Automation (UIA) which is 2nd generation MSAA. Third is the exposure of a Document Object Model so that screen readers/magnifiers can interact wwith objectsas well as their properties and methods.

JAWS takes advantages of all the mentioned tools, however other screen readers such as NVDA and the native screen reader for Windows which is Narrator mostly take advantage of MSAA/UIA and the MS Office DOM

Web browsers expose a very different set of tools for adaptive technology to tap into to provide feedback for individuals utilizing keyboards or even voice recognition.

Depending on the operating system, browsers provide totally different tools for accessibility, especially for different devices whether someone is using a computer or a mobile device.

Browsers provide information through several methods that is extensively documented by W3C and is comprised of properly written HTML/CSS as well as ARIA (Accessible Rich Internet Application) and the W3C DOM that most popular browsers such as MS Edge, Safari, Mozilla Firefox, and Google Chrome take advantage.

In short, Gutenberg is never going to be Microsoft Word but in a browser, no matter how much it looks like MS Word visually, and trying to avoid the basics of accessibility instead of just doing what WCAG along with a bunch of accessibility practitioners/experts tell you is like asking a carpenter to do an electrician's job using a plumber's tools.

[mtias]

There seems to be a broader discussion that needs to happen around how to conceive of the block editor (a combination of both separate blocks and continuous content) and what tools are available for us to craft it in the most pleasant, usable, and accessible way. Perhaps it's time we revisit role="application"? Like everything we do, this is an iterative process, hoping to make things better with each step and the collaboration of different perspectives. I think it'd be helpful if we avoid ontological axioms such as "Gutenberg is what the DOM says it is", though, as it limits what solutions we could imagine and build.

To the matter at hand around the use of block outlines, it'd be great if we could discuss all the implications without defaulting to a requirement that is, in essence, an interpretation: when should a block show a focus border?

There are also a few issues highlighted by the design work so far that have not been properly answered:

• Within the text of a paragraph, pressing Backspace will delete a character while if the block itself is in focus the entire block will be deleted. It is important this distinction is well communicated to users. The current implementation uses the block outline to signal block level operations. We cannot just apply the thinking that as a pseudo-textarea the highlight should be around its boundary when the behaviours can be so different depending on what actually is in focus.
• A similar thing happens when focus is placed on elements of the toolbar and not the block in the DOM, even though the block is still conceptually selected.
• Blocks also cannot be solely conceived as textareas when they have extra behaviours (like removing, splitting, navigating with arrows, etc) or when a block can have multiple textareas itself. The APIs we define for signaling the different states of focus have to be well constructed so that third-party blocks work consistently within the editor.

Maybe we need to rethink the use of textbox role for things like paragraphs, which only seems to partially match expectations (even line-break on Enter or Return is somewhat subverted, but that has a whole different set of complications in how users tend to understand paragraphs and line breaks).

In short, Gutenberg is never going to be Microsoft Word but in a browser

I don't understand this statement when Microsoft also has a browser version of its Word editor that works with web APIs. We could argue about the implementation details (application role, for one) and how well it might serve all needs, but a useful example for this conversation is how there you can insert an element like a table and see there's no focus indication on the table element as a whole nor on the table cell itself. Each cell has a contentEditable attribute set (works similarly to a textbox if we follow that thinking), but there's no accompanying focus highlight outside of the blinking cursor.

Google Docs also employs techniques like copying the current text (not the source DOM structure) into a separate element with id docs-aria-speakable to use for reading selection and movements instead of the source DOM (when the "screen reader" support is turned on, not by default). I'd imagine this is useful when there's no elegant mapping between the DOM for presenting content and the DOM for manipulating content. I'm not making a statement on how robust or recommended this approach is for us, but I think it's important we don't default to "just doing what WCAG says" when there is no straightforward answer to the intricacies of some of the problems a rich block editor presents. (That's not to say that it cannot be a valuable starting point, though!)

Another good example is the disagreement in https://github.com/WordPress/gutenberg/issues/22190 about whether down / up arrows should allow moving between paragraphs, since that is not the expected behaviour of a textarea / multi-line textbox in a web document, though it's the expected behaviour of a document editor in general.

I hope if we can discuss all the implications at length and avoid implying people are unethical when they seem to disagree with a given point of view (replying to @afercia again) that we could actually have a fruitful collaboration. There is not a straightforward interpretation of guidelines to cover all the interactions we have and we should see disagreements as a possibility to build something better together.

---

As an action point, we already have a setting to toggle a behaviour that restricts the cursor to any given block (you cannot traverse between blocks with the arrow keys), which makes the block boundaries a lot more assertive. What do you think of showing the border by default in such a case? It still has the problem of no meaningful differentiation from actual block selection, but perhaps it's still overall a better setup there to start.

[afercia]

Perhaps it's time we revisit role="application"?

role="application" introduces more harms than good and I wouldn't recommend it.

Not to mention it would need a substantial refactoring of many, many, parts of the block editor UI for which I'd estimate, very roughly, one year of intensive development at the very least. Google Docs, for example, uses role="application" on the body element, which makes the whole "document" an app where most of the native HTML semantics is gone. Everything, literally everything, including semantics and expected interaction, needs to be rebuilt via scripting. Google Docs is a highly-engineered application that goes far beyond what can be done in WordPress. To mention only one thing: in Google Docs even the single characters typed by users are sent to an ARIA live region to support screen readers.

Regardless, even imagining the block editor as a "canvas". a clear focus indication is a requirement.

[mtias]

I know :) It might still be worth considering opening that conversation again if we are running into limitations that hinder the experience.

[afercia]

It is still unclear to me whether a solution for WordPress 5.5 has been identified. I see there's a "try" pull request to use a background change as focus indication for the contenteditables: https://github.com/WordPress/gutenberg/pull/24354

That's already been discussed by the accessibility team and agreed it's not a sufficient focus indication.

Which leaves us with a problem: in absence of a solution, if WordPress 5.5 is released with the block editor in its current state (with no focus indication for the blocks being edited) well this is an obvious regression in the accessibility level compared to WordPress 5.4.

The accessibility team proposed a few options on the related discussions on Slack. Amongst them, it was also clarified that a focus indication doesn't necessarily needs to be a full outline around the blocks. For example, when a block being edited is made of other native form elements, focus indication on the forms elements would probably be a better solution. When the block is made of a contenteditable area )or multiple ones), then the contenteditable area needs a focus indication.

In short, the accessibility team made an effort to be propositive. What is the proposal from the editor team? Release "as is" with no changes?

[afercia]

Answering to a point from @StommePoes

Idea: Add a single control to the user settings so people who don't want to see where anything is can turn all the outlines off (this lets all groups have the editing experience they want). There's a reason games have levels so you can choose how many monsters are trying to kill you.

I think it's something definitely worth considering. To me, instead of a specific setting, it seems more interesting to better explore the concept of "modes" . I seem to recall at some point there was some sort of consensus in extending the block editor modes.

Given the default editor mode needs to be usable by everyone (and thus needs focus indication for any interactive / editable UI), other modes could be used for users that don't want a focus indication. For example, it seems to me "Spotlight mode" better fits with the idea of a "lighter" UI, which partially already is.

After more than 3 years of development and (sometimes passionate, to be fair) discussions on the block editor, it seems pretty clear there are different needs that can't be fulfilled by only one "mode".

A good premise however is that some of these needs haven't been ever tested with real users. While the accessibility needs come from more than 20 years of research, user testing, and data that ultimately form the W3C official recommendations, the needs for a "lighter UI" are mostly based on assumptions designers and developers make on behalf of a not-well-defined group of "users". Please do correct me if I'm wrong, but I haven't seen user testing and data suggesting that the removal of focus indication provides a better experience for users. And if I'm wrong, I'd appreciate to be pointed at the user testing and data that prove this is a real user need. Preferably, user testing made on a group of users with more than 5 persons 🙂

I don't want to dismiss the effort made on some user testing sessions that ran in the past, but usually those happened after a Gutenberg feature had been implemented and with very small group of users. I wouldn't call a group of 5 users sufficient to give some comprehensive, useful, feedback for a software that's used on 37.8% of the Web. Not to mention these small groups of users never included users with specific accessibility needs.

That said, for the future I'd propose to better discuss in what direction the block editor modes should evolve to better serve everyone. I also think opening this discussion to a broader audience (i.e. not on GitHub) would be greatly beneficial.

[francescamarano]

This is a regression, in terms of accessibility and for users in general. As an early adopter of GB, not having the border around the block I am working on is disorienting. The fact that the modal bar pops up once I click on a block (Without the border telling me where I am) is even more confusing.

I politely but strongly disagree with this statement

The initial decision of having sharp borders was because the concept of blocks was novel, thus we needed something to make it sharper and more clear as million of users were to be onboarded on a paradigm shift. It wasn't for accessibility reasons. The counter example is simple here: no text editor highlight the paragraph. The cursor is enough to know where the user is, and if a paragraph-level selection is necessary, one selects the paragraph.

First of all, there might be users that have opted to use the Classic Editor up until today and decided to give Gutenberg a go now. The concept of blocks is novel to them. Secondly, we (WordPress) should be leading, not conforming to how other editors do things. After all, this is the vision that is guiding Gutenberg

It’s time for WordPress’ next big thing, the thing that helps us deal with our challenges and opportunities. The thing that changes the world. We Called It Gutenberg For a Reason

Finally, I second @afercia closing statement

That said, for the future I'd propose to better discuss in what direction the block editor modes should evolve to better serve everyone. I also think opening this discussion to a broader audience (i.e. not on GitHub) would be greatly beneficial.

Posts on Design, then cross-posted on Accessibility, Core and Test should be the minimum with an invitation to test, so we can have some sort of user-tests.

[afercia]

Secondly, we (WordPress) should be leading, not conforming to how other editors do things.

Yes, please ❤️ Leading by example in following web standards, specifications, and best practices.

[folletto]

First of all, there might be users that have opted to use the Classic Editor up until today and decided to give Gutenberg a go now. The concept of blocks is novel to them. Secondly, we (WordPress) should be leading, not conforming to how other editors do things. After all, this is the vision that is guiding Gutenberg

I agree on both, I don't think there's any disagreement between what you said and these comments above. Note that again there's a big difference between now and when we launched. At launch there wasn't an ecosystem of tools, explanations, articles, tutorials, etc. Now all of these exist, we also refined the internal onboarding itself. On top of that Gutenberg improved a lot, added features, and also grew in complexity, all things that require changes. Evolution is a requirement of being leaders.

We have here design improvements that have been discussed for months — as noted above since November 2019, including being tagged for A11y, discussed in Chat, and referenced on Make — implemented, and now rolled out. There are rough edges for sure — I don't think anyone disagrees on that, at least nobody said anything so far here nor in Slack. It's important we work together in moving forward with constructive ideas that start by understand why certain improvements were done, and build together to have the best possible solution.

I note also that there are quite a few suggestions in this thread, including Andrea above repeating two of the ideas I suggested to try... 11 days ago. I'm not sure why the focus on this thread has been so antagonistic, instead of building on the constructive suggestions that were already done, not just by me.

—

But anyhow, let's move forward. We have the ideas, let's see what we can do about it.

Just to summarize, these are the two ideas that from the comments above and from the Slack discussion seemed to have consensus for an exploration:

1. We can explore other ways to highlight that don't divide vertically blocks, so not a full outline around the blocks — thus keeping text flowing across paragraphs and ease readability and legibility, which is an important goal to keep in mind.
2. We can explore in evolving out existing modes, making changes for example to "Top Toolbar" to be more of a focused writing more (there was a good point that the name is misleading), and enhancing "Spotlight" mode too. We can also consider introducing a "High Contrast" mode. This would have the additional benefit of being the standard approach for this kind of accessibility on many software tools and almost all operating systems, so it's already expected from users.

[mariohamann]

I find the discussion very exciting and would also like to share a few thoughts about it. I understand the argument that removing the borders creates a pleasant reading flow. Today I used the top toolbar for the first time - and I must say that pure writing in Gutenberg is really fun.

Differences to text editors

Gutenberg differs from text editors such as Pages and Word, however, by at least three characteristics:

1. continuous text consisting of headings and paragraphs in Gutenberg consists of several blocks which are completely independent of each other in terms of content and design. The omission of borders is deceptive in terms of the nature of the block principle.

2. At the same time, however, a block can consist of several text elements, such as in a card block consisting of heading and content. In this case, it is useful to inform the user that they are not editing just any text field, but text fields that belong to the card block. As far as I know, there is nothing comparable in text editors.

3. Finally, in Gutenberg elements can be nested within each other in a clearly defined hierarchy, which also influences the design and functionality. Below is an example of an accordion block: The heading is part of a single accordion element. The content of the accordion element, however, can be filled with any other blocks using the inner-blocks function. If the heading is selected, it should be clear that you are still editing the entire accordion element. If a block in the content area is selected, this should no longer be the case. Only a clear marking allows this distinction.

What do the others really do?

Based on the discussion, I looked at what other programs do in similar situations. Headings and paragraphs are known not to be marked by Pages, Google Docs etc. It becomes more interesting when you look at elements with text as content, which are more similar to blocks than simple continuous text:

table cells

• In Google Docs, currently selected cells are not selected.
• In Pages, Numbers and Google Sheet, current cells are marked - in Google Sheet, a shadow is even added when you are in write mode.

Text boxes

• In Keynote, Pages, and Google Slides, the borders of text fields are always displayed in the blank state. This is in line with @paaljoachim's suggestion and seems to be a great approach .
• As soon as you edit text fields, the respective borders are always displayed absolutely clear.
• Edit: In Keynote, when you select a "text frame", the usual "draggers" are displayed to enlarge the frame. These disappear when you enter text, but the frame remains. This is also the case in Apple Pages. This makes the difference very clear, for example, whether pressing the backspace key deletes individual letters or the entire element. With Google Slides there is no difference between the two different stages.

Personal conclusion

As I mentioned at the beginning, I understand the argument that you want to focus writing even more. But in my opinion Gutenberg is less a text editor (like the previous TinyMCE editor) but more a page builder. The people who just want to write text without any border lines can theoretically still use the "Classic Editor" block. But if blocks are to be the future, they should always be recognizable as such in their respective form. Based on the implementations in similar settings, the use of borders seems to make the most sense for me.

Edit

Within the text of a paragraph, pressing Backspace will delete a character while if the block itself is in focus the entire block will be deleted. It is important this distinction is well communicated to users.

I have not yet considered this consideration of @mtias. In fact, these are two different states in which different things can happen, e.g. when pressing the delete key. That' s why I have made some additions above. It seems as if there should be three different stages:

1. A block is not selected (e. g. no border).
2. A block is selected, but you are not in a textarea (e. g. blue border).
3. A block is selected, you are in a textarea (e. g. grey or black border).

[mariohamann]

I thought again about the balancing act between "focus on text" and "focus on blocks". More and more I became aware that we might be talking about two different modes here. I'm aware that there are currently already two modes, namely, "Select" and "Edit". I was wondering if a switch to two other modes, namely "Block Mode" (🧊) and "Text Mode" (📝) would be more appropriate. Other issues like could also benefit from this e. g. https://github.com/WordPress/gutenberg/pull/24372#issuecomment-669754639

The switch button at the top is rather meant for clearer visualization, less as an actual suggestion. There seem to be ideas to add more than two modes, e. g. https://github.com/WordPress/gutenberg/issues/23328#issuecomment-667049026 and therefore it makes sense to use the current dropdown to switch the modes, but maybe with some shortcuts like CTRL-1, CTRL-2 etc.?

Hover

🧊 Block mode

In "block mode", the borders of the blocks are immediately displayed on hover. I used a grey frame here to show the difference to a concrete selection. This is the same effect as the current "select" mode.

In this mode we could furthermore show the inserters as proposed in https://github.com/WordPress/gutenberg/issues/22867.

📝 Text Mode

In text mode, at least for the text blocks, no block frames are displayed for hovers. Here the text editor feeling is enhanced. This corresponds to the current behavior in edit mode.

Click

🧊 Block mode

In this case the "Block-Mode" works like an improved "Select-Mode".

1. the first click at a glance first marks the block as a whole. The block is marked with a blue frame to make the selection clearer. Pressing the delete key would delete the block. At this moment, for example, only functions that affect the entire block are displayed in the toolbar.
2. only the second click makes it possible to write the text (as also e.g. the cursor makes clear).The borders of the block are still displayed, but no longer in blue but in grey again.

Instead of switching to edit mode by double clicking, we would still stay in "block mode".

📝 Text mode

When you click, you are given the opportunity - as usual in text editors - to start writing immediately. The cursor adapts accordingly in advance. This again corresponds to the current behavior of Edit mode.

Move vs. Select

🧊 Block mode

In block mode the block can be moved by holding down the mouse button. This is a behavior known from several editors and would be a big improvement over the current "Select mode". In addition, this allows us to drag and drop blocks with the "Top Toolbar" enabled, which to my knowledge is currently not possible.

📝 Text mode

In text mode the text is selected instead. Here we are currently moving away a little from the behavior of text editors, because suddenly whole blocks are selected. This is the current behavior of text mode and may need to be reconsidered.

Conclusion

I must admit that these changes would be quite extensive and both modes would need to be maintained in the future. However, there are already two modes that need to be maintained.Whether this is the solution to the problem I can't say, but at least it might enrich the discussion to find the "final" solution. :)

[drake1337]

My mind is blown that this is even a problem. Would you PLEASE just use Occam's razor and go with the obvious simple solution? Just give the option to allow block borders to be viewed at all times? If people want the current they can, if they find the past interface easier to work with (borders always visible) they can!

Ever since the update occurred and the boarders have been removed, its much more difficult to quickly edit through blocks. Its supremely infuriating that I cannot at least go into some deep setting and change it back.

Are you making this for yourselves? Or are you making this with the actual end users in mind?

Are you putting forward solutions that you like, and work for you? Or consider the actual end user, and what solution they want?

Solution: Provide a choice between the current "no borders", and settings that allow the previous "borders always visible" as seen in the first post example 5.4. You can add your fun, more complicated option designs later (I am sure they will improve my experience.)

I just want to add I do like the update and how it has simplified the interface. I am not bothered by the simplification itself, I am bothered that there is not an option to add borders that are always visible to my blocks (like it was in 5.4).

I am also bothered that the goal is to simplify everything, but when an issue arises in regards to this simplification a long winded discussion with complex solutions takes place. Several people have flat out said they prefer to have permanent borders around their blocks, so provide the option in the settings.

[StaggerLeee]

Please give us back outlines, borders. For those people that enjoy new design make small filter to remove them.

Sorry, see on one old site padding problem is solved long time ago. My mistake.

[pattonwebz]

I would like the borders back too @StaggerLeee but could you edit your comment to be a little less offensive? We are trying to keep the contents of this thread nice - and constructive. Thank you :heart:

[StaggerLeee]

Sorry, I will. I am in the state of shock right now. And my eyes hurt.

[pattonwebz]

That is understandable, it is quite a striking change.

[StaggerLeee]

Is outline left for Quote block by purpose ?

[StaggerLeee]

As starting point. Needs to be adapted for few block types, makes bouncing.

.wp-block { padding:15px; } .wp-block:focus { padding:15px; outline:1px solid black; } .is-hovered { border:1px solid gray; padding:14px; } .is-hovered:focus { border:none; }

• All blocks are now expanded in Inserter.
• Title, the most important SEO thing, important database input, is now treated as simple text. No separation, no feel it is special in any way. I do understand all this with accessibility but don't ruin it for 99.95% of WP users.

[mariohamann]

I opened an issue for the different modes: https://github.com/WordPress/gutenberg/issues/24751

@pattonwebz @StaggerLeee @drake1337 Do you think the idea described in https://github.com/WordPress/gutenberg/issues/24751#issuecomment-678818957 could help you? I would be happy to recieve some feedback there.

[afercia]

Setting the milestone to WordPress 5.6 for visibility. Ideally, this issue should be solved even earlier in a minor release as it is a regression in the accessibility level compared to WordPress 5.4.

I'd like to suggest to go for the simplest option. The Gutenberg defaults need to provide an accessible experience to everyone. To me, that means that any UI that accepts text input must have a clear focus indication when it's focused and users input text. While it is true that in 5.4 the border was set on the whole block and not on the editable element, that solved the problem anyways, For analogy, also blocks that don't have a real editable area had the border when selected.

To me, this just needs to be restored. That said, I do realize different users do have different needs and preferences. Gutenberg already provides different "modes" to suit these needs. There are already the "Top toolbar" and "Spotlight mode" options that can be further expanded to provide a "lighter" interface. Looking at the discussion on the original implementation of these options, see https://github.com/WordPress/gutenberg/pull/9394#issuecomment-417027208, I'd tend to think we should follow that intent.

Worth also noting that the three options, Top toolbar, Spotlight mode, and Full screen, were intentionally kept separate to allow users to combine them if they want. To me, that means that "Top toolbar" should only unify the toolbars. Actually, "Spotlight Mode" is the one that is closer to a "Focus mode", at the point that its initial name was, in fact, "Focus mode". See https://github.com/WordPress/gutenberg/pull/8920. Also to note the demo video on that pull request: https://cloudup.com/cwaVMa9NygI where it's clear that Focus (Spotlight) mode was meant as a mode that "can be paired with making the toolbar fixed to the top". I'd really, really, like to see these existing options leveraged to provide a no-borders interface, while the default should always have a clear focus indication. This is the most reasonable compromise I can think of.

@mariohamann I love the exploration you made and the deep thinking you put on it. I had to read your proposal twice to understand it 🙂 I'm a bit concerned it would be way too complicated for users and I'd tend to think striving for simplicity is always the best option.