Introduce best practices to hide CSS generated content from assistive technologies

[afercia]

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!

[jhabdas]

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: "=============================================";
}
</style>

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)

Suggestion

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.

---

I bring this up because I'm trying to refactor the twentyseventeen_scripts method in functions.php in Twenty Seventeen and am tripping all over twentyseventeen_get_svg, which seems to be an implicit time-based dependency on a theme file via use of the hooks system, and am being forced to give up affordances to accessibility as a result of the current design complexity.

[joedolson]

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.

[afercia]

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.

[Cheffheid]

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)

[afercia]

interesting data about support: major browsers and screen readers do announce CSS generated content:
​https://a11ysupport.io/tech/css/generated_content

[afercia]

From dboudreau and aardrian at California State University, Northridge (CSUN) Assistive Technology Conference 2019:

​https://twitter.com/aardrian/status/1108926620977369090

More confirmation that ::before / ::after is read by AT:

​https://twitter.com/dboudreau/status/1108840452415983620

Research from @dive4cb and John Northup during #csunatc19 showed that CSS content embedded through pseudo selectors such as :before and :after is now properly conveyed to assistive technologies