WordPress.org

Make WordPress Core

Opened 12 months ago

Last modified 4 months ago

#40822 new defect (bug)

Addressing Proximity in the admin area

Reported by: trishasalas Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Administration Keywords: a11y-task has-screenshots ui-feedback
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.

Change History (10)

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


12 months ago

#2 @afercia
12 months ago

  • Keywords a11y-task added

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


12 months ago

#4 @afercia
12 months 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
5 months 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
5 months 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
4 months ago

  • Keywords ui-feedback added

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


4 months ago

#9 @melchoyce
4 months 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
4 months 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 4 months ago by karmatosed (previous) (diff)
Note: See TracTickets for help on using tickets.