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

Comment (by GaryJ):

 Replying to [comment:23 obenland]:

 > The search form uses `.screen-reader-text` since r11312. No theme should
 need to register support for this class, as they should already support
 it!

 Twenty Eleven doesn't support it.

 It's not on the
 [http://codex.wordpress.org/CSS#WordPress_Generated_Classes Codex list] of
 required classes.

 It's not part of the
 [https://make.wordpress.org/themes/handbook/guidelines/theme-check
 /#wordpress-generated-css-classes Theme Handbook list] of required
 classes.

 It's not in the [https://github.com/Pross/theme-
 check/blob/master/trunk/checks/style_needed.php#L10 Theme Check plugin].

 It's also not been needed for any theme that has been (quite legitimately)
 filtering the search form output in a way that means the class was never
 used.

 All that means there are plenty of premium and free themes out in the wild
 that don't use it, so instead of worrying about "should", can we look at
 what problem actually exists in the real world?

 You're also forgetting that plugins could want to rely on knowing that a
 class exists, so it too could amend output to include visually hidden
 content between one version and the next.

 > > The only sensible way for a theme to opt in, is to add theme support.
 > This is not how built-in classes work. Themes can't pick and choose
 classes that they support. Nor should they be able to.

 As above - `.screen-reader-text` has never been listed as a required
 built-in class, so they *could* pick not to support it, and many don't.

 > > The Genesis Framework search form, by default doesn't have a <label>.
 > I'm sorry to hear that, but that doesn't mean that core should provide a
 solution for Genesis' shortcoming. We can't be accountable for the custom
 overrides that we allow developers to do.

 It's not just Genesis. It's front-end output from core, multiple themes
 and plugins that could all be empowered to improve accessibility in one
 go. It's a practical solution for everyone, without risking any changes to
 front-end displays just because core, parent theme or a plugin got
 updated.

 Joe has already [https://core.trac.wordpress.org/ticket/29808#comment:41
 said] that aria-labels aren't as good as headings, and rewriting widgets
 from scratch to be more accessible is a longer term solution. that has
 already been waiting years to fix. Adding a `label` with the right class
 could be done in a far quicker timeframe, for the same end result - a
 component that becomes more accessible or otherwise meets defined criteria
 that claims to make it so, without altering the visual display.

 > Also, using theme support to denote support for a specific class feels
 like using a sledgehammer to crack a nut.

 It's an unusual use, granted, but this is, and always has been, about
 maintaining backwards-compatibility. The problem isn't standalone themes.
 When one entity (core, parent theme, plugin) does the outputting of
 potential markup, and another (standalone theme, child theme) controls the
 front-end styles, then there needs to be a way for the latter to indicate
 that visually hidden markup can be output, and what class the former
 should use for it.

 > If there are themes that don't have `.screen-reader-text` defined, it's
 an opportunity to educate their authors about it.

 With that, I agree, and having this support will only bring attention to
 the need for the class. It will remove one of the barriers that theme and
 plugin authors would face about how to support it for core, parent theme
 and plugin output, without affecting those dependents who don't have the
 required styles.

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