#35664 closed defect (bug) (fixed)
Edit term screens: tab order should match visual order
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 4.6 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Taxonomy | Keywords: | has-screenshots has-patch commit |
Focuses: | ui, accessibility | Cc: |
Description
While Posts have separate screens for listing the posts and adding new ones, Taxonomies have just one screen with two columns. In these screens, the initial focus is set on the first focusable field on the "add" form and that makes perfectly sense.
By the way, since the right column is the first one in the source and the left column is the last one, this is problematic for accessibility.
For keyboard and screen reader users, navigation is a linearised process. If WordPress forces users to start their navigation in the middle of the content, all the previous content (the list table) will be basically "skipped".
Starting from the focused input field, users will press the Tab key or use arrow keys to navigate forward, and after the submit button there's just the footer.
To go to the list table, they will be forced to navigate backwards, which is always a confusing experience. Making the tab order match the visual order is also a WCAG success criterion.
The fix would be fairly simple, and it would be also a nice opportunity to clean up a bit the related CSS (noticed some redundant media queries and other possible adjustments).
Was also wondering why the Tag Cloud in the Tags screen is the first thing on the top, for consistency I'd propose to move it below the form. Any thoughts more than welcome.
Attachments (2)
Change History (19)
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
9 years ago
#4
@
9 years ago
Some testing with plugins that "do things" on these screens would be nice, @joedolson will have a look at this. Also, any help in testing would be greatly appreciated :)
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
9 years ago
This ticket was mentioned in Slack in #core by chriscct7. View the logs.
9 years ago
#7
@
9 years ago
- Milestone changed from 4.5 to Future Release
This should be tested to check if it breaks something with plugins doing their things on this screen. Tomorrow is beta 4 day so, I don't feel happy to merge it so late in the release cycle. Should be merged early at the beginning of a new release cycle, so punting for now.
This ticket was mentioned in Slack in #core by afercia. View the logs.
9 years ago
#9
@
9 years ago
When this goes in, a make core post should accompany it that includes the before and after screenshots. This will help encourage testing.
#11
@
9 years ago
Asked on the Italian WP Slack for plugins that "do things" on this screen, here some plugins to test with (haven't checked personally): WPML, Polylang, one extension for CMB2 which adds some custom fields https://github.com/jcchavezs/cmb2-taxonomy.
@joedolson any other plugins off the top of your head? :)
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
9 years ago
#13
follow-up:
↓ 14
@
9 years ago
Works fine with the plug-ins I tested, which were all plug-ins adding custom fields into the tag form. Polylang broke the tag quick-edit form in WordPress 4.6, but it's not obvious to me that this is directly caused by this change. It looks like a problem in the list table class passing 0 as the colspan value for the quick edit form.
#14
in reply to:
↑ 13
@
9 years ago
- Keywords commit added; ui-feedback removed
Replying to joedolson:
It looks like a problem in the list table class passing 0 as the colspan value for the quick edit form.
Yeah, Polylang adds a table in these screens and with the patch applied it becomes the first table in the source. The .widefat:first thead
jQuery selector used to get the count of the visible columns to be used as the value to set on the Quick Edit table cell colspan
attribute assumed the WP list table to be the first table in the source. Which now it may be not true, giving the different order of the hooks in the source.
The refreshed patch uses a more specific jQuery selector to fix the issue.
About the action hooks, the order is now different of course but basically just one changed:
do_action( "after-{$taxonomy}-table", $taxonomy );
is the only action hook in the "right column" and it was the first one to fire. With the patch applied, it's the last one.
The proposed patch is a first pass to make the visual order and the source order match. Also, I'd propose to move the "Popular Tags" tag cloud below the form, to improve consistency of the categories and tags screens.
There's room for other accessibility improvements, for example consider to use a fieldset element and
aria-describedby
attributes for the form, but they should go in a separate ticket.Screenshots with the patch applied: