Page MenuHomePhabricator

Clean up section edit link brackets
Open, Needs TriagePublic

Description

Section edit links currently emit HTML ~= the following (modulo 2 editlinks, etc. etc.):

<span class="mw-editsection">
  <span class="mw-editsection-bracket">[</span>
  <a href="editlink" title="title">edit</a>
  <span class="mw-editsection-bracket">]</span>
</span>

Volker noted that screen readers read the brackets out (in T13555: .mw-editsection links should not be part of the <h#> element, specifically T13555#6474274). Some other observations:

They are IMO only (somewhat) useful for visual users, exposing them in a screenreader seems verbose to me, as the link gets read out anyways separate object. The divider, as of current <span class="mw-editsection-divider"> | </span>, might make sense, but even that is debatable. We could consider adding aria-hidden="true" to the brackets.

I think it would make sense to push these into CSS instead:

I would guess the brackets being in the HTML is something for older browsers that may be unsupported now. Is there a reason those couldn't be moved to CSS ::before and ::after instead pending some ultimate resolution to this task? Timeless display: nones the brackets in favor of CSS adding a little pen icon on .mw-editsection. I don't really see how Minerva is adding the icon but it also has no brackets though? I don't see an HTML img and I don't see the CSS for background-image (Javascript-added image?).

Here's the new task suggested therein.

Event Timeline

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

matmarex added subscribers: bwang, Esanders, ppelberg.
matmarex subscribed.
In T318174, @bwang wrote:

Description

Because the brackets and vertical divider are actually present in the HTML as text, they are read out to screenreaders, making the "edit" and "edit source" links far less comprehensible. In addition, the usage of the before psuedo element on .mw-editsection means the screenreader reads out "zero width space" before the bracket (Tested with VO)

AE917D83-3734-4A79-A5E8-F831B4A072DE.JPG (1×3 px, 3 MB)

AC

  • Brackets and vertical divider are replaced with psuedo elements and are not read out by screenreaders (i.e. similar to the "[hide]" button in modern Vector's TOC)
  • The psuedo element on .mw-editsection is removed
  • Screenreaders read out the element as "Heading 1, link, edit, link, edit source"

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