Addressing Proximity in the admin area

[trishasalas]

This ticket is to address proximity issues in the admin area as a whole.
New tickets should be created for individual issues as they are found and reported.

Background:
In web design, the principle of proximity states that related items should be placed close together. By the same token, if things are spaced farther apart they appear to have less relation to one another.

This principle is especially critical for users with low vision. It will even be addressed in the next draft of the WCAG guidelines! ​See Accessibility Requirements for People with Low Vision

Additionally, there will be ongoing education in ​Make WordPress Accessible to help better understand the issue so that problems become more apparent.

[afercia]

It would be nice to add some screenshots and references. Moving to future release as per today's accessibility bug scrub.

[afercia]

Some resources, highly recommended for designers and UI/UX folks:

Types of Low Vision
​https://webaim.org/articles/visual/lowvision

W3C draft: Accessibility Requirements for People with Low Vision
3.6 Point of Regard and Proximity
​https://www.w3.org/TR/low-vision-needs/#point-of-regard-and-proximity

Point of Regard and Proximity of Controls (straw test)
​http://www.d.umn.edu/~lcarlson/wcagwg/point_of_regard/#straw_test_2

Youtube video (2 mins): the straw test in action, by Derek Featherstone
HCB University: Accessibility 101 "The Straw Test"
​https://www.youtube.com/watch?v=S1j6CYT3kWA

Post about a similar accessibility session by Derek Featherstone:
Responsive Design & Accessibility
​http://www.berndtgroup.net/thinking/blog/ux/responsive-design-and-accessibility

[afercia]

Some screenshots with clear examples of how UI controls can be very hard to discover for people with low vision, visual field loss, screen magnifier users, etc., due to lack of proximity:

Quick edit (same for Bulk edit):

Reply to comment (same for edit comment):

Save/Delete menu:

Appearance > Theme details: notice "Delete" is on the right:

Customizer > Theme details: notice the placement of controls is inverted compared to the Appearance screen. This forces users to "learn" a new interface and introduces inconsistency with no apparent reason:

Gutenberg (see the toolbar on a very large display):

Additionally, across the whole WordPress admin, the primary action button (the blue one) is placed inconsistently. Sometimes it's on the left, sometimes on the right. I guess this is mostly for historical reasons: in a so large project it's perfectly understandable to have some inconsistency across UI sections that were designed at different times. I seem to remember this was also discussed a few times but never fully addressed. It would be great to establish a solid, predictable, pattern and always have the primary action button where users expect.

Lastly, worth noting a new pattern was recently introduced in the edit term screen, see [40655]:

In this case, the placement of controls is far better for accessibility: the "delete" link is next to the update button and easily discoverable. I understand the concerns about avoiding unintentional clicks so I'd agree there should be some grade of separation between the primary action control and a Delete/Cancel control, but I'm confident this can be achieved respecting the proximity principle.

[melchoyce]

Based on ​https://www.lukew.com/ff/entry.asp?571, I think we should:

• Have the primary action (like update, etc.) on the left, as a primary button.
• If relevant, list secondary actions immediately to the right of the primary action, as secondary buttons.
• List all negative action (cancel, delete) next, as links.

In most cases, the actions should be left aligned, to line up with the forms. This would happen on Settings, bulk edit screens, edit term screens, etc.

In the case of things like the theme modal, actions should remain centered (since the content within the modal doesn't follow the same left-aligned linear path as forms do).

I don't know that these rules should apply to Gutenberg, where related actions are already grouped together — but I'll let @karmatosed or @joen chime in about it, since I haven't been super involved in that discussion.

[karmatosed]

Have the primary action (like update, etc.) on the left, as a primary button.
If relevant, list secondary actions immediately to the right of the primary action, as secondary buttons.
List all negative action (cancel, delete) next, as links.

The above is more or less what Gutenberg is following. We have a slight variation on actions outside of forms or assumed forms. Our actions are grouped together also which adds a different context in some cases, a strong example of that is an ellipsis (more) menu.

[cathibosco1]

We looked at this in our design triage session today - The new pattern looks great but for accessibility the buttons should not be at opposite sides of the screen - what is useful is:

1) making sure the distance between buttons (or links) is sufficient to avoid clicking wrongly
2)consider making the clickable area of the links large enough too...

It can be tested to meet mobile standards here: ​https://search.google.com/test/mobile-friendly

Hope this is helpful. My thinking is that the buttons should be centered in the order of hierarchy

Thoughts?

[afercia]

@cathibosco1 sure thanks :)

so ideally the patch would be updated to exclude the change in button alignment

Maybe wrong ticket? This ticket is a general tracking ticket for the proximity of controls and illustrates various examples, including the theme details modal. It doesn't have a patch attached :)

As per the details, I totally agree with the pattern detailed by @melchoyce in the previous comment https://core.trac.wordpress.org/ticket/40822#comment:9 also considering, as @karmatosed said, that's also what Gutenberg does.

I understand the concern about avoiding clicks on the wrong button, but probably that should be addressed increasing the clickable area, as mobile operating systems do (see screenshot below). I guess it should be addressed separately though, as part of a buttons redesign.

[afercia]

Primary action and destructive action in Android (Emotion UI)

[afercia]

Quoting from the latest W3C "Accessibility Requirements for People with Low Vision" draft
(Editor's Draft 03 January 2019, at the time of writing)
​http://w3c.github.io/low-vision-a11y-tf/requirements.html#proximity-of-related-information

[Edit] Update – on May 31 2019, it is now "W3C Editor's Draft 02 May 2019"

Proximity of Related Information

People with limited field of vision or who use large text have little in their field of view at one time. If related information is not close together, they can have trouble knowing about it, seeing it, and using it. In most cases, it is best if:

• Related information — such as labels and controls, instructions for data fields, matching tests in two columns, and feedback — is in close proximity.
• Feedback is in close proximity to the user’s visual focus.
• Dialog boxes and other such pop-up messages appear over the users' point of regard.
• Users are informed of new information that may be outside of their view — such as a new browser tab opening in the background.

[cathibosco1]

Thank you for finding my error @aferica

Replying to afercia:

@cathibosco1 sure thanks :)

so ideally the patch would be updated to exclude the change in button alignment

Maybe wrong ticket? This ticket is a general tracking ticket for the proximity of controls and illustrates various examples, including the theme details modal. It doesn't have a patch attached :)

As per the details, I totally agree with the pattern detailed by @melchoyce in the previous comment https://core.trac.wordpress.org/ticket/40822#comment:9 also considering, as @karmatosed said, that's also what Gutenberg does.

I understand the concern about avoiding clicks on the wrong button, but probably that should be addressed increasing the clickable area, as mobile operating systems do (see screenshot below). I guess it should be addressed separately though, as part of a buttons redesign.

[afercia]

Some exploration for the Comments form was made in #43412.

[michaelarestad]

This ticket seems to have focused in on the proximity of buttons within wp-admin. My recommendation is to make the changes recommended above. This requires development at this point. I'm going to mark this as a good first bug for someone to move the buttons closer together.

[landwire]

So how would I go about taking this as my "good first bug"?
I have wordpress running locally (forked the wordpress-develop git repo) and already worked on the quick edit/bulk edit screens.

I am totally new to Core Contributing, so I would like that someone checks the CSS so far, as I am not sure how you handle linting, syntax, colours etc.

How do I attach an image here, so that you can see the current work?

How does the branching work and what name should the branch be? What should the commit message look like?
Any help is appreciated.

Styled the quick edit and bulk edit screen only for now. Feedback welcome.

Trac ticket: https://core.trac.wordpress.org/ticket/40822

[kebbet]

#PR601 can be closed, fixed in [53023]

Can be closed, fixed in https://core.trac.wordpress.org/changeset/53023

https://core.trac.wordpress.org/ticket/40822

## Before - Edit menu

## After - Edit menu

## Before - New menu

## After - New menu

[kebbet]

3542 (​https://github.com/WordPress/wordpress-develop/pull/3542) groups menu actions to the left (as in edit category or quick edit). See attached screenshots

Visual resualt after build rtl-version of css.

[sabernhardt]

#57066 was marked as a duplicate.

[sabernhardt]

#56594 was marked as a duplicate.

[oglekler]

Hi @kebbet,
could you please clarify the scope of the ticket and provide information for testing 🙏

[kebbet]

Hi @oglekler,

Thanks for the ping. Reading back on the ticket, I think my PR should be a separate ticket, as this ticket is for the general scope. The description of it states New tickets should be created for individual issues as they are found and reported.

That way it is easier to mark tasks done.

I reopened Trac 56594 to address this on that ticket.

[joedolson]

Moving this to 6.4. The first step on this should be to isolate each individual change as a separate ticket. Each scenario will need a separate and independent solution, so these shouldn't be committed as a group.

[oglekler]

@kebbet can you please take care about separating different parts into tickets?

[marybaum]

August 29 bug-scrub attendees agree with Joe and Olga that this needs splitting up.

[mdxfr]

a good example of non proximity in Gutenberg (that have to be fixed to avoid) ​https://github.com/WordPress/gutenberg/issues/47446

[joedolson]

There are two items in this ticket remaining to be completed: the theme details panel in both the installer and the customizer. All other core items have been resolved.

Gutenberg issues should be raised separately in the Github repository.

[joedolson]

Related: #59371, #59372. Tickets open to complete remaining issues on this ticket.

[marybaum]

@joedolson would like to get some testing on this, #50846, and #58912. I will ask @webcommsat to raise the three tickets in devchat tomorrow.

[joedolson]

In 56639:

Administration: Improve control proximity in theme details modal.

Make the theme details modals in the Customizer and at Appearance > Themes consistent. Change the order of controls so both modals are in the same sequence, center all controls in both desktop and mobile views, and change delete link color to meet color contrast requirements.

Props trishasalas, afercia, melchoyce, karmatosed, cathibosco1, michaelarestad, joedolson, petitphp, mikinc860.
Fixes #59372. See #59371, #40822.

[joedolson]

With [56639], all of the core issues raised in this ticket have been resolved. Any outstanding Gutenberg issues should be raised in Github, and any additional core issues should open new tickets.

Commited in https://core.trac.wordpress.org/changeset/56449