[wp-trac] [WordPress Trac] #35483: Accessibility improvements for the Bulk Edit form

WordPress Trac noreply at wordpress.org
Tue Jan 19 19:25:07 UTC 2016


#35483: Accessibility improvements for the Bulk Edit form
-------------------------------------+-------------------------------------
 Reporter:  afercia                  |       Owner:  afercia
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  4.5
Component:  Quick/Bulk Edit          |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch has-           |     Focuses:  ui, accessibility,
  screenshots                        |  javascript
-------------------------------------+-------------------------------------

Comment (by afercia):

 I just wanted to make this form usable with a keyboard ;) but yep, seems
 there are many usability issues to solve. Will try to be as short as
 possible and maybe it would be nice to discuss this a bit longer on Slack.

 '''Initial focus'''
 Should be set on the first form element. If in a linearised workflow like
 when using only the keyboard the remove buttons feel wrong as first thing,
 then I'd say they shouldn't be the first thing in the form in the first
 place. It's a bit tricky since many form elements get printed out
 conditionally, depending on the features supported by the post, user
 capabilities, how many registered taxonomies... For example, when a post
 type doesn't support `title` what is printed out is, err.. this:

 [[Image(https://cldup.com/Idkr3hkpde.png)]]

 Maybe move the titles at the end of the form as a last check to do before
 saving would make more sense? We're moving towards a complete refactoring
 though :)

 '''"Remove buttons" size'''
 Sure, they can use just the "x", thinking on small screens they should be
 at least 40x40 pixels though.

 '''Move focus to the previous or next remove buttons'''
 Thought it's already the previous one by default? If there's no previous
 one, will use the next one.
 Automatically closing the form when no more items left would be a bit
 confusing for screen reader users I guess, not sure about this but worth
 experimenting a bit, maybe using also an audible message

 '''The "structural" css needs a bit more work'''
 I agree. Maybe open a separate ticket? Would need a re-think since many
 elements are printed out conditionally (see above)

--
Ticket URL: <https://core.trac.wordpress.org/ticket/35483#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list