Small FYI: according to a post by accessibility expert Leonie Watson, CSS generated content is read out in modern browsers. Maybe the fact that [] won’t be in separate spans will help the screen readers to ignore them, but be aware that this is an assumption that needs to be tested (or ask around people who cssfied parentheses on various special pages?).

In T268900#7014492, @stjn wrote:

Small FYI: according to a post by accessibility expert Leonie Watson, CSS generated content is read out in modern browsers. Maybe the fact that [] won’t be in separate spans will help the screen readers to ignore them, but be aware that this is an assumption that needs to be tested (or ask around people who cssfied parentheses on various special pages?).

Latest spec allow alternative text to be specified in content: https://www.w3.org/TR/css-content-3/#alt but browser support is poor so far: https://caniuse.com/mdn-css_properties_content_alt_text (only Chromium and friends).

We don't know whether moving the brackets to CSS generated content would make this better or worse, but we could try it out – keep the <span class="mw-editsection-bracket"> in HTML, but hide it with display: none and add it back with content: .... If it works better, we can then remove the HTML markup. If it works worse, we can easily revert the change.

(Making and reverting changes to the generated HTML requires a lot of waiting while caches expire.)

Is there follow-up work here to suppress the [ | ] readout in screen readers? Setting aria-hidden="true" to those brackets wouldn't be too hard.

In T268900#8256603, @matmarex wrote:

Latest spec allow alternative text to be specified in content: https://www.w3.org/TR/css-content-3/#alt but browser support is poor so far: https://caniuse.com/mdn-css_properties_content_alt_text (only Chromium and friends).

The other major browsers now support alt text in generated content; Firefox and Safari support is about a year old, see also T320996. (I noted there are other targets too today for content generation using this new CSS.)

I think from that perspective there's no loss to making the CSS change now. Either a) the content is voiced, which is how it is Today anyway, or b) it's not voiced for a browser that recognizes the new rule. (Progressive enhancement after the browsers started unprogressively enhancing our content! :)

We don't know whether moving the brackets to CSS generated content would make this better or worse, but we could try it out – keep the <span class="mw-editsection-bracket"> in HTML, but hide it with display: none and add it back with content: .... If it works better, we can then remove the HTML markup. If it works worse, we can easily revert the change.

As reasonable as any other plan.

In T268900#11287626, @cscott wrote:

Is there follow-up work here to suppress the [ | ] readout in screen readers? Setting aria-hidden="true" to those brackets wouldn't be too hard.

No work has been done here AFAICS. I personally try to tend away from aria as a grab-all solution, and going the aria-hidden way probably adds HTML rather than reduces it (and we like reducing HTML I suspect), but I have no strong favor for one or another solutions.

Change #1281800 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] [WIP] Hide section edit links decorations from screen readers with CSS

https://gerrit.wikimedia.org/r/1281800

Test wiki created on Patch demo by Matma Rex using patch(es) linked to this task:
https://52f304fbbc.catalyst.wmcloud.org/w/

I have not tested it very thoroughly, but it seems to work. Android's Talkback no longer points out the square brackets when navigating.

Change #1281800 merged by jenkins-bot:

[mediawiki/core@master] Hide section edit links decorations from screen readers with CSS

https://gerrit.wikimedia.org/r/1281800

Discussion Tools currently displays its brackets around ‘(un)subscribe’ action like this on translatewiki.net:

Don’t know how widespread it is (on Wikipedia I had that disabled because I use CD) but probably requires a hotfix if it is.

I think it only affects users and wikis without visual enhancements – the latter means enwiki. So considering default user preferences, it affects only one wiki, but a pretty large one.

Looking at the Gerrit change for core, I think the following needs to be added to DiscussionTools:

/* TODO: Remove these elements from the HTML. (T268900) */
.ext-discussiontools-init-section-subscribe-bracket {
  display: none;
}

(tested using developer tools on live translatewiki.net). While I don’t think the double brackets are UBN, this change is trivial enough that I hope it can be merged tomorrow, so that it hits WMF wikis together with the core change.

Visual enhancements are not applied on all pages by default so if you’re looking at a page outside of talk namespaces, the chances are, you’ll see this problem.

Good point, I forgot this. I was wondering why I see the brackets on https://translatewiki.net/wiki/Support even though I have visual enhancements enabled… So it affects even more high-traffic pages (village pumps, noticeboards etc. on all wikis). I still don’t think it’s UBN (it’s just a tiny annoyance), but I still hope it can be fixed tomorrow.

However, in case it doesn’t get fixed, I’m adding DiscussionTools so that people complaining about it are less likely to open duplicate tasks.

Thanks. I suppose we should do the same for DiscussionTools's [reply] links, which use very similar brackets.

Change #1301800 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/DiscussionTools@master] Hide reply/subscribe links decorations from screen readers with CSS

https://gerrit.wikimedia.org/r/1301800

Change #1301800 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Hide reply/subscribe links decorations from screen readers with CSS

https://gerrit.wikimedia.org/r/1301800

Thanks for the fix @matmarex!

Change #1302974 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/DiscussionTools@master] Remove reply/subscribe links brackets from page HTML

https://gerrit.wikimedia.org/r/1302974

Change #1302975 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/DiscussionTools@master] Remove old styles for hiding reply/subscribe links brackets

https://gerrit.wikimedia.org/r/1302975

I think requiring all the links in such a structure to be direct descendants with <a> selector was a bit too strict. See, for instance, https://ru.wikipedia.org/wiki/Шаблон:Действия_для_страницы — I cannot update it entirely to the new markup (it uses .mw-editsection-like which should hopefully still be fine) because the last element in the list is wrapped in a <span>.

(though this specific example also gets complicated from Parsoid inserting its markup into things...)

As this recent change has broken multiple things, is there a reason it has not been rolled back?

Note red box added for emphasis.

In T268900#12035542, @Zackmann08 wrote:

As this recent change has broken multiple things, is there a reason it has not been rolled back?

Note red box added for emphasis.

As I said at VPT, this is a change with some minor disruption that needs updates for looks onwiki.

I did make the change fixing that issue in most skins but that made me discover that Timeless implements its own editsection styling but doesn’t pass it on to .mw-editsection-like (despite having some basic styles for it). Probably should be fixed via some patch to it.

(Same with Minerva now that I checked for it. Damn it.)

Some other things we're reckoning with after this change is that

<a></a><a></a> has no implicit space between each anchor element so it can lead to words stuck together. Potentially in screen readers, definitely in skins that don't have mw-editsection-like (like Minerva e.g. already-existing T405802 and also Timeless), and likely in text-only browsers like Lynx.

In T268900#12035542, @Zackmann08 wrote:

As this recent change has broken multiple things, is there a reason it has not been rolled back?

Note red box added for emphasis.

I lack the clairvoyance to roll back the change before I am aware of the things it broke. I fixed all issues reported so far, but yours is the first report I see of this one. Apparently it's already fixed on-wiki (thanks, @stjn). If there are other broken things, please let me know about them as well.

For the record, I'm open to rolling it back if we encounter any issues that are more difficult to fix, I planned this change specifically in a way that would make that easy (T268900#8256603). It's technically Friday (UTC) now, so the soonest that could happen would be on Monday morning.

In T268900#12035777, @stjn wrote:

I did make the change fixing that issue in most skins but that made me discover that Timeless implements its own editsection styling but doesn’t pass it on to .mw-editsection-like (despite having some basic styles for it). Probably should be fixed via some patch to it.

In T268900#12035858, @Izno wrote:

<a></a><a></a> has no implicit space between each anchor element so it can lead to words stuck together. Potentially in screen readers, definitely in skins that don't have mw-editsection-like (like Minerva e.g. already-existing T405802 and also Timeless), and likely in text-only browsers like Lynx.

For reference, screenshots of Timeless and Minerva:

I guess if you think about it, these links should be a list, with each one in its own list item. Easy enough to do in the code (here), but I haven't thought about consequences of that, and I don't know how well that would work for screen reader users (and improving that was the whole motivation for this change).

Adding spaces in place of the dividers and adjusting the CSS to support that seems less troublesome (and then we wouldn't have to write custom CSS in these skins, since the fallback would be okay).

In T268900#12035911, @matmarex wrote:

I guess if you think about it, these links should be a list, with each one in its own list item. Easy enough to do in the code (here), but I haven't thought about consequences of that, and I don't know how well that would work for screen reader users (and improving that was the whole motivation for this change).

This just ends up being the hlist pattern a la onwiki or the forked one in core, which is screen reader friendly. To some degree, maybe friendlier than a pile of spans living just after a heading. Though I've seen Lighthouse get annoyed at lists of only one element show up here in Phab, which might be or is how mw-editsection is presented on wikis that aren't double-edit-button wikis, which is most of them. (Modulo user scripts, which aren't of interest for the 99% case.)

Adding spaces in place of the dividers

Not sure what this means? <a></a> <a></a> in the HTML and then adjust the CSS, or something else?

I do think between the two it's probably reasonable to just plop some links in the text.

I've added a little margin to each of the links in the meantime.

Just to update, I'm not currently planning to roll back the changes. Please let me know if you discovered some issues that would warrant doing it. Other than what we discussed here, the only problems I know about are T429647: Square brackets after signature in Reply tool preview (fixed, waiting for deployment) and https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Edit_button_is_wonky (fixed on-wiki).

I'll wait another week or two to make sure we have no reason to revert, since reverting would be more difficult after the next steps are done. The next step would be deploying https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/+/1302974 and a similar patch for core (to be written) to remove the HTML markup.

This also broke a prominent gadget on English Wikivoyage which I had to jump in to fix over the weekend. I missed the associated tech news post if it was posted.

I’ve run into another problem:

There is a stray pipe for me on https://en.wiktionary.org/wiki/leu. Looking at the CSS, this is because I use NoScript on Wiktionary, and the rule

.client-nojs .mw-editsection-visualeditor,
.client-nojs .mw-editsection-visualeditor + .mw-editsection-divider {
	display: none;
}

(rEVED modules/ve-mw/init/styles/ve.init.mw.DesktopArticleTarget.noscript.less (at 1125b683f1fd)) no longer selects the pipe.

This is quite an edge case (it can happen either if one manually disables JS in the browser like me, or if one is using a years-old browser version), so I don’t think it warrants a rollback, but it should be fixed.

Change #1305532 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/VisualEditor@master] Fix hiding section edit link divider in no-JS envs

https://gerrit.wikimedia.org/r/1305532

In T268900#12035911, @matmarex wrote:

Apparently it's already fixed on-wiki (thanks, @stjn). If there are other broken things, please let me know about them as well.

The Documentation module is popular on a few other wikis and people may not know what's going on.

Stjn's fix on enwiki is "a hotfix for phab:T268900 issue" — it'd be good to know if it's going to stay or not.

Since no one really objected to it being there, I think it’s staying. However, it also requires a following edit to /styles.css subpage at the moment, since Minerva and Timeless do not provide their own editsection styling: https://en.wikipedia.org/?diff=1360085358

Change #1305532 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Fix hiding section edit link divider in no-JS envs

https://gerrit.wikimedia.org/r/1305532