[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:  reopened
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Themes       |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  accessibility
-------------------------+------------------------------

Comment (by obenland):

 Okay, here is my best-of of arguments against any action beyond theme
 author education:

 Core did not break backwards compatibility. `.screen-reader-text` has been
 used on the front-end in the search form since r11312. As in: For the last
 six years. The only time a theme would not be confronted with it would be
 if it has a custom search from where it wasn't copied over. Default themes
 have had support for it since Twenty Ten (with the exception of Twenty
 Eleven until r31268), and with it all those themes that were derived from
 them. Including all 300,000+ `_s`-based themes, and plenty more.

 As for the themes that do not have support for it, I think we had a good
 amount of success with the education route that we've started.
 @joedolson's and my posts were well received
 ([https://make.wordpress.org/accessibility/2015/02/09/hiding-text-for-
 screen-readers-with-wordpress-core/ #],
 [https://make.wordpress.org/themes/2015/01/26/supporting-screen-reader-
 text/ #]), and there were additional educational pieces that originated in
 the a11y team. `.screen-reader-text` was added to the list of required
 classes by the WPTRT, and we're working on getting it added to Theme Check
 as well.

 I do not think we should add default styles to make our lives easier.
 Emojis has set a bad precedent with core adding a script on the logged-out
 front-end for the first time, without a theme or plugin enqueueing it. It
 makes for a very bad developer experience when they have to start removing
 actions and filters to take full control of the front-end of their site.
 WordPress has never done that until now, and I think we should be very
 careful about changing that.

 Adding new screen-reader-text improvements doesn't mean that it has to
 deteriorate user experience. r31388 for example does not impede UX, even
 if a theme doesn't have styles for the class. At worst, the reader has
 more context for that headline.

 Yes, there is a problem with themes that don't have styles for the class,
 but adding default styles is not the solution. I think we should continue
 that path we started, educate, be conservative for now about where we add
 more `.screen-reader-text` classes in core, and crank it up later when a
 lack of theme support is even less of a concern.

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