Make WordPress Core

Opened 7 years ago

Closed 8 months ago

Last modified 4 months ago

#40822 closed defect (bug) (fixed)

Addressing Proximity in the admin area

Reported by: trishasalas's profile trishasalas Owned by: joedolson's profile joedolson
Milestone: 6.4 Priority: normal
Severity: normal Version:
Component: Administration Keywords: a11y-task has-screenshots a11y-proximity changes-requested
Focuses: ui, accessibility Cc:

Description

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.

Attachments (2)

Screen Shot on 2019-01-07 at 13-17-55.jpg (628.6 KB) - added by cathibosco1 5 years ago.
40822 buttons android.jpg (26.7 KB) - added by afercia 5 years ago.
Primary action and destructive action in Android (Emotion UI)

Download all attachments as: .zip

Change History (57)

This ticket was mentioned in Slack in #accessibility by trishasalas. View the logs.


7 years ago

#2 @afercia
7 years ago

  • Keywords a11y-task added

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


7 years ago

#4 @afercia
7 years ago

  • Keywords needs-screenshots added
  • Milestone changed from Awaiting Review to Future Release

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

#5 @afercia
6 years ago

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

#6 @afercia
6 years ago

  • Focuses ui added
  • Keywords has-screenshots added; needs-screenshots removed
  • Type changed from enhancement to defect (bug)

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):

https://cldup.com/8vzuJzR7Ob.jpg

Reply to comment (same for edit comment):

https://cldup.com/d98RdU-KeT.jpg

Save/Delete menu:

https://cldup.com/rxF0ahYXq8.jpg

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

https://cldup.com/bzuc02OcHD.jpg

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:

https://cldup.com/VYiaYkmtKO.jpg

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

https://cldup.com/dmyFnAJI2M.jpg

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]:

https://cldup.com/gPhxX2xTP3.jpg

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.

#7 @melchoyce
6 years ago

  • Keywords ui-feedback added

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


6 years ago

#9 @melchoyce
6 years ago

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.

#10 @karmatosed
6 years ago

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.

Last edited 6 years ago by karmatosed (previous) (diff)

This ticket was mentioned in Slack in #design by kumikocmorita. View the logs.


6 years ago

This ticket was mentioned in Slack in #design by melchoyce. View the logs.


5 years ago

#13 @cathibosco1
5 years ago

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?

Last edited 5 years ago by cathibosco1 (previous) (diff)

#14 follow-up: @afercia
5 years ago

@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
5 years ago

Primary action and destructive action in Android (Emotion UI)

#15 @afercia
5 years ago

  • Keywords a11y-proximity added

#16 @afercia
5 years ago

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.
Last edited 5 years ago by afercia (previous) (diff)

#17 in reply to: ↑ 14 @cathibosco1
5 years ago

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.

#18 @afercia
5 years ago

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

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


5 years ago

This ticket was mentioned in Slack in #design by estelaris. View the logs.


4 years ago

#21 @michaelarestad
4 years ago

  • Keywords good-first-bug added; ui-feedback removed

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.

#22 @landwire
4 years ago

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.

This ticket was mentioned in PR #601 on WordPress/wordpress-develop by landwire.


4 years ago
#23

  • Keywords has-patch added

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

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

This ticket was mentioned in Slack in #core by monsenhor. View the logs.


19 months ago

#25 @joedolson
19 months ago

  • Owner set to joedolson
  • Status changed from new to accepted

#26 @kebbet
19 months ago

#PR601 can be closed, fixed in [53023]

This ticket was mentioned in PR #3542 on WordPress/wordpress-develop by @kebbet.


19 months ago
#28

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

## Before - Edit menu
https://i0.wp.com/user-images.githubusercontent.com/11491369/199220614-111a647d-5ea8-4b00-aea7-3796b4282928.png

https://i0.wp.com/user-images.githubusercontent.com/11491369/199220682-d21848b5-8e5a-4262-b50a-57a6f5db559d.png

## After - Edit menu
https://i0.wp.com/user-images.githubusercontent.com/11491369/199220770-911051bf-e748-4cc7-a790-32e1b71a91a1.png

https://i0.wp.com/user-images.githubusercontent.com/11491369/199220741-6b184f56-eea6-4335-b6e0-2a4a15db4d61.png

## Before - New menu
https://i0.wp.com/user-images.githubusercontent.com/11491369/199220926-7a9d01bf-4e4e-4bb3-a9ac-62cf4f2f3444.png

## After - New menu
https://i0.wp.com/user-images.githubusercontent.com/11491369/199220881-911073fd-a4c5-499f-85dd-bf9a5db2aa76.png

#29 @kebbet
19 months ago

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

@kebbet commented on PR #3542:


19 months ago
#30

Visual resualt after build rtl-version of css.

https://i0.wp.com/user-images.githubusercontent.com/11491369/199236277-eb6eaaf5-0dbc-4364-b346-d5219807b96d.png

#31 @sabernhardt
18 months ago

#57066 was marked as a duplicate.

#32 @sabernhardt
18 months ago

#56594 was marked as a duplicate.

#33 @sabernhardt
14 months ago

  • Milestone changed from Future Release to 6.3

This ticket was mentioned in Slack in #core by chaion07. View the logs.


12 months ago

#35 @oglekler
12 months ago

  • Keywords needs-testing-info added

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

#36 @kebbet
12 months ago

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.

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


11 months ago

@sabernhardt commented on PR #3542:


11 months ago
#38

I reopened Trac 56594 to address this on that ticket.

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


11 months ago

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


11 months ago

#41 @joedolson
11 months ago

  • Milestone changed from 6.3 to 6.4

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.

#42 @oglekler
9 months ago

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

This ticket was mentioned in Slack in #accessibility by amberhinds. View the logs.


9 months ago

This ticket was mentioned in Slack in #core by marybaum. View the logs.


9 months ago

#45 @marybaum
9 months ago

  • Keywords changes-requested added; good-first-bug has-patch needs-testing-info removed

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

#46 @mdxfr
9 months ago

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

Last edited 9 months ago by mdxfr (previous) (diff)

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


8 months ago

#48 @joedolson
8 months ago

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.

#49 @joedolson
8 months ago

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

This ticket was mentioned in Slack in #core by marybaum. View the logs.


8 months ago

#51 @marybaum
8 months ago

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

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


8 months ago

#53 @joedolson
8 months ago

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.

#54 @joedolson
8 months ago

  • Resolution set to fixed
  • Status changed from accepted to closed

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.

Note: See TracTickets for help on using tickets.