[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 GaryJ):

 Replying to [comment:42 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.

 Or, the theme author never wanted to visually hide the label in the first
 place.

 > 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.

 Twenty Eleven, Thesis, Genesis Framework, Canvas, Sandbox, Avada, and a
 ton of others in the community still don't appear to support it even now,
 so throwing numbers around for derivates of one particular theme doesn't
 mean the rest of the community has followed your ideology.

 > 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/ #]),

 Your posts received ~10 comments between them - is that how you're judging
 them to be well received? Plus, articles explaining what the educational
 push forward is, doesn't address all the existing sites out there that use
 themes without the necessary class.

 > 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.

 It's no worse than gallery styles have done (still doing?), which is why
 the majority of comments here are now saying to add it, but make it
 filterable.

 > 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.

 No, at worse, it breaks the layout in some unpredictable way, which means
 content may not be visually readable depending on the CSS. But, what it
 may or may not do is missing the bigger point - the use of it, without
 consideration for backwards compatibility for existing sites.

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