Custom field check box automatically changes the context on user focus

[karlgroves]

Custom field check box automatically changes the context on user focus

• Severity: High
• Affected Populations:
  • Blind
  • Low-Vision
  • Motor Impaired
  • Cognitively Impaired
• Platform(s):
  • All / Universal
• Components affected:
  • Tools and Options

Issue description

The "Custom Fields" checkbox within the "Options" dialog causes an
unexpected page refresh when the user selects it, and consequently
resets the focus position to the top of the page.

This is not expected behaviour for checkboxes, and the sudden change of
context may be confusing for assistive technology users, while the loss
of focus position will force keyboard users to manually navigate back to
where they were before.

Remediation Guidance

If it's not possible to update the page in the background, as happens
with other checkboxes in the "Options" dialog, then the user should be
warned (with visible text, not visually-hidden) that selecting this
option will close the options dialog and reload the page.

Alternatively, an "Apply Changes" button could be added to the dialog,
which confirms the user's changes for all checkboxes (i.e. none of the
checkboxes cause background updates or page reloads until the user
explicitly presses the Apply button).

Relevant standards

• 3.2.5 Change on Request (Level
  AAA)

Note: This issue may be a duplicate with other existing accessibility-related bugs in this project. This issue comes from the Gutenberg accessibility audit, performed by Tenon and funded by WP Campus. This issue is GUT-65 in Tenon's report

[melchoyce]

Screenshot from the full report:

[afercia]

+1
Note: when there are unsaved changes to the content, a JavaScript confirm dialog will ask if you want to reload the page but that's unrelated. To reproduce, save your changes first and then click the
"Custom Fields" checkbox.

[sarahmonster]

The design team discussed this during a triage session in Slack today (Note: You may need a Slack account to log in.)

The best solution, from both an accessibility and a user experience perspective, would be to avoid this page refresh altogether, since it's not in line with user expectations of how checkboxes typically work on the web. (Checking a checkbox doesn't usually refresh the page.)

If the page refresh is strictly unavoidable, we could add some warning text to the label: "(Requires page refresh)” or similar, but this is something of a band-aid solution. First, we'd like to explore ways of avoiding that refresh altogether.

Technical feedback and/or explorations here would be super helpful!

[karmatosed]

I am removing the 'User Experience (UX)' label as part of a label cleanup. It's not being used anymore consistently so let's try and keep to 'needs design' and 'needs design feedback'. If we find a need for another label we can consider it but having those 2 should cover this.

[noisysocks]

The checkbox works by registering and de-registering the pre-existing postcustom meta box (#11084). When this meta box is registered, the WordPress backend will include the necessary HTML, JS, and CSS for the Custom Fields form. When any meta box is registered, WordPress will instruct the block editor to watch for post saves and, upon save, make an additional POST request which updates the post's meta boxes.

Custom Fields are disabled by default. We want to avoid including unnecessary frontend resources and making two requests per save in the majority case. Therefore, we decided (#10676 (comment)) to require a page reload to toggle the setting.

We could, in theory, avoid the page refresh by manually injecting the HTML, <script> and <link> tags into the page when the option is toggled on. It would be challenging to maintain such an approach, though.

We could also look into rebuilding the Custom Fields UI to be a React-based component that uses the REST API. This would require some work, though, as we would need to add support for Custom Fields to the REST API.

I don't think either of those two approaches are worth the development effort involved. Custom Fields is a feature without that exists only in the block editor for backwards compatibility with the classic editor.

Instead, I think it's best that we polish the existing mechanism to make it less jarring and more accessible. I'd encourage us to explore adding a Page reload is required button that appears after the checkbox is toggled.

[marekhrabe]

Looking at the code, what about using already established DeferredOption? It visually looks like all other checkboxes but its handler (the function doing the actual work to save the new value) is called only once the modal is dismissed.

DeferredOption is currently used for the option of "Show Tips" where they only get enabled after you close the modal to prevent UI collisions.

What I imagine a flow might look like:

• open Options
• toggle "Custom Fields" checkbox
• its label can be updated to mention the page reload but nothing else happens
• close modal
• only now we finally perform the reload

If user changes their mind and flips the option back to the initial state before they close the modal, no reload will be performed once they do close it.

This should be fairly easy to implement and leverages code already in the repository.

[marekhrabe]

I've made #15688 to explore this variant. Let me know how it works for y'all.

[afercia]

@marekhrabe thanks for exploring a solution for this issue.

close modal, only now we finally perform the reload

I'm not sure this actually solves the root issue, it just changes the moment when an unexpected page reload happens 🙂

When closing any modal, the expected interaction is that focus is moved back to the button that triggered the modal. Note: we're already doing an exception here because, at that point, the More menu is closed so focus is returned to the only logical place: the More button. Triggering a page reload when would be completely unexpected, even with the info text added to the checkbox label.

I'd suggest to explore the additional button suggested in the report.

[marekhrabe]

Agreed - I have the same feeling from the interaction but it was the easiest option in code so I thought I'll start with it. I will have a look at the button option and try something out

[gziolo]

I think @noisysocks explained in-depth (#15320 (comment)) why it works the way it works. It's suboptimal and would be very hard or time-consuming to fix for something which is going to be used by a very small group of users. It's definitely not our priority.

[marekhrabe]

I've updated my exploration PR to use an additional confirmation button. Can somebody take a look?

[mapk]

Here's what the confirmation button looks like in a screencast.

This is a good route. Let's restyle the notification to look more like a notification and I think we'll be good.

Maybe something like this? Notice the alignment adjustments too...

[marekhrabe]

Before we proceed, could @afercia confirm we are solving the issue the right way? To me it feels better both visually and in Voiceover but I’m not a regular Voiceover user so my point of view is not that important.

[afercia]

A notice (also a spoken notice) and the reload happening on user action sound good to me, thanks!

[mapk]

Just to note here, I'm thinking a yellow notification makes more sense here. It's a warning notification rather than an information one.