Make WordPress Core

Opened 14 months ago

Last modified 7 weeks ago

#40428 assigned defect (bug)

Introduce best practices to hide CSS generated content from assistive technologies

Reported by: afercia Owned by: trishasalas
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Administration Keywords: a11y-task
Focuses: ui, accessibility Cc:


This ticket is part of the a11y-task series, which aims to start discussion and research on broad accessibility issues that probably can't be solved so soon. In the accessibility team, we've discussed a few times these topics and decided as first step to try to make everyone aware of them. This could help in trying to improve future implementations and avoid to introduce new issues.

As the CSS 3 spec states, in the near future CSS generated content will be treated as actual content (Safari and VoiceOver already does that).

Specifically for assistive technologies:

Generated content should be searchable, selectable, and available to assistive technologies. The content property applies to speech and generated content must be rendered for speech output.

Some interesting data about browsers and screen readers support (i.e. which ones announce CSS generated content) here: http://tink.uk/accessibility-support-for-css-generated-content/. Please consider these data are from March 2015, so they're probably a bit outdated.

What this means in practice

In the best case, screen readers will try to read the generated content as a character, and if there's no character that matches, they may announce You are currently on a text element. See #37513 for a specific use case.


In the worst case, when the generated content maps to an actual recognisable character, screen readers will just announce the character. A couple simple examples:

content: "\00d7"; gets read out as "times" content: "\25BA"; gets read out as "black right pointing pointer"

Maybe in the future it will be possible to use a CSS-only solution, see:

Alternative Text for Speech https://www.w3.org/TR/css-content-3/#alt which will (hopefully) introduce the ability to specify alternative text for the CSS generated content property, after a slash:

content: "\25BA" / "";

There's no browser support so far.

A possible solution

When CSS generated content is not intended to be available for speech output, then it should always be wrapped by an element (for example a <span>) with an aria-hidden="true" attribute. At the moment, this is the only reliable way to hide CSS generated to assistive technologies.

Of course, trying to apply this solution to all the CSS generated content currently used in core would be a huge task. There may be better solutions, worth researching a bit. Worth also considering there's an ongoing effort to replace the CSS font icons currently used in core with SVG icons. That could help mitigating the issue, but it will still stand for any other non-icons generated content.

Any thoughts and feedback welcome!

Change History (11)

#1 @afercia
14 months ago

  • Owner set to trishasalas
  • Status changed from new to assigned

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

14 months ago

#3 @jhabdas
13 months ago

FWIW, the `media` attribute accepts media queries, allowing one to use a media query to specify a media type, such as not aural. It is intended to enable one to apply CSS to specific "types" of user agents, be them monochrome, TTY, braille, et cetera.

I tested media queries out yesterday using VoiceOver on macOS Sierra on both Chrome and Firefox using a very limited test case of:

<style media="only screen">
h1:after {
  content: "=============================================";

Test results

  • Chrome read aloud the H1 body, and then the words "equals equals equals"
  • Firefox read aloud the H1, and that was all (though it does that with and without the media query)


When creating features, please consider special needs users may be more likely to choose the browser which works best for their needs, and that browser may already have affordances built in to provide a better experience for them when assistive technologies like VO are enabled despite what standards bodies like W3C or WHATWG suggest.

Last edited 13 months ago by jhabdas (previous) (diff)

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

13 months ago

#5 @joedolson
13 months ago

Unfortunately, this is a concern for screen reader users, who can't be targeted using any specific media queries. Given that official guidance for CSS generated content is that it is to be treated as content, screen readers will read it in the future, whether they do now or not. We need to plan on the assumption that any generated content will be available to a screen reader, even if that content is fundamentally meaningless as aural feedback.

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

13 months ago

#7 @afercia
13 months ago

  • Milestone changed from Awaiting Review to Future Release

#8 @afercia
13 months ago

In 40643:

Accessibility: Add "(opens in a new window)" screen reader text to the "News-Nearby Events" dashboard widget footer links.

  • standardizes similar messages in core to always use (opens in a new window)
  • adds translators comments
  • hides the dashicons with aria-hidden="true", see #40428

Fixes #40733.

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

4 months ago

#10 @Cheffheid
4 months ago

As per today's bug scrub:

An idea to help tackle this is by creating a PHP function (the_dashicon() or something) to standardize the markup used for these icons and make use of aria-hidden as described in the ticket.

(And maybe allow aria-hidden to be toggled/exchanged for aria-label for any icons that do need to be announced a certain way? Not that I'd want to advocate textless icons, of course)

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

7 weeks ago

Note: See TracTickets for help on using tickets.