WordPress.org

Make WordPress Core

Opened 2 years 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 a11y-proximity
Focuses: ui, accessibility Cc:
PR Number:

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 10 months ago.
40822 buttons android.jpg (26.7 KB) - added by afercia 10 months ago.
Primary action and destructive action in Android (Emotion UI)

Download all attachments as: .zip

Change History (21)

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


2 years ago

#2 @afercia
2 years ago

  • Keywords a11y-task added

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


2 years ago

#4 @afercia
2 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
22 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
22 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
22 months ago

  • Keywords ui-feedback added

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


22 months ago

#9 @melchoyce
21 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
21 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 21 months ago by karmatosed (previous) (diff)

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


13 months ago

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


10 months ago

#13 @cathibosco1
10 months 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

@melchoyce recommended "I don’t think we should hold up the link/button semantic changes, so ideally the patch would be updated to exclude the change in button alignment"

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

Thoughts?

Version 0, edited 10 months ago by cathibosco1 (next)

#14 follow-up: @afercia
10 months 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
10 months ago

Primary action and destructive action in Android (Emotion UI)

#15 @afercia
10 months ago

  • Keywords a11y-proximity added

#16 @afercia
10 months 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 months ago by afercia (previous) (diff)

#17 in reply to: ↑ 14 @cathibosco1
10 months 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
9 months ago

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

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


4 months ago

Note: See TracTickets for help on using tickets.