[wp-trac] [WordPress Trac] #29699: Use current_theme_supports( 'screen-reader-text' );

[WordPress Trac]

#29699: Use current_theme_supports( 'screen-reader-text' );
---------------------------+-----------------------------
 Reporter:  GaryJ          |      Owner:
     Type:  enhancement    |     Status:  new
 Priority:  normal         |  Milestone:  Awaiting Review
Component:  General        |    Version:
 Severity:  normal         |   Keywords:
  Focuses:  accessibility  |
---------------------------+-----------------------------
 ticket:18650#comment:16 - accessible dropdown widgets
 ticket:26553#comment:2 - comments_popup_link()
 ticket:16433#comment:12 - commenter name in comment reply link

 The comments linked above are three examples that are all stuck on the
 fact that themes aren't guaranteed to provide a `.screen-reader-
 text`-esque class on the front-end.

 My proposal is that `add_theme_support( 'screen-reader-text' );` can be
 used by themes to indicate that they do have some implementation of (what
 we know as) `.screen-reader-text` which has the result of making content
 visually hidden but available for screen readers.

 Core can then use `current_theme_support( 'screen-reader-text' );` within
 various contexts where it outputs markup, to enhance the default output to
 make it more accessible.

 The default expected CSS selector would be exactly `.screen-reader-text`
 to match the class name that core uses. This could be enhanced by allowing
 something like `add_theme_support( 'screen-reader-text', array( 'class' =>
 'visuallyhidden' ) );` which would make implementations inside existing
 frameworks (e.g. Bootstrap, HTML5 Boilerplate) not have to duplicate
 rulesets.

 This proposal doesn't make any suggestion for the properties and values
 themes should use in their CSS implementation.
 [https://github.com/RRWD/leiden/issues/1#issue-38779796 This] post
 outlines a few different ways for instance.

 All the theme support is doing is telling WP that by adding a given class,
 WP can assume that it will be for screen readers only. Plugins, theme
 frameworks and parent themes could also use the same check to enhance
 their output too. By doing it in core, but making the approach available
 for all developers, it has the side-effect of bringing the whole issue
 about screen reader accessibility to a wider audience too.

 If accepted, the above tickets and similar could proceed, and themes could
 be updated in their own time to add this support. If they don't, then it's
 status quo for them, so fully backwards-compatible.

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