Opened 10 years ago
Closed 9 years ago
#32150 closed defect (bug) (fixed)
List table: better indication for "no taxonomy"
Reported by: | afercia | Owned by: | obenland |
---|---|---|---|
Milestone: | 4.3 | Priority: | normal |
Severity: | normal | Version: | 4.2 |
Component: | Taxonomy | Keywords: | has-patch |
Focuses: | ui, accessibility, administration | Cc: |
Description
Posts (and Custom Post Types and Media, when they have a taxonomy) list the specified terms in the related table column, see screenshot:
One of the things reported by testers in the accessibility testing session dedicated to the posts screen is that there's no clear indication when there are no terms specified.
Currently, the table cell displays a —
character (em dash) which gives just a visual feedback but most screen readers don't read out punctuation at all (that would be meaningless even if read out).
We'd like to propose to use some explicit text to give a better feedback. To keep things simple I'd suggest to use a short, generic text suitable for either Posts, CPTs and Media. Wondering if something like "No terms" would be appropriate.
Any thoughts and suggestions more than welcome.
As far as I see, there are two occurrences of that em dash that would need to be changed, the first one in class-wp-posts-list-table.php
and the second one in class-wp-media-list-table.php
Attachments (5)
Change History (33)
#1
follow-up:
↓ 2
@
10 years ago
- Component changed from Administration to Taxonomy
- Focuses administration added
I think —
reduces visual clutter, see comment:26:ticket:21240.
Could we add a screen reader text?
#2
in reply to:
↑ 1
@
10 years ago
Replying to SergeyBiryukov:
I think
—
reduces visual clutter, see comment:26:ticket:21240.
Could we add a screen reader text?
Yes, would like to hear the accessibility team members opinion too, though.
#3
@
10 years ago
I don't have a problem with using screen reader text on this. I'd consider this to be an example of image based information; the typographic character of the emdash is a representative image in this context, and the screen reader text would essentially be alternative text for the graphic meaning it conveys.
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
10 years ago
#6
@
10 years ago
@karpstrucking thanks very much for your patch. Wrapping the labels in a span with a screen-reader-text
class would be perfect. I'm not so sure about the label text to use, the "found" part doesn't sound so correct to me and we should also avoid to introduce new labels. What do you think?
#8
@
9 years ago
- Keywords has-patch added
Refreshed patch uses screen reader text and hides the "emdash" from screen readers with an aria-hidden=true
attribute. Will work for Posts, Media attachments (when they have a taxonomy) and Custom Post Types using the not_found
label if provided, if not will fallback to "Categories" and "Tags", see Jetpack Project CPT in the screenshot below.
If this goes in (hopefully) maybe the Codex should be updated, see:
https://codex.wordpress.org/Function_Reference/register_taxonomy#Arguments
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 joedolson. View the logs.
9 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
9 years ago
#13
@
9 years ago
- Owner changed from SergeyBiryukov to obenland
- Status changed from assigned to accepted
#15
@
9 years ago
@afercia Is the not_found
label really the right string here? Even if it's just for screen readers, we should use strings which are semantically correct. In this case there are no terms assigned, there is no way to find them.
#16
@
9 years ago
@ocean90 I agree, semantically should be just "no terms". Didn't want to change what was originally proposed by @karpstrucking.
#17
@
9 years ago
If there is no term assigned, a term for that object can not be found, and you could make the argument the search context is WP looking in the database.
#18
@
9 years ago
Don't have a strong opinion about this, which one would work better for you: "No terms found" or just "No terms"? Or "Untagged"? thinking at how custom taxonomies would use that.
#20
@
9 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
New patch introduces a "no_term" label just for non-hierarchical taxonomies.
#21
@
9 years ago
- Keywords commit removed
Why is this just for non-hierarchical taxonomies? A post could have no assigned terms in a hierarchical custom taxonomy.
#23
@
9 years ago
- Keywords needs-patch added; has-patch removed
"Uncategorized" is just the name of the default term in the category taxonomy. Custom hierarchical taxonomies don't have default terms.
#25
@
9 years ago
When navigating horizontally through table cells NVDA will now read out:
Project Types column 4 No terms Project Tags column 5 No terms
This ticket was mentioned in Slack in #core by afercia. View the logs.
9 years ago
#27
@
9 years ago
32150.patch makes a final tweak to this, by using "No tags"/"No categories" phrases instead of the generic "No terms", and updates the inline docs.
Replace em dash with taxonomy's "not_found" label