Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Radio button automatically changes the context on user focus #15328

Open
karlgroves opened this issue Apr 30, 2019 · 6 comments
Open

Radio button automatically changes the context on user focus #15328

karlgroves opened this issue Apr 30, 2019 · 6 comments
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Technical Feedback Needs testing from a developer perspective.

Comments

@karlgroves
Copy link

Radio button automatically changes the context on user focus

  • Severity: High
  • Affected Populations:
    • Blind
    • Low-Vision
    • Motor Impaired
    • Cognitively Impaired
  • Platform(s):
    • All / Universal
  • Components affected:
    • Document Panel
    • Publish and Unpublish

Issue description

Under the "Visibility" section of the Publish panel, there are three
radio buttons named "Public", "Private" and "Password". When the
user selects the "Private" option, an alert appears asking if they
want to publish the post privately, and clicking "Yes" then publishes
the post immediately. This behaviour is not consistent with the expected
behaviour of radio controls, and is not consistent with the behavior of
the other two radios in that group.

Additionally, if the user clicks "No" in the alert, the focus is
shifted to the "Public" radio control, rather than shifting back to
the "Private" radio as would be expected.

Remediation Guidance

Remove the alert-and-publish behaviour from the "Private" radio, so
that it behaves like a standard radio control. This will also resolve
the focus management issue.

Relevant standards

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-16 in Tenon's report

@gziolo gziolo added the Needs Accessibility Feedback Need input from accessibility label Apr 30, 2019
@melchoyce
Copy link
Contributor

Screenshot from full report:

image

@afercia
Copy link
Contributor

afercia commented May 5, 2019

Not sure if there's a technical reason for the JS alert in the first place. This behavior has always been a bit annoying and may be completely unexpected for some users.

If an user confirmation is necessary for some technical reason (can't think of any off the top of my head), would be great to explore an alternative solution that doesn't change context unexpectedly.

@afercia afercia added [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Technical Feedback Needs testing from a developer perspective. and removed Needs Accessibility Feedback Need input from accessibility labels May 5, 2019
@karmatosed karmatosed added the Needs Design Feedback Needs general design feedback. label May 6, 2019
@mapk
Copy link
Contributor

mapk commented May 10, 2019

Related to #12023.

Unfortunately, it appears to be somewhat of a Core bug due to WP not being able to save the state "Private" on a draft post. I'm not entirely clear about whether the alert box is a Gutenberg issue or also appeared in Classic editor so leaving this issue open for now.

Let's see if work can be done on #12023 to help resolve this.

@mapk mapk removed the Needs Design Feedback Needs general design feedback. label May 10, 2019
@afercia
Copy link
Contributor

afercia commented May 10, 2019

I'm not entirely clear about whether the alert box is a Gutenberg issue or also appeared in Classic editor

No alert appears in the Classic Editor, I guess simply because the setting is saved when submitting the form.

@sarahmonster
Copy link
Member

This is an instance of underlying technical limitations driving a sub-optimal design. See also #9396 for extensive discussion. The approach in #12023 shows promise from both a design and accessibility perspective; let's see if we can't help move it along. 🚀

@joedolson
Copy link
Contributor

Is it viable to add a new post status that's more similar to 'future', but indicates that the post will be private when published? E.g., implement status variants such as future-private, draft-private, etc.? These could be stored internally as post meta, and processed at publication to set the status as well as display the expected status in the editor.

Advantages: no need to change anything about post statuses, ability to process autosaving with awareness of a status change but without implementing the change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Technical Feedback Needs testing from a developer perspective.
Projects
None yet
Development

No branches or pull requests

10 participants