Making WordPress.org

Opened 8 months ago

Last modified 6 months ago

#7593 new task (blessed)

Remove the non-block editor

Reported by: dd32's profile dd32 Owned by:
Milestone: Priority: low
Component: Support Forums Keywords:
Cc:

Description

When we first introduced the Block Editor to the support forums (Dec '22 - Jan '23 #6608), there were concerns that lead to us adding an opt-out.

15 months later, there's been some problems along the way, but the vast majority of posts are made using the block editor.

I'd like to remove the option to opt-out, as keeping the option around only leads to extra code where bugs could hide. I've found a few over this time, mostly around edge-cases that can't be supported properly with the Blocks Everywhere plugin we're using for the editor.

For reference, looking at the last ~800k threads/replies (That's the last million IDs) ~4% of posts were made using the not-block-editor, but that was by 0.4% of users.

Using Blocks Posts Author Count (%)
No 29,379 (3.94%) 512 (0.39%)
Yes 715,847 (96.06%) 131,678 (99.61%)

Change History (16)

#1 @dd32
8 months ago

In 13548:

Support Forums: Blocks: When editing a reply/thread that was created pre-block editor, but now has a block editor, load the block editor upon save.

This fixes edits of old reviews showing block HTML, as old reviews can be edited in the new block editor.

See #6608, #7593.

#2 @joedolson
8 months ago

I think we need to get some user opinions from people with disabilities on whether it's OK to only provide the block editor. @alexstine, do you have opinions on the state of the block editor in the support forums at this point?

I know there are still some problems, such as it being impossible to add alt text using the block editor in the forums, which is important for many users.

This ticket was mentioned in Slack in #forums by courtneyengle. View the logs.


8 months ago

#4 @alexstine
8 months ago

I am not in favor of removing the non-block editor at this time. Maybe when we get serious about accessibility here, it can be discussed in the future but not until then.

#5 @dd32
8 months ago

I'm not inclined to agree with a blanket "no because Accessibility" here, not until an actual list of accessibility concerns are actually given with a chance for those teams to consider it / decide if it's a valid concern.

The Gutenberg features exposed on the forums are very minimal, the most basic functionality of Gutenberg, I'm genuinely surprised to hear that this basic functionality has problems with accessibility.

That's to say, I'd appreciate you actually try it, and report back with exact concerns.

such as it being impossible to add alt text using the block editor in the forums

While alt text is an important feature for accessibility, It's not one that would prevent someone using the Block editor. Notably; The only cases of images having alt= in the forums are people using the Block editor. Those not using the block-editor don't add alt tags to their images.

#6 @Cybr
8 months ago

I concur with @alexstine. I write faster in HTML and Markdown than I would using any WYSIWYG, and I'm sure I'm not alone.

Always allow plain text. The forums are for exchanging text, not making pretty things. Unlike 99% of the community, I will not be acquiescent to this; if the Block Editor were imposed, I'd stop using the support forums altogether and support my users elsewhere where plain text and Markdown are supported.

Related: https://wordpress.org/support/topic/canonical-url-problem-question/#post-17388850.

For fun, I just enabled the Block Editor again.

Immediately, before I could even type a single letter, I encountered an issue: I had to precisely hit the "Start writing or type / to choose a block" before I could start typing. Click anywhere else, hit any key, and I get shown a useless outline.

Once I precisely crossed the invisible text border and clicked, the entire interface flashed, and I had to be cognizant of what had happened.

Then I quickly made a typo -- which is on me. But double- or triple-clicking next to a word doesn't select the word or sentence respectively.

Then, Grammarly didn't kick in, which is a no-go for professional communication.

The Block Editor shouldn't even be considered a default in this state. Accessibility should never be an afterthought.

My eyesight is perfect (well, -0.10 on one eye). My monitors are calibrated. I have both arms and legs. My hands don't tremble. I do not suffer from headaches. I use a professional keyboard and a gaming mouse.
This is to say that I wouldn't "require" accessibility. However, Gutenberg's shortcomings in this area makes it inoperable for power users. I can only imagine what people with disabilities have to endure.

#7 @dd32
8 months ago

@Cybr Thank you for detailing your experience with it! That's very helpful. While I don't fully agree with every expectation you have of it, the basic problems you encountered are things that should definitely be resolved, and I'm going to try to duplicate it and find upstream issues for.

#8 follow-up: @alexstine
8 months ago

@dd32 I'm kind of shocked by your response but I guess I shouldn't be at this point. You have been around the community long enough to be well aware of this page.

https://github.com/wordpress/gutenberg/issues?q=is%3Aopen+is%3Aissue+label%3A%22%5BFocus%5D+Accessibility+%28a11y%29%22

There are only 449 current accessibility issues tracked in Gutenberg, but I sure can't imagine the problem with removing the option to not use it in the area where users come for support.

I haven't exactly been quiet about it and I made a lot of my initial concerns known in the ticket that introduced the Blocks Anywhere plugin and Matt went forward anyway, because nothing touches this site without his signoff.

For the issues:

  1. There is no longer a simple field to write a reply in, users must choose a block first. This adds complexity for non-technical users.
  2. The editor adds landmark pollution to the main landmark.
  3. There is no options menu like in the main editor so therefore no way for users to discover the shortcuts required to use the editor and all the custom interactions required for assistive tech. E.g. Moving between blocks isn't as simple as a click for us, it's press escape, navigate with arrows until you find what you think is the right block, and press enter to interact with it. Hopefully you're not wrong because it can be a guessing game.
  4. The list view option is read as a submenu, not sure how that happened. Maybe a plugin regression I guess.
  5. Shift+Tab does not move you to the block formatting toolbar, not sure why.

What I fail to see is why we're so hard pressed to make the experience harder for users to get and receive support. If this becomes the default experience, I truly hope plugin authors take support elsewhere and I'll support them anyway I can. Really, the best outcome for this would have been an option to edit in plain text or the Gutenberg editor that you could select on the new topic/reply forms but somehow I remember that idea getting shot down.

BTW, just because in your opinion people are not using ALT text doesn't mean we should remove the option.

It's clear my opinion doesn't matter so I'm going to see myself out. It's also getting harder and harder to not take this personally, I'm not just the annoying Accessibility Team, I actually live this daily.

EDIT: ALT text, @joedolson said it could not be added with Gutenberg so how are people adding it in the forums?

Others can feel free to respond from here.

Thanks.

Last edited 8 months ago by alexstine (previous) (diff)

#9 in reply to: ↑ 8 @dd32
8 months ago

Replying to alexstine:

@alexstine I'm aware of the listed issues, and I nearly linked it.

However, The Gutenberg interface shown on the forums is a tiny set of the most basic Gutenberg features. The issues facing many parts of the Gutenberg interface is absolutely irrelevant to the forums use-case.

For the issues:

  1. There is no longer a simple field to write a reply in, users must choose a block first.

The editor does have a paragraph block as the starting point, a block selection is not supposed to be required.
However, The tab indexes are indeed poorly arranged, resulting in landing on the toolbar and Block sections first.

That should be resolved, I'd have to explore whether this is a implementation detail, Blocks Everywhere, or Gutenberg issue.

This affects more than just those with accessibility needs.

  1. The editor adds landmark pollution to the main landmark.

I'd really need more details on how to see this, and how it actually affects the interface. It's not at all obvious to most of us who don't use accessibility tools of what the expected outcome is, or how to resolve it.

  1. There is no options menu like in the main editor so therefore no way for users to discover the shortcuts required

Enabling the Help / Shortcut menu's is possible. This seems like a very reasonable request, and one that is not otherwise tracked upstream, as it's an implementation detail.

  1. The list view option is read as a submenu, not sure how that happened. Maybe a plugin regression I guess.
  2. Shift+Tab does not move you to the block formatting toolbar, not sure why.

These seem like bugs that likely need to be tested and filed upstream.

What I fail to see is why we're so hard pressed to make the experience harder for users to get and receive support.

Given the option to disable the editor is already hidden in the user profile, this is really not about making it harder to receive support, but rather to streamline the experience and expectations in code.

Right now, those using the non-block-editor do not get their workflows tested, as it's such a small percentage of posts, instead it's just expected that every post is a block post.

Really, the best outcome for this would have been an option to edit in plain text or the Gutenberg editor that you could select on the new topic/reply forms

IIRC the problem is that it's not natively offered by the upstream interface being used, and so adding it in is prohibitively complex.

just because in your opinion people are not using ALT text doesn't mean we should remove the option.

It's not opinion, it's what the data says. There's no need to design/account for something that is not utilised.

EDIT: ALT text, joedolson said it could not be added with Gutenberg so how are people adding it in the forums?

I suspect it might be from copy-paste then, as that's correct, I've checked and there's no UI exposed for it currently.

It's clear my opinion doesn't matter so I'm going to see myself out. It's also getting harder and harder to not take this personally, I'm not just the annoying Accessibility Team, I actually live this daily.

Your opinion does matter, but opinion needs to be backed up with data and examples. I can't read your mind, I can't duplicate your experiences, I can't resolve anything If I don't have anything to provide a basic direction.

I've never once considered "The accessibility team is just annoying", but I do routinely wish that representatives of teams (Not specifically Accessibility! Other teams too) would provide adequate context to their requests and concerns. I can't do anything with "Team X feels this doesn't work".

Last edited 8 months ago by dd32 (previous) (diff)

#10 @Cybr
8 months ago

[...] but opinion needs to be backed up with data and examples.

Yes, but the data must be analyzed with the proper perspective. Or should I say a different perspective? Allow me.

Given the option to disable the editor is already hidden in the user profile [...]

Indeed, the adoption rate of the non-block editor is low because it isn't obvious that it has a toggle. We may see very different adoption rates if the toggle were underneath the editor.

The opposite adoption rate was there for Gutenberg versus the Classic Editor: Right before WP 5.0 was shipped, only 700,000 out of 22,500,000 WordPress sites used Gutenberg --- 97.69% of users stuck to the Classic Editor or another page builder. This number aligns with your findings above, but then for opposite ends.

Yet there's one big difference: Gutenberg's plugin was more in-your-face. It is a featured plugin. I even recall notifications about it in our dashboard. Yet, contrasting what would be logical, and only because of Gutenberg's insignificant adoption, the decision was made to foist WordPress 5.0's release with a 3-day notice. Otherwise, developers wouldn't be inclined to support the pre-alpha software with incoherent API and arcane coding standards, which subsequently caused WordPress.com to fail to compete against Wix because the Block Editor was suffering from plugin incompatibilities. Anyway... excuse my indulgent digression about the past.

Then, about this:

Those not using the block-editor don't add alt tags to their images.

I always added the alt-tags until I found they were removed during the saving process; perhaps this was a temporary issue, so I'll try it again later when I need to post images again. Still, this bug and the missing alt-text interface are why alt-tags are under-utilized, and it shouldn't be used as an argument in favor of the Block Editor.

#11 @alexstine
8 months ago

@dd32

This affects more than just those with accessibility needs.

Okay, so that is reason enough to not rush into this. Also, no, there is a click required to expose an input field to start typing. There is no label anywhere that says you are typing a reply that is associated with a field. It's because Gutenberg really wasn't designed for that. Gutenberg is a post editor, a very block-specific experience. Maybe not visually but that's how it is presented to blind users.

Number 5 is specific to Blocks Anywhere, again, the tabindex issue. It works fine in core/plugin.

IIRC the problem is that it's not natively offered by the upstream interface being used, and so adding it in is prohibitively complex.

Yeah, that is just an ableist view there. I think we should no longer put wheelchair ramps in because it's too hard and expensive, hopefully you revisit that way of thinking.

It's not opinion, it's what the data says. There's no need to design/account for something that is not utilised.

Again, the ableism. I don't care if it is the old editor or new editor, people need a way to add/save ALT text. If there is a bug preventing that, of course your data will not show it. Amazing.

I provide a lot of context 90% of the time but do realize we keep having the same conversations over again and I get tired of having to rehash things that have already been explained and dealt with. Accessibility isn't much bigger than Meta, WordPress is only a small fraction of my time which most of it is spent on trying to not let Gutenberg get worse.

Thanks.

#12 @codente
8 months ago

Accessibility as an afterthought is not the way to go here.

Further, the block editor is buggy itself so I don't think getting rid of the option to switch away from it because there might be bugs makes sense.

The vast majority of posts being done with the block editor is probably because people don't realize there is an option to switch away from it.

Last edited 8 months ago by codente (previous) (diff)

#13 follow-up: @joedolson
8 months ago

It's true that the block editor in the context of Blocks Everywhere is a simplified version of the block editor, and not all of those issues apply in this context. However, I think a lot of what this comes down to is speed; the block editor is more of a hassle to use than a simple text area, and offers very little in terms of benefits.

For what it's worth, I was able to get back to the block toolbar using Shift + Tab when using NVDA + Chrome and NVDA + Firefox; what's your combination testing that @alexstine?

I can appreciate that the code path is more complicated when we have multiple options available; but I also think that it's extremely important for users to be able to choose a simpler tool when that's what works best for them. Having a simple textarea where a user can type their response quickly and easily, without all the extra information contained in the block editor makes the experience considerably more efficient for many users.

The data about low usage feels disingenuous, given that the availability of the simpler editor has not been widely advertised and is difficult to enable.

The alt text issue *is* something that needs to be resolved in core, however. The fundamental issue is that the alt text field is in the settings panel, but should be editable directly in the block. It is more possible to add alt text in the old editor, however, since you have a code view.

Overall, I feel like we don't have any real information about whether users prefer the block editor or not; and the data we have about usage is problematic, given that users don't have a lot of choice. But I also feel that for the vast majority of users, it probably doesn't make any difference at all which editor is in use. But as is common for accessibility issues, it is extremely important for the people it impacts. This is why numbers like "how many people are using this" are not really relevant.

#14 in reply to: ↑ 13 @alexstine
8 months ago

Replying to joedolson:

It's true that the block editor in the context of Blocks Everywhere is a simplified version of the block editor, and not all of those issues apply in this context. However, I think a lot of what this comes down to is speed; the block editor is more of a hassle to use than a simple text area, and offers very little in terms of benefits.

For what it's worth, I was able to get back to the block toolbar using Shift + Tab when using NVDA + Chrome and NVDA + Firefox; what's your combination testing that @alexstine?

I can appreciate that the code path is more complicated when we have multiple options available; but I also think that it's extremely important for users to be able to choose a simpler tool when that's what works best for them. Having a simple textarea where a user can type their response quickly and easily, without all the extra information contained in the block editor makes the experience considerably more efficient for many users.

The data about low usage feels disingenuous, given that the availability of the simpler editor has not been widely advertised and is difficult to enable.

The alt text issue *is* something that needs to be resolved in core, however. The fundamental issue is that the alt text field is in the settings panel, but should be editable directly in the block. It is more possible to add alt text in the old editor, however, since you have a code view.

Overall, I feel like we don't have any real information about whether users prefer the block editor or not; and the data we have about usage is problematic, given that users don't have a lot of choice. But I also feel that for the vast majority of users, it probably doesn't make any difference at all which editor is in use. But as is common for accessibility issues, it is extremely important for the people it impacts. This is why numbers like "how many people are using this" are not really relevant.

@joedolson You can reach it with shift+tab but it isn't the first tab stop so you have to go a ways for it. I find this confusing for users who don't know Gutenberg. Thanks.

#15 @dd32
8 months ago

In 13571:

Support Forums: Blocks: Resovle some style issues in the editor making buttons and functionality invisible.

See #7599, #7593.

#16 @dd32
6 months ago

In 13791:

Support Forums: Blocks: Properly style the Blocks Everywhere interface in the old support theme.

The new support theme that defines the base variables hasn't been activated everywhere.

See #7599, #7593, [13571].
Closes https://github.com/WordPress/wordpress.org/issues/326.

Note: See TracTickets for help on using tickets.