#29699 closed enhancement (wontfix)
add_theme_support( 'screen-reader-text' );
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Themes | Keywords: | has-patch |
Focuses: | accessibility | Cc: |
Description
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. 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.
Attachments (2)
Change History (55)
#2
@
10 years ago
seems like a solid approach to handle this with all the possible front-end variations.
#3
@
10 years ago
@scottsweb had a suggestion for this. In summary, instead of theme support called screen-reader-text
, we could use a superset of accessibility
. This was on the assumption that there might be other accessibility-specific features that themes need to communicate to other parties that it supports, without having separate theme support items. The args array passed in would then have keys named for specific things like screen-reader-text-class
.
At this point, I can't think of anything that is as specific as the screen-reader-text point, but I'm open to changing if there are. We already have html5
theme support which can change the markup for comments, for instance, that could include attributes for accessibility.
We must remember that while this idea is new, this specific theme support is not about accessibility per se, but really about backwards-compatibility; moving the linked tickets forward to improve accessibility, without breaking existing themes.
#4
@
10 years ago
- Keywords has-patch added
Patch attached which enables usage of both formats - a custom class, or a default class of screen-reader-text
:
add_theme_support( 'screen-reader-text', array( 'class' => 'visuallyhidden' ) ); add_theme_support( 'screen-reader-text' );
Unit tests included.
#5
@
10 years ago
- Summary changed from Use current_theme_supports( 'screen-reader-text' ); to add_theme_support( 'screen-reader-text' );
#6
@
10 years ago
I haven't yet been able to think of another type of theme support relevant to accessibility that would have this impact; I considered ARIA landmark roles, but that's rarely going to be relevant to any core functionality.
I think that this should go in, so that we can start work on the widget and other replacement features, as well as integrate this support into bundled themes.
#7
follow-up:
↓ 8
@
10 years ago
I love this idea!
I don't know if this is an edge case or major use case, but I often find that I need two "screen-reader-text" classes, one for hidden alternative text (i.e. icon labels) and another for links that should be visible when they have :focus
(i.e. "skip to content links, etc."). Should this support both? Are they actually different. Is the :focus
case not relevant here? (Or is it even the assumed use case?)
#8
in reply to:
↑ 7
@
10 years ago
Replying to mrwweb:
I don't know if this is an edge case or major use case, but I often find that I need two "screen-reader-text" classes, one for hidden alternative text (i.e. icon labels) and another for links that should be visible when they have
:focus
(i.e. "skip to content links, etc."). Should this support both? Are they actually different. Is the:focus
case not relevant here? (Or is it even the assumed use case?)
Thanks for bringing this point up. I had considered it, but hadn't documented any notes about it.
If you look at https://github.com/RRWD/leiden/issues/1#issue-38779796 (linked in the original post), you'll see that wp-admin and Twenty Fourteen both use screen-reader-text:focus
, Bootstrap uses a second class, and H5BP uses a modifier class along with the original. From a CSS point of view, either the first or third approaches are best for most flexibility and code-reuse, so there shouldn't need to be a second class. If you do have a second class, that's fine - but it should only be concerned with bringing back something previously visually hidden and styling it to look good - and that's not something this ticket is directly concerned with, since it's only looking at hiding potentially new extra bits for backwards compatibility.
Should there be a need however, for a second class dealing with focusable stuff (i.e. WP started outputting an opt-in automatic Skip Links section), then adding a second or third key to the theme support args array with a default would be trivial to do.
#9
@
10 years ago
I agree with Gary; in general, the purpose of this is to provide backwards compatibility for core-defined code. If there's a need for a :focus class, the theme is free to provide that, but I don't currently see a need for that in core code.
#10
@
10 years ago
Makes sense to me. So long as there's no obvious reason for core or plugins to provide skip-to links, then it seems unnecessary.
#11
@
10 years ago
In general, I'd consider that a theme issue, so no, I wouldn't expect it to be necessary.
#13
@
10 years ago
themes aren't guaranteed to provide a
.screen-reader-text
-esque class on the front-end
The search form uses .screen-reader-text
since r11312.
There are a variety of CSS classes that WordPress expects themes to define (like .alignleft
, .alignright
, etc.), outlined in the WPTRT guidelines. We should just add it to that list.
#14
@
10 years ago
Chatted with Emil; adding .screen-reader-text to the required classes in theme review.
This doesn't really make the problem simpler, unless we're willing to consider that breaking people's sites who aren't implementing the class is OK. It's still the case that we don't know whether the class is defined, and therefore adding things like labels to the category dropdown will simply show up. Theme support declarations would allow us to tell whether we can add the label without impacting the theme.
#15
@
10 years ago
If it's added to the required classes, then (assuming the patch here goes in), the second part should be to define theme support too, so that WP core and plugins can actually make use of it.
Is the theme review requirement that exactly the class .screen-reader-text
is added, or just a class that is for visually hidden text?
#16
follow-up:
↓ 18
@
10 years ago
- Keywords close added
I don't think that this is a good use of the theme support mechanism. Of course themes are not guaranteed to define .screen-reader-text
, but they also might not define .wp-caption
for example.
The class has been in use for over 5 years now, default themes use it, starter themes use it, functions proposed in #29808 use it.
#17
follow-ups:
↓ 19
↓ 34
@
10 years ago
- Keywords close removed
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't count on its presence.
I think that would be a great solution. Whether this should be a new ticket or continued in this on is a different question.
#18
in reply to:
↑ 16
@
10 years ago
Replying to obenland:
I don't think that this is a good use of the theme support mechanism. Of course themes are not guaranteed to define
.screen-reader-text
, but they also might not define.wp-caption
for example.
That's not a similar example. If a theme doesn't have .wp-caption
, then the captions are still present, albeit not styled. It will inherit whatever the parent of body styles are.
Consider if the patch wasn't accepted. If a theme doesn't include .screen-reader-text
, and WP core starts outputting extra content for the purposes of accessibility, when it should otherwise by visually hidden, then that could start breaking content layout, and all because WP core got upgraded. The only sensible way for a theme to opt in, is to add theme support.
The class has been in use for over 5 years now, default themes use it, starter themes use it, functions proposed in #29808 use it.
Do default themes use it to visually hide output from core, or just extra bits added by themselves? This proposal is to enhance accessibility potentially for all themes, in one go, if they opt in, and not require inconsistent efforts on an individual theme basis. The opening report already highlights three tickets which are effectively halted by the lack of such mechanism, and there may be more I've not found.
#19
in reply to:
↑ 17
@
10 years ago
Replying to 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't count on its presence.
Didn't the gallery styles get removed for gallery html5 support? Why would another situation suggest adding more internal uncacheable style sheets in?
It's also not a standard piece of code - see the linked "This" in the opening report which shows how Twenty Fourteen is doing it different from core admin, which is then also different in H5BP and Bootstrap, even allowing for other choice of class names.
FWIW, I also talked to johnbillion at WCEU, and he said he was happy with my proposal as is.
#20
@
10 years ago
In talking to obenland, what we'd like to try first is to patch the problem areas by adding the appropriate labels and getting the fixed widgets into core without alternate versions. Yes, this could result in some themes having minor change in appearance, but we feel that the better and simpler route is to simply fix the problem.
That could end up with pushback that kills it, but we'd like to try.
#21
@
10 years ago
Here's a real example from outside of core. The Genesis Framework search form, by default doesn't have a <label>
. Amending the code so that it does would change the visual appearance, potentially breaking the layout of 130,000+ sites. Adding a screen-reader-text
class to Genesis style.css
to visually hide the new label won't help, as the child themes don't reference that file - it needs to be in the child theme style.css
.
So, it's exactly the same situation as in core, but the point is, it's not core. It's a theme, and plugins could be in a similar situation. Adding explicit labels to fix the tickets in core doesn't address the issues in the wider context, whereas having a solution that all parties in the community can use (add_theme_support( 'screen-reader-text' )
with something close the patch I've added here) means everyone can use it.
#22
@
10 years ago
Jumping new into the conversation:
I agree with @GaryJ that adding add_theme_support( 'screen-reader-text' ) will be the best way to check for screen reader text CSS and maintain backwards compatibility in themes, frameworks and plugins.
Adding the CSS to core has the disadvantage that core decides how the CSS will look like.
Using the screen-reader-text with hover for skip links needs custom styling to fit the theme's look, and some customers still need IE7 support (yes, I know), so the CSS can differ per theme.
Like @joedolson I can't come up with another a11y functionality for add_theme_support than the screen-reader-text. ARIA labels, roles etc. is all hidden from screen anyway. So if that is added in core/framework/plugin, the front end won't suffer from it.
So, +1 for add_theme_support( 'screen-reader-text' );
#23
follow-ups:
↓ 25
↓ 26
@
10 years ago
Maybe I should have been more verbose in my previous comment.
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!
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.
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.
Also, using theme support to denote support for a specific class feels like using a sledgehammer to crack a nut.
If there are themes that don't have .screen-reader-text
defined, it's an opportunity to educate their authors about it. It is not something for core to fix.
This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.
10 years ago
#25
in reply to:
↑ 23
@
10 years ago
Replying to obenland:
Also, using theme support to denote support for a specific class feels like using a sledgehammer to crack a nut.
If there are themes that don't have.screen-reader-text
defined, it's an opportunity to educate their authors about it. It is not something for core to fix.
+1 from me, on these points.
#26
in reply to:
↑ 23
;
follow-up:
↓ 27
@
10 years ago
Replying to 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 Codex list of required classes.
It's not part of the Theme Handbook list of required classes.
It's not in the 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 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.
#27
in reply to:
↑ 26
;
follow-up:
↓ 30
@
10 years ago
Replying to GaryJ:
Twenty Eleven doesn't support it.
It's not on the Codex list of required classes.
It's not part of the Theme Handbook list of required classes.
It's not in the Theme Check plugin.
Let's change that!
I updated the Codex list and the Theme Handbook list. Happy to create a ticket for Twenty Eleven.
Yes, there are probably a lot of themes out there that don't have the class defined. But creating a new theme support feature for it is just not the way to mitigate it.
I would suggest to start adding the class in a place that is not very visible and start beating the drum with the release of 4.2, doing that theme author education that you agreed we should do. We can then continue to add it in more visible places over time.
#28
@
10 years ago
Created #31095 to add styles in Twenty Eleven, and complete them in Twenty Twelve.
#29
@
10 years ago
Created a pull request for Theme Check.
#30
in reply to:
↑ 27
;
follow-up:
↓ 31
@
10 years ago
I'm definitely +1 to author education, fixing up the Codex and having Theme Check look for it. There's no excuse for new themes not to include it, and that's a good thing.
But it still doesn't change the status quo of existing themes in the wild that aren't likely to be updated. WP core shouldn't start amending existing output (so new pagination functions don't count here) with enhanced accessibility content, just because an instance of WP had a core update.
Replying to obenland:
Yes, there are probably a lot of themes out there that don't have the class defined. But creating a new theme support feature for it is just not the way to mitigate it.
So what do you suggest to specifically address this segment of sites, if WP core is going to be adding more screen-reader-text content?
#31
in reply to:
↑ 30
@
10 years ago
Replying to GaryJ:
So what do you suggest to specifically address this segment of sites, if WP core is going to be adding more screen-reader-text content?
As I said earlier, I would suggest to start adding the class in a place that is not very visible and start beating the drum with the release of 4.2. Continue adding it new functions, making it more common, spreading the word, and then start using it on existing template tags and elements.
#33
@
10 years ago
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
I'm going to close this out. After reading the whole thread, I think obenland makes some excellent points, including:
I would suggest to start adding the class in a place that is not very visible and start beating the drum with the release of 4.2, doing that theme author education that you agreed we should do. We can then continue to add it in more visible places over time.
Also, using theme support to denote support for a specific class feels like using a sledgehammer to crack a nut.
Adding it to theme check and making it required in the theme directory sounds good. If we find later that we need something akin to the proposal here to declare that the theme supports things, due to the impact it may have, then we can reconsider it. But some relevant text showing up on a theme is by itself probably not the end of the world.
#34
in reply to:
↑ 17
@
10 years ago
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 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?
This ticket was mentioned in Slack in #themereview by otto42. View the logs.
10 years ago
#36
follow-up:
↓ 41
@
10 years ago
- Resolution wontfix deleted
- Status changed from closed to reopened
This needs another look at it.
Core just broke backward compatibility with .screen-reader-text in [31821]. Okay, yeah, it's *really* minor, but for anybody running a theme without a .screen-reader-text rule, then now new text appears where it did not appear before.
I don't think we need add_theme_support. I think we need output of the proper rules, by default, without any opt-out. All the twenty-themes have the same basic set of .screen-reader-text rules. Are those rules not universally applicable for "hiding things"?
It seems to me that .screen-reader-text's whole goal is to hide things in an accessible way. Which is fair, but is it really the problem of the theme? Is there any case in which this set of rules Joe provides needs to be altered by a theme in some way? https://make.wordpress.org/accessibility/2015/02/09/hiding-text-for-screen-readers-with-wordpress-core/
Should we not be including some default set of rules for backward compatibility? It could be as simple as a single line of CSS in wp_head. Requiring themes to do this for forward compat and customization is fine, but by not making some form of back-compat, we're putting core in the future position of adding a bunch of new text to people's sites that they might not want to display, and might not be expecting. Comments popup link is just the first, really.
#38
follow-up:
↓ 39
@
10 years ago
I don't think we need add_theme_support.
This should probably be in a new ticket then.
#39
in reply to:
↑ 38
@
10 years ago
Replying to obenland:
I don't think we need add_theme_support.
This should probably be in a new ticket then.
I don't think so. Same problem, just a question of implementation. The problems to be solved is:
a) Should core output CSS into the head?
b) If yes, then should it be opt-in or not?
c) It not, then should it be opt-out or not?
The original ticket was simply yes, opt-in. I think it should be yes, not-optional. But, regardless of the implementation, the problem remains the same.
If this CSS isn't theme-specific in some way, we should not rely on the themes to adjust for it. Is it theme-specific in some manner?
#40
@
10 years ago
If this CSS isn't theme-specific in some way, we should not rely on the themes to adjust for it. Is it theme-specific in some manner?
No, I can't think of anything about this that should particularly be theme specific.
#42
follow-up:
↓ 50
@
10 years ago
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 (#, #), 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.
#43
@
10 years ago
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.
They already have to do that for lots and lots of things. That's par for the course. My concern is not with the developers. They'll adapt and there are fewer of them overall.
No, my concern is with the users. If core is going to start getting into the business of adding screen-reader-text to places where it was not before, in the name of accessibility, then we need to make very, very sure that this new text doesn't interfere with people's existing sites. I don't want people taking actions to remove text from their sites or questions on the support forums from people asking how to make their sites less accessible. And that's the road you're heading down here.
Break one person's carefully made layout in the name of accessibility, and they'll never again think of accessibility as a good thing. What they're going to think instead is that you broke their site in order to help blind people.
So think real long and hard before you start ditching front-end compatibility.
#44
@
10 years ago
I'm entirely in favor of having the styles enqueued into themes by core. It's a tiny quantity of styles, we can make them easy to override, and users have a seamless experience. This is far from being the only code injected by core; anytime a user makes use of MediaElementJS they're pulling in styles and scripts from core. This is unique in that it's getting pulled in globally, but it's not a major issue.
Break one person's carefully made layout in the name of accessibility, and they'll never again think of accessibility as a good thing. What they're going to think instead is that you broke their site in order to help blind people.
This is a very real concern to me, as well. Accessibility has had a struggle for years getting people to understand that it can be done effectively without having significant impact on their designs (outside of color contrast issues) - the last thing we need is to reinforce that negative experience. Thanks for expressing that, Otto.
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
10 years ago
#46
follow-up:
↓ 48
@
10 years ago
Just a note on Otto's remark
It could be as simple as a single line of CSS in wp_head
For Dutch government websites it is forbidden to have CSS added into the <head>, only links to stylesheets are allowed.
So if you would decide on adding CSS in the head, please make it filterable.
This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.
10 years ago
#48
in reply to:
↑ 46
;
follow-up:
↓ 49
@
10 years ago
Replying to rianrietveld:
For Dutch government websites it is forbidden to have CSS added into the <head>, only links to stylesheets are allowed.
Interesting, do they also mention why they want a so "strict" best practice? Would remember them HTML5 allows stylesheets also in the body, if properly scoped :)
#49
in reply to:
↑ 48
@
10 years ago
Replying to afercia:
Replying to rianrietveld:
For Dutch government websites it is forbidden to have CSS added into the <head>, only links to stylesheets are allowed.
Interesting, do they also mention why they want a so "strict" best practice? Would remember them HTML5 allows stylesheets also in the body, if properly scoped :)
Content Security Policy also defaults to not allowing internal style sheets, so it really should be filterable. That way we give the power to those who can make use of it and produce cleaner code that meets their CSP.
#50
in reply to:
↑ 42
@
10 years ago
Replying to 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 (#, #),
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.
This has definitely been a problem with furthering various aspects of accessibility as it applies on the front-end. I'm in favor of making a change that allows us to pursue better accessibility options for the front-end.