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

[WordPress Trac]

#29699: add_theme_support( 'screen-reader-text' );
-------------------------+----------------------------
 Reporter:  GaryJ        |       Owner:
     Type:  enhancement  |      Status:  closed
 Priority:  normal       |   Milestone:
Component:  Themes       |     Version:
 Severity:  normal       |  Resolution:  wontfix
 Keywords:  has-patch    |     Focuses:  accessibility
-------------------------+----------------------------

Comment (by GaryJ):

 Another example of how things currently stand: the default value of the
 global `$more` is `(more…)`. If WP changed that, without including
 a back compat solution, to `(<span class="screen-reader-text">Read
 </span>more<span class="screen-reader-text"> about This Really Long Post
 Title</span>…)` then one doesn't know how many grid-like fixed-
 height displays would break upon WP update, when a theme hasn't overridden
 the default value.

 If the rejected `add_theme_support()` approach is considered opt-in, then
 I think the Joe's solution (which I didn't previously like) is the next
 best idea:

 Replying to [comment:17 joedolson]:
 > All right, another follow-up. I chatted with Otto about this, and he
 suggested and supported simply loading a .screen-reader-text class from
 core; like we do for the gallery and media players. I think that would be
 a much better solution - it's a standard piece of code, it will be the
 same for all themes, and then we [can] count on its presence.

 Have a `<style>.screen-reader-text{...}</style>` be added to the front-end
 by WP by default, and let theme / site authors toggle that inclusion with
 a boolean filter. That's then an opt-out approach. Sites don't get their
 designs disrupted. Screen readers users benefit while visual users don't
 get negatively affected. Theme / site owners can copy-paste that template
 of styles into their style.css. Plugin authors can assume it to be present
 if WP version > X allowing them to easily check before adding their own
 enhancements. It's not going to have a massive SEO or performance impact.

 Could that approach be up for consideration?

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