Make WordPress Core

Opened 8 years ago

Closed 6 years ago

#40677 closed defect (bug) (fixed)

Widgets page is not accessible for keyboard users

Reported by: juliemoynat's profile juliemoynat Owned by:
Milestone: 5.1 Priority: normal
Severity: normal Version:
Component: Widgets Keywords: has-patch has-screenshots
Focuses: accessibility, javascript Cc:

Description

Hi,

I noticed that widgets page is not accessible for users that navigate with keyboard.

A good point is that drag and drop is not the only solution to add a widget into an area but this page needs some enhancements to be accessible for keyboard users (blind people, people with motor disability, and even people with no handicap).

This is my list:

  • Available widgets can't be focused.

Solution : If we add a "tabindex="0"" attribute on ".widget.ui-draggable" elements, we can focus them and open it just like a click. And we need to add a focus style to see focus on elements.

  • A keyboard user can't select the area where he wants to add the widget because a TAB or arrow navigation automatically select the following choice. So he can just add widgets in the last area.

Solution : deactivate TAB navigation on elements and just allow arrow navigation. This would be equivalent to radio buttons navigation. TAB would be just to go to "Cancel" or "Add widget" button. Also add a screen reader text to tell which choice is selected (blind people can't see the checked icon).

  • This page is divided into 3 parts : "Available widgets", "Inactive widgets" and all widgets areas. The "all widgets areas" has not title to quickly navigate into it.

Solution : add a "h2" title on the third zone ("Widgets areas" for example) and replace "h2" title of widgets areas by "h3" (logical, right?)

  • Widgets in areas can't be deactivated with keyboard because we need to drag them back.

Solution : Add a link "Deactivate" next to the "Delete" one.

  • Widgets areas can't be opened with keyboard because arrows are "div"s and not buttons.

Solution : be inspired by the left column of the page to add menus (there is tabindex and screen reader text to explain)

  • Widgets in areas also have an arrow to hide / show. The arrow is a link and that's a good point but there no text in it.

Solution : add a screen reader text to explain what that link does (blind people can't see the arrow)

Thank you for your help

Attachments (2)

40677.diff (10.7 KB) - added by afercia 7 years ago.
40677-headings.diff (4.4 KB) - added by afercia 7 years ago.

Download all attachments as: .zip

Change History (25)

#1 @joedolson
8 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Thanks for your ticket, @juliemoynat! This issue was being tracked in #31476, and should be entirely fixed as of 2 days ago in 40569. If you can install the beta version of WordPress 4.8 and verify that all your issues are addressed, that would be great, but if there are further issues, please comment on #31476 to address them!

Thanks for sharing and helping out!

#2 @afercia
8 years ago

  • Version 4.7.4 deleted

See [40569] and [40480]. However, they fix just a part of the accessibility issues in the Widgets screen. Worth noting this screen has also an alternate mode, can be enabled from the Screen Options, see Enable accessibility mode, that's recommended especially for keyboard users and screen reader users.

#3 @juliemoynat
8 years ago

Hi,

Thank you for your replies.

@joedolson I've installed WordPress 4.8-alpha-40576. Can you confirm that #31476 correction is in that version?
If so, I confirm that my ticket is not a duplicate of #31476 because Widgets page doesn't work better with keyboard.

@afercia I didn't know this option exists and users can't imagine there is some accessibility options in it. I never remind of this "screen options" button...
An accessibility mode should be accessible into the screen, not hidden into an accordion. I will test this accessibility mode as well.

#4 @afercia
8 years ago

  • Milestone set to Awaiting Review
  • Resolution duplicate deleted
  • Status changed from closed to reopened

An accessibility mode should be accessible into the screen, not hidden into an accordion.

Yep, right. Ideally, the same content should be served to all users. Personally, I don't support alternative modes or "accessible versions" as a viable solution for better accessibility. The Widgets screen "accessibility mode" is there for historical reasons, and I guess it was implemented years ago with a good intent. However, modern applications should be accessible out of the box. As noted in #40678 this screen, together with the Menus one, the media views, and the customizer, are the most critical areas in WordPress for accessibility. The Widgets screen would need some big refactoring primarily because the drag and drop functionality is hard to use with a keyboard. I really hope there will be the chance to improve this screen in the next future and contributors interested in helping out.

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


8 years ago

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


7 years ago

#7 @afercia
7 years ago

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

Moving to future release as something that should be addressed, as per today's bug scrub. Some points outlined here are already fixed. Some of the other suggestions would be very simple and there are no reasons why they shouldn't be implemented :)

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


7 years ago

#9 @afercia
7 years ago

See also #42778 which aims to make the "Accessibility mode" link more discoverable.

#10 @afercia
7 years ago

  • Keywords good-first-bug added
  • Milestone changed from Future Release to 5.0

#11 @afercia
7 years ago

  • Owner set to afercia
  • Status changed from reopened to assigned

Note: working on a patch for this.

@afercia
7 years ago

#12 @afercia
7 years ago

  • Focuses javascript added
  • Keywords has-patch has-screenshots added; needs-patch good-first-bug removed

I've split the issues this ticket aims to solve in 2 separate patches.

Keyboard accessibility

40677.diff makes the left part of the Widgets screen (the "Available Widgets") operable with a keyboard, manages focus when appropriate, adds label and feedback for screen reader users, improves color contrast. I'm not saying this will make this screen fully accessible but it's an improvement. Looks good to me and it's contained in the admin-widgets JS which doesn't touch the Customizer. I think it's ready for review and commit. Screenshot:

https://cldup.com/v7KLwCCp7H.png

Headings

40677-headings.diff it's just a proof of concept, please do not merge. Adding a new heading on the right, for example "Available Sidebars", would be trivial:

https://cldup.com/9uqmLitQ-4.png

However, all the headings below should be bumped up by one level. It's possible to do that in a slightly hacky way, which doesn't make me so happy. However, things get even more hacky because when adding a widget, or dragging a widget from the left column to the right one and vice-versa, then the widget heading should be changed on the fly, for example from a h3 to a h4 or vice-versa, in order to preserve a correct headings hierarchy. 40677-headings.diff experiments this approach but I think it's extremely fragile, and I'm really not sure it should be done. Better ideas welcome.

Off the top of my head, an alternative solution could be keeping the current headings unchanged and just prepend to the sidebar names some visually hidden text, for example:

<span class="screen-reader-text">Available sidebar: </span>Blog Sidebar
<span class="screen-reader-text">Available sidebar: </span>Footer 1
<span class="screen-reader-text">Available sidebar: </span>Footer 2

Last point

A couple fixes have already been implemented in previous WordPress releases. There's one thing left to do from the original points described in the ticket:

Widgets in areas can't be deactivated with keyboard because we need to drag them back. (Add a link "Deactivate" next to the "Delete" one.)

I'd recommend to split this in a separate ticket as I think it should be discussed with the Customizer and Design teams.

#13 @afercia
7 years ago

I'm going to commit the first part related to the "Available Widgets" section because it's a good improvement. Screenshot of the visual changes (darker blue for the selected item, underline for the focused item):

https://cldup.com/eEgnTEyoGV.png

Still to do:

  • headings for the available Sidebars
  • Add a link "Deactivate" next to the "Delete" one

#14 @afercia
7 years ago

In 42794:

Accessibility: Widgets: Make the "Available Widgets" section operable with a keyboard.

For a number of years, the "Available Widgets" section has been off-limits for
keyboard users. Now it can be used also with the keyboard. This change introduces
also some improvements for assistive technologies.

  • makes the widget toggles focusable and adds an aria-expanded attribute to indicate their state
  • improves the toggles labelling to clarify context (add/edit)
  • changes the controls to choose a sidebar from list items to buttons
  • adds an aria-label attribute to the buttons to clarify their purpose
  • adds an aria-pressed attribute to the buttons to indicate which one is selected
  • improves color contrast of the selected button
  • uses a wp.a11y.speak() message to announce to screen reader users when a widget has been added to a sidebar
  • moves focus back to the toggle button when closing a widget

See #40677.

#15 @westonruter
7 years ago

FYI: Small regression in Customizer introduced by [42794] as reported in #43983.

#16 @westonruter
7 years ago

In 43244:

Customize: Hide expansion arrows in Customizer's available widgets list.

Fixes regression introduced by [42794].

Props dlh.
See #40677.
Fixes #43983.

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


6 years ago

#18 @audrasjb
6 years ago

  • Keywords fixed-major added

Reopening for 4.9.9 consideration as seen during accessibility team bug-scrub meeting.

#19 @SergeyBiryukov
6 years ago

  • Milestone changed from 5.0 to 4.9.9

#20 @pento
6 years ago

  • Milestone changed from 4.9.9 to 5.0.1

#21 @afercia
6 years ago

  • Owner afercia deleted

#22 @pento
6 years ago

  • Milestone changed from 5.0.1 to 5.0.2

#23 @pento
6 years ago

  • Keywords fixed-major removed
  • Milestone changed from 5.0.2 to 5.1
  • Resolution set to fixed
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.