Pages, Posts, Comments Screens - Prompts for Screen Readers

Description

Some quick wins here...

In the main display screens for Pages, Posts, Comments (and Custom Posts too) there are some input fields that could really be helped by the addition of a label to explain their purpose. This enhancement would improve the experience and ease of use for these screens for screen reader users. These labels could be made for screen readers only using CSS - ie hidden from sighted users - so as not to spoil the design.

Search pages text box in the top right of the screen.

The selection checkboxes - Suggest the ones in the table header and footer should have label "Select All". Suggest the check box for individual pages, posts, etc should have a label of "Select Title of page/post".

Ideally the Bulk Actions and Show All Dates dropdowns should have a label but that is less important in my view as context is supplied by default option (kind of).

Happy to discuss, and to help with screen reader-only text but I believe there is a screen-reader-text CSS class available now maybe?

The theme search does not have a label. I have attached a patch to address this.
Note the patch adds labels for the search type dropdown when it appears and the search input box. The label for the search input box is dynamic based on the setting of the drop down when the page is drawn.

A second pass might be to make this label dynamic client side (using jQuery) so that it updates when the drop down is changed. I don't know how accessible that would be.

Column headers are printed twice, which means we'd end up with duplicate IDs here.

What if we hooked directly into the print_column_headers() list table method and always overrode the checkbox column? 21325.diff​

Existing 'cb' => '<input type="checkbox" />' can also become 'cb' => true or 'cb' => false with this change. Unless someone is manually looping through get_column_headers() and doing their own printing, there'd be no side effect.

The one issue is that "Select all" might need to be disambiguated for localization reasons. "Select all" for posts might translate differently than "Select all" for themes, for example. The other option would be to consider the context to be selecting all "rows" or "checkboxes," in which case, we're fine. It looks like we already use "Select All" elsewhere, without context, on update-core.php and elsewhere.

Column headers are printed twice, which means we'd end up with duplicate IDs here.

Doh! Forgot that. I shouldn't code in the early hours!

What if we hooked directly into the print_column_headers() list table method and always overrode the checkbox column? 21325.diff​

Existing 'cb' => '<input type="checkbox" />' can also become 'cb' => true or 'cb' => false with this change. Unless someone is manually looping through get_column_headers() and doing their own printing, there'd be no side effect.

That makes sense.

The one issue is that "Select all" might need to be disambiguated for localization reasons. "Select all" for posts might translate differently than "Select all" for themes, for example. The other option would be to consider the context to be selecting all "rows" or "checkboxes," in which case, we're fine. It looks like we already use "Select All" elsewhere, without context, on update-core.php and elsewhere.

I think the latter case makes sense, especially as you say, it is used elsewhere without context.

Thanks for that Sergey. There was an oddness around line endings in your patch (I got "Stripping trailing CRs from patch." for each chunk) and one syntax error (PHP Parse error: syntax error, unexpected '.' in /mnt/hgfs/mike/sandbox/localhost/wptrunk/wp-admin/includes/class-wp-terms-list-table.php on line 240).