[wp-trac] [WordPress Trac] #40428: Introduce best practices to hide CSS generated content from assistive technologies

[WordPress Trac]

#40428: Introduce best practices to hide CSS generated content from assistive
technologies
-------------------------------+-----------------------------
 Reporter:  afercia            |      Owner:
     Type:  defect (bug)       |     Status:  new
 Priority:  normal             |  Milestone:  Awaiting Review
Component:  Administration     |    Version:
 Severity:  normal             |   Keywords:  a11y-task
  Focuses:  ui, accessibility  |
-------------------------------+-----------------------------
 This ticket is part of [https://core.trac.wordpress.org/query?keywords
 =~a11y-task 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 [https://www.w3.org/TR/css-
 content-3/#accessibility 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.

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

 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!

--
Ticket URL: <https://core.trac.wordpress.org/ticket/40428>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform