Reconsider the 'Accessibility' section in the Preferences modal dialog

[afercia]

Description

After #56481 / #56510 the Preferences modal dialog now contains a new 'Accessibility' tab panel that only contains two preferences:

• Contain text cursor inside block
• Show button text labels

Screenshot:

Across the history of this project, prior feedback has been already provided about not havint a separate 'Accessibility' froup of options / preferences. Besides usability and discoverability concerns, there's also some 'philosophical' and ethical considaration. I'd kindly propose to reconsider this recent change and not group any preference within a separate 'Accessibility' section.

Some concerns have been previosuly expressed in #16354
To recap, quoting:

• A separated 'Accessibility' section pigeonholes those options when they are actually useful to people for all sorts of reasons very much including personal preference.
• I worry slightly that introducing a new Accessibility set of options could encourage future options that require people who rely on assistive technology or other accommodations to opt-in for a usable experience
• I don't think that accessibility should be opt-in.
• Adding options for accessibility will just encourage bad decisions and a way of thinking like "we'll do what's pretty and then dumb it down for those that need it". It sets a bad precedent.

I'd totally agree that there should bot be 'accessibility options' as accessibility should be baked in for every UI in the editor. To me, some of these preferences are just normal user interface preferences. Personally, I would reall like to not have an 'Accessibility' section. I'd like to hear thoughts about this from other accessibility specialists Cc @joedolson @alexstine @andrewhayward

Specifically to the 'Show button text labels':
it isn't really an accessibility-only options. It's more a matter of personal preference for all users. As such, I don't think it should go in the Accessibility section. As mentioned in other issue, for example, the macOS Finder doesn't place this preference into an Accessibility group. It's a general UI preference available on right-click on the Finder toolbar. Screenshot:

Also available in the 'Customize Toolbar...' panel. Screenshot:

See also more feedback on not considering this as an 'accessibility' option on these comments:
#10524 (comment)
#10524 (comment)

To me, this preferences is a general UI preferences and should go within the 'Appearance' tab panel.

Instead, I do realize the 'Contain text cursor inside block' is more technical and more targeted to keyboard users. However, again, keyboard users ia a broad category of users not necessarily related to specific accessibility needs. For some useers, it is just a matter of personal preference.

Overall, these features may benefit all users based on personal preferences or personal needs. I don't think the should live in a separate 'Accessibility' section. Cc @mtias

One of the arguents to have an 'Accessibility' section in #56481 / #56510 the is that new preferences like the Contrast preference would live in the new ection. However, again, I'd see the Contrast preference more like a general UI preference, not strictly related to accessibility

Lastly, philosophically and ethically, a separate 'Accessibility' section hints to considering Accessibility as something 'separate from normal', which is a concept that I'm afraid I can't support as it is not inclusive. Also, it sorts of relegates 'Accessibility' to a role of second-class citizen.

Step-by-step reproduction instructions

• Open the Preferences modal dialog.
• Observe there is now a separate 'Accessibility' tab panel.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[alexstine]

@afercia I agree with what you said but I sometimes just go with the path of least resistance. Whether that is great long term stands to be argued.

Lastly, philosophically and ethically, a separate 'Accessibility' section hints to considering Accessibility as something 'separate from normal', which is a concept that I'm afraid I can't support as it is not inclusive. Also, it sorts of relegates 'Accessibility' to a role of second-class citizen.

In all fairness, if I fought everything/every time that does this to me, I'd have no energy left at all. A good majority of websites are starting to come out with dedicated accessibility sections. Slack, Microsoft Teams, Google sites, Microsoft sites, etc. I think it's a perseption thing and you can't always be of the opinion that you are a second class citizen even though the majority of the time, it may be true. Google Docs today still requires you to enable accessibility support before you can barely use it because even after, it's pretty terrible. Before, it's totally unreadable.

My point, we can try to fight this in Gutenberg or eventually just accept this as the paradigm major sites/platforms are starting to adopt.

Would be interested to hear others opinions because this does of course have limits. I will never allow Gutenberg to get to the point where everything is inaccessible before you check the enable accessibility mode checkbox. At that point, I will consider the project too far gone to have any lasting positive impact.

Thanks.

[joedolson]

There are two points that make having an accessibility settings section potentially worthwhile:

1. It may make some features easier to find for those who need them, and
2. Not all accessibility features can be turned on by default. Some accessibility features can directly conflict with other features. Though it's not relevant to this case, an example would be a low contrast and a high contrast mode. Both are features that can benefit specific needs; but they are directly opposite, and you cannot use them both at the same time. As such, there will always be a need for settings to choose the user experience for a specific user.

So, while I'm still philosophically opposed to segregating accessibility settings, I can also see that those settings can be necessary and having the section clearly marked out can make them easier to find when needed.

I'll note that Windows does not call their 'Accessibility' section accessibility settings; they call it "Ease of Access", which I suspect is just trying to avoid that terminology. Personally, I'd rather just call them accessibility settings, and not mask the intent with terminology. It decreases the mental burden of remembering what this application calls those settings.

[annezazu]

Thinking about broader PRs that have stalled and ways we can move forward, I can see a preferences section like this being helpful to get more accessibility features added to turn on as you'd like and make these options easier to find. For example, these PRs on A11Y enhancements for useTabNav and try arrow press confirmation before switching blocks. As Alex said, lots of tools are coming out with or have long had sections like this and I could see it being something that could more easily help folks find what they need/know what's possible for customization.

In the long run, looking at phase 3 efforts where folks can personalize their experience more (select or pin access to certain sections, create custom data views to filter by, etc) I could also see this aligning well with that angle.

[afercia]

Thanks @alexstine @joedolson @annezazu for your thoughts.

I'd like to note that at the very least I would have liked to see this conversation happening before the changes introduced in #56481 / #56510. That means I would have appreciated WordPress contributors historically more versed in accessibility to be involved in the process that led to this change and not just have to 'accept' it. I'm not sure introducing changes that ignore prior feedback, and thus implicitly dismiss it, is the best way to encourage collaboration and contribution to this project.

That said, more specifically to the new content organization of the Preferences modal dialog:

The 'Show button text labels' preference now lives in the section: 'Accessibility > Interface'.

but

there's already another 'Interface' section In 'Preferences > General > Interface'.

To me, having two 'Interface' sections is redundant and confusing for users. I see the one in the 'General' section contains preferences of various nature: list view, block breadcrumbs, right-click. To me, 'Show button text labels' should be moved there as it's not an accessibility specific feature: it's a general UI preference no different from the one in the macOS Finder.

Alternatively, it could be moved to the section 'Preferences > Appearance', which has a pretty appropriate description:

'Customize the editor interface to suit your needs.'

To me, this description makes the 'Appearance' section the most appropriate place for many preferences related to specific user needs. No need to label other preferences as 'Accessibility' or 'Eas of access' specifically, if the concept of 'specific needs' is already in place in the Appearance section.

That leaves us with the 'Contain text cursor inside block' preference.
This one is pretty technical and I'd agree it warrants its own section. However, I think the preference description can be improved:

Keeps the text cursor within the block boundaries, aiding users with screen readers by preventing unintentional cursor movement outside the block.

This preferences may help all keyboard users, not only screen reader users. I'd just change aiding users with screen readers to aiding users who prefer to use the keyboard.

Screenshot: two 'Interface' groups in two different sections:

[andrewhayward]

To probably add not much...

...having two X sections is redundant and confusing for users. [...] To me, Y should be moved there as it's not an accessibility specific feature.

Unlike operating systems, the range of strict accessibility features available in WordPress will probably be pretty narrow, and for the most part, I would imagine that there could be an argument for almost any accessibility-related setting to be somewhere else.

That being said, there are always going to be settings that some subset of users will have a particular need for. So while it goes without saying that I'm in agreement with previous sentiment, and "philosophically and ethically" opposed to treating accessibility as something separate, I also don't entirely see grouping some settings together as necessarily being in opposition to that.

This is of course not to say that we should allow that to be an implicit license for the defaults to be inherently inaccessible. And it also doesn't mean that settings should just get thrown in without careful consideration. But having some particular settings easily discoverable is to me an accessibility feature in and of itself, even if only from a cognitive perspective.

On the flip side, I do think that there's a great deal of value in putting "accessibility" settings into "mainstream" groups. Whether users discover an option they never knew they needed, or are just exposed to a broader experience that makes them think a bit, we should definitely be asking if tucking some settings away in a tab most people will never visit is actually constructive or an "improvement". It would be interesting to know the thought process that went into the reorganisation.

I'm almost inclined to suggest that perhaps settings could appear in multiple tabs, grouped both by function and by need. However, we probably don't have enough settings to warrant it, and while it might be useful for some users, it could also be confusing to others.

Maybe there's a setting to show/hide the accessibility tab... but would that be an accessibility setting, and if so, would it be on the accessibility tab?!

---

TL;DR I don't think an accessibility tab is inherently a bad thing, and for many users it would probably be beneficial. But it might also be that we don't have enough settings to warrant it, and those settings could be better integrated into existing groups. Either way, ensuring settings organisation happens as part of an open conversation is important, even if eventually someone has to make a decision.

[mtias]

Thanks for the thoughts! An Accessibility section certainly doesn't aim to make accessibility opt-in, so let's put that to rest.

Quite the contrary, it recognizes that there's a wide range of preferences that go beyond trivial appearances and modify how people interact with the software, helping them access functionality in different ways.

We can always discuss the specific placement of individual settings based on how likely users are to find them. I don't necessarily have a strong opinion on where to place the text labels, but I think it'll be more discoverable where it is now.

Adding a configurable keyboard shortcut for invoking the toolbar also makes sense here. A feature like #41363 could land on this panel. I'd expect to add more tools here, like some double-click actions that have been discussed before; right click context menus on list view or elsewhere; and long press to lift and drag a block as an opt-in.

I'd just change aiding users with screen readers to aiding users who prefer to use the keyboard.

I don't think this phrasing is right. People that "use the keyboard" includes people that expect to use arrows to move between paragraphs. It'd be confusing phrased this way. Happy to use something else if it can be improved.

[joedolson]

Regarding the organization of settings, I'd really prefer that settings were less dependent on a specific, linear structure. We should have searchable settings, so that we can add meta data for a setting. E.g., finding accessibility settings could be a search for 'accessibility' or related terms that pulls up any setting that reasonably relates to accessibility or usability. But since we don't have that right now, it's not unreasonable to have some kind of grouping.

The phrasing on how to describe the text cursor block boundaries is tricky. It changes the behavior of keyboard navigation, which is probably more beneficial for screen readers, but may also be useful for keyboard users who aren't using screen readers. The important part, in my opinion, is having a clear description of what the feature does, rather than who it's theoretically for. If people understand what it will do, then they can decide for themselves whether it's useful.

I'm not sure we should be making assumptions about the impacted audience. e.g. 'Keeps the text cursor within the block boundaries, aiding users by preventing unintentional cursor movement outside the block.'

[afercia]

The phrasing on how to describe the text cursor block boundaries is tricky. It changes the behavior of keyboard navigation, which is probably more beneficial for screen readers, but may also be useful for keyboard users who aren't using screen readers. The important part, in my opinion, is having a clear description of what the feature does, rather than who it's theoretically for. If people understand what it will do, then they can decide for themselves whether it's useful.

I'm not sure we should be making assumptions about the impacted audience

That was my point. Mentioning a specific assistive technology is incorrect ant it's an assumption. Alsom it reinforces the incorrect perception that accessibility is only about screen readers, which is misleading and doesn't help educaiton of users and developers.

[mtias]

Searching preferences would be a great feature, we should add a separate issue for it.

[joedolson]

Opened two new issues to reflect these conversations.