.mw-editsection links should not be part of the <h#> element
OpenPublic

Description

Currently, screen reader users who navigate by headings constantly hear the word "edit" at the end of each heading because section edit links are part of the <h#> elements. It should be changed so that the <h#> elements contain only the heading text, with the section edit links separated out.

This was originally a bug for the link coming before the heading text, which has since been changed. The original description is preserved below:

Author: rene.kijewski

Description:
Proposed change

For users of screenreaders (and textbrowsers) it takes quite long to walk throught the headlines. At every single headline they hear "[edit]" first instead of the real section title. This could easily be changed by let the edit-section-link come second in the rendered page and let the section title come first. There would not even be visual changes for seeing users and users of graphical browsers.

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz11555.
bzimport created this task.Via LegacyOct 3 2007, 9:51 PM
bzimport added a comment.Via ConduitOct 3 2007, 10:01 PM

thomas.dalton wrote:

That wouldn't be hard to do. It would be better to do it with skins, though, surely? You can specify CSS for different media, I assume screen readers are one such medium. Is there a way to swap the order in CSS in such a way that screen readers would obey it?

Graham87 added a comment.Via ConduitOct 4 2007, 2:47 AM

As I said in <a href="my message to Wikitech a while ago"> http://lists.wikimedia.org/pipermail/wikitech-l/2006-October/027158.html</a>, I would also prefer this behaviour. I think it would be even better if the edit links weren't part of the heading title - the way it was before October 2006. There was a long discussion on Wikitech about this a few months ago - I can't find it at the moment.

Raymond added a comment.Via ConduitOct 4 2007, 9:10 PM

Created attachment 4213
revised patch

I worked a few weeks ago on this issue too, together with a blind people of de.wp. Please find attached my patch, basically the same as the first patch but added some CSS tweaks for some browsers.

I hasitate(d) to commit this patch because I don't know how many JS hacks it will break :-8

Normally it should have no effect to normal seeing people but should have a great improve to people using screenreaders.

attachment Bearbeiten-Link verschieben.patch ignored as obsolete

bzimport added a comment.Via ConduitOct 7 2007, 7:41 PM

rene.kijewski wrote:

(In reply to comment #3)

I hasitate(d) to commit this patch because I don't know how many JS hacks it
will break :-8

At http://www.revolus.de/files/George_Tolhurst.htm I stored a modified version of a random English article with the German JS-hack applied. I modified the page as the patch would do. (But without browser specific stuff.)

And unfortunately there are visual changes:

  • the font of the [edit]-link is much smaller now
  • the link is not floating to the right anymore

I think only the small text is hurdle against the patch. The right floating [edit] often breaks with infoboxes anyway. If the local admins would take the JS-hack out of their MediaWiki:monobook.js/common.js every think would be fine and the visual changes would be gone.

There a little typo in attatchment #4213: "</span>$link </h$level>" should be "</span> $link</h$level>".

Huji added a comment.Via ConduitNov 14 2007, 3:32 PM

Actually, I think one other option is to hide the "edit" link from those using screen readers totally, because they generally won't need it. It can be done, if there is agreement on it, by adding a line to CSS similar to this:

@media reader {
.editsection {display:none;}
}

bzimport added a comment.Via ConduitDec 15 2007, 6:33 PM

leon wrote:

Applied Raymond's patch (4213) to svn trunk, r28517.

bzimport added a comment.Via ConduitDec 18 2007, 4:43 PM

ayg wrote:

Reverted in r28630, for the reasons given in the commit message (i.e., it doesn't work properly). IMO, the correct solution is to change back to the <div><div>[edit]</div> <h#>Heading</h#></div> we had before. Changing to the current form was my fault and I do plan to fix it . . . last time I tried, unfortunately, it broke lots of customizations.

bzimport added a comment.Via ConduitDec 18 2007, 10:15 PM

arnomane wrote:

Erm. What didn't work? It did work properly and I checked it more than once. There was no visible difference. And honestly I give a shit on Javascripts that do not rely on documented API but some undocumented (and braindead) item order. But I do care about handicaped people that have *severe* problems browsing wikipedia *at all* because of this stupid item order.

bzimport added a comment.Via ConduitDec 19 2007, 10:15 AM

lee_yiu_chung wrote:

See bug 12340 and http://encyclopedia.tw/wiki/%E8%AC%9B%E5%80%92%E7%B7%9A . In WinXP + Firefox 2 the edit link appears *below* the title, and the image overlaps the words.

bzimport added a comment.Via ConduitDec 19 2007, 4:44 PM

ayg wrote:

(In reply to comment #8)

Erm. What didn't work? It did work properly and I checked it more than once.
There was no visible difference.

With your particular fonts, on your particular browsers. I said where the problems were: it was blatantly wrong in Opera 9.5 beta, and on a Chinese-language site someone linked to, and undoubtedly in Safari and other browsers. This was expected from looking at the standard and the unexplained figure of exactly -1.2em.

And honestly I give a shit on Javascripts that
do not rely on documented API but some undocumented (and braindead) item order.
But I do care about handicaped people that have *severe* problems browsing
wikipedia *at all* because of this stupid item order.

I would agree if there weren't a better solution, that *didn't* screw up visual page layout, but there is a better solution. As I say, change the elements to <div><span>[edit]</span> <h#>Heading</h#></div>.* This is essentially how it was prior to October 2006. I changed it to that as soon as I was told there was a problem, but Brion reverted me because it (necessarily) broke a lot of CSS. See the discussion that began here:

http://lists.wikimedia.org/pipermail/wikitech-l/2006-October/027130.html

I introduced the issue here:

http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=17078

I fixed it here:

http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=17507

But Brion reverted it here:

http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=17569

Any solution that leaves [edit] inside the header isn't a full solution anyway; it would make it considerably less annoying, doubtless, but you would still have to listen to "edit" after the reader reads every section title. The correct solution is to move the edit link outside the header. That will break all custom section header CSS, because selectors like "h2" will mean something totally different. If you can get Brion to accept that, please do it. I tried it once, within a couple of weeks of introducing the problem, and was reverted. I may try again in a couple of days when finals are over, but if you want to commit a fix before then, feel free.

  • Alternatively, it could be <div><h#>Heading</h#> <span>[edit]</span></div>. In this case you (or I) might try using the technique from bug 1629 comment 27 and 29. Or not float it at all, maybe, as people have been suggesting and I've repeatedly claimed I would do.
bzimport added a comment.Via ConduitDec 20 2007, 12:26 AM

lee_yiu_chung wrote:

Some notes. Just discovered bug 12340 is caused by us - the shared.css somehow disappeared in http://encyclopedia.tw/wiki/%E8%AC%9B%E5%80%92%E7%B7%9A. After uploading the common.css, seems bug 12340 is fixed. You may check it again,

bzimport added a comment.Via ConduitDec 20 2007, 12:55 AM

lee_yiu_chung wrote:

Sorry, what I said should be shared.css, not common.css.

bzimport added a comment.Via ConduitDec 20 2007, 9:49 PM

ayg wrote:

(In reply to comment #11)

Some notes. Just discovered bug 12340 is caused by us - the shared.css somehow
disappeared in http://encyclopedia.tw/wiki/%E8%AC%9B%E5%80%92%E7%B7%9A. After
uploading the common.css, seems bug 12340 is fixed. You may check it again,

Regardless, I observe that it's distinctly too high in IE6, for instance. (It works in FF2 for any font/language combination I tried, to be fair.) It would require a *lot* of hacking to get it to display right in all browsers on all platforms, and still would not properly fix the problem.

bzimport added a comment.Via ConduitDec 21 2007, 6:28 PM

ayg wrote:

Other bugs related to section edit link formatting: bug 1629, bug 11270.

bzimport added a comment.Via ConduitApr 1 2008, 1:32 PM

ayg wrote:

Note that there's been a patch at bug 11270 to fix this since January, but I'm not going to check it in without Brion's okay, since it will break stuff and make users angry.

Anomie added a comment.Via ConduitMay 31 2009, 3:07 PM
  • Bug 19022 has been marked as a duplicate of this bug. ***
Catrope added a comment.Via ConduitOct 28 2009, 9:57 PM

Comment on attachment 4213
revised patch

Marking patch as obsolete: it's ancient, and there's an up-to-date one on bug 11270

Peachey88 added a comment.Via ConduitApr 30 2011, 12:09 AM

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

DieBuche added a comment.Via ConduitJul 27 2011, 5:00 PM

diebuche wrote:

Patched in r93284

Krinkle added a comment.Via ConduitJul 27 2011, 8:10 PM

Reverted in r93299.

bzimport added a comment.Via ConduitNov 9 2011, 8:05 PM

sumanah wrote:

+reviewed

Krinkle added a comment.Via ConduitJun 3 2012, 3:42 PM

Rephrasing bug to reflect original request as well as to address some disagreement regarding the implementation.

The original request was to not put the span.editsection inside the h#. In which order is a different matter and one could even argue that putting it before the .mw-headline is better because the section edit page actually contains the heading itself.

Krinkle added a comment.Via ConduitJun 3 2012, 3:42 PM

Note that this part may be fixed as part of bug 31932.

DanielFriesen added a comment.Via ConduitMay 10 2013, 12:57 PM

Is this bug relevant anymore? [edit] links are now placed after the header text.

bzimport added a comment.Via ConduitMay 10 2013, 2:36 PM

michael wrote:

(In reply to comment #24)

Is this bug relevant anymore? [edit] links are now placed after the header
text.

Still relevant. The edit link is still in the heading, saying that, e.g., “References [Edit]” is the title of an article section.

bzimport added a comment.Via ConduitMay 11 2013, 10:18 PM

smccandlish wrote:

(In reply to comment #25)

(In reply to comment #24)
> Is this bug relevant anymore? [edit] links are now placed after the header
> text.

Still relevant. The edit link is still in the heading, saying that, e.g.,
“References [Edit]” is the title of an article section.

Definitely. I'm surprised that this hasn't been fixed yet, given that patches have been submitted, CSS tweaks gives, and it's been reviewed. This should have been fixed years ago. PS: Krinkle is correct that the .mw-headline should come after the span.editsection for page flow logic reasons, no matter how CSS is used to visually place things (which is ultimately subject to the user agent's local CSS anyway). Not having them in this order will be a major usability problem because people will naturally click on a section's "Edit" link to make changes to the section's heading, and will wax sorely confounded if that heading is not actually within the section.

bzimport added a comment.Via ConduitMay 22 2013, 5:20 PM

sumanah wrote:

MatmaRex, would you mind taking a look at this? Please feel free to de-assign if you'd rather not make the attempt. Thanks!

matmarex added a comment.Via ConduitMay 22 2013, 5:29 PM

(In reply to comment #0)

For users of screenreaders (and textbrowsers) it takes quite long to walk
throught the headlines. At every single headline they hear "[edit]" first
instead of the real section title. This could easily be changed by let the
edit-section-link come second in the rendered page and let the section title
come first.

I have done it while fixing bug 41729, as Daniel points out in comment 24. So the situation is slightly better now (but clearly not perfect).

I'm not sure how feasible would changing the format again be. But anyway there's apparently a lot more bugs about those links that are not consistently tracked than I thought, so some more careful research would be in order.

matmarex added a comment.Via ConduitMay 22 2013, 6:48 PM

I've created tracking bug 48717 and connected some bugs to it, including this one.

Elitre added a comment.Via ConduitAug 2 2013, 8:35 AM

Graham87 comments at en.wp that https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update worsened the situation about this bug for people like him who are using JAWS:

"This change makes reading Wikipedia more annoying for screen reader users, due to bug 11555. The word "edit" (now "edit source[editbeta]" appears as part of the heading title, which is read out in full whenever a screen reader user navigates between headings."

Thanks.

TheDJ added a comment.Via ConduitAug 12 2013, 5:56 PM

I've been trying to find a workaround for this, but I can't really find one.

If we do change this again, perhaps we should introduce an html5 header element at the same time:

<header>
<h2>heading 2</h2><span>editsction</span>
</header>

DanielFriesen added a comment.Via ConduitAug 12 2013, 6:06 PM

That doesn't look like proper use of the header element to me.

Rezonansowy added a comment.Via ConduitFeb 20 2014, 1:13 PM

(In reply to Daniel Friesen from comment #32)

That doesn't look like proper use of the header element to me.

No, it is a very good use. See https://developer.mozilla.org/en-US/docs/Web/HTML/Element/header and http://www.w3schools.com/tags/tag_header.asp

So:
<header>
<h2>Heading 2</h2>
<span>[edit section]</span>
</header>

bzimport added a comment.Via ConduitFeb 21 2014, 1:34 AM

michael wrote:

(In reply to Daniel Friesen from comment #32)

That doesn't look like proper use of the header element to me.

It looks like a valid use to me.

Does header break anything on MSIE 7 or 8?

bzimport added a comment.Via ConduitFeb 21 2014, 2:33 AM

smccandlish wrote:

(In reply to Michael Zajac from comment #34)

(In reply to Daniel Friesen from comment #32)
> That doesn't look like proper use of the header element to me.

It looks like a valid use to me.

Does header break anything on MSIE 7 or 8?

Perfectly valid, even exemplary, use of <header>, but I'm not sure it buys us anything toward resolution of #11555. I'm unaware of any effect this would have on the accessibility or usability problems of the [edit section] links not being part of the <h#> headINGS. Unless I've missed something, <header> is not a semantically required element to put around <h#> headings, nor even a useful one unless there's a specific purpose in mind for doing so, and that purpose is supported by user agents or likely to become supported by them.

I would side with the argument that use of <header> in this case would actually at least be semantically useful for server coders and site implementors, though probably not at all for end users (readers, wikicode editors). Regardless, it won't resolve this bug.

That said, I have not been keeping up with what screen readers are doing with HTML5. Their support for would-be-accessibility-useful features of HTML 4/XHTML 1 and CSS 2 was so awful, I'm not sure I can bear to go see what the developers of such projects are willfully ignoring this time around... But maybe I'm wrong and HTML5 <heading>s are all the rage in screen readers and other agents.

gerritbot added a comment.Via ConduitSep 3 2014, 12:07 PM

Change 158087 had a related patch set uploaded by TheDJ:
[Do not merge] HTML5: Use <header> element to wrap our headings.

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

gerritbot added a comment.Via ConduitOct 26 2014, 11:07 AM

Change 158087 abandoned by TheDJ:
[Do not merge] HTML5: Use <header> element to wrap our headings.

Reason:
Abandoning, since I don't have time for big changes like this. But SOMEONE PLEASE DO IT.

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

He7d3r awarded a token.Via WebNov 24 2014, 12:50 PM
Krinkle removed a project: Future-Release.Via WebNov 25 2014, 9:13 PM
Krinkle lowered the priority of this task from "Low" to "Lowest".Via WebNov 25 2014, 11:57 PM
Krinkle set Security to None.
Krinkle edited the task description. (Show Details)
Krinkle removed a subscriber: wikibugs-l.
Liuxinyu970226 removed a subscriber: Liuxinyu970226.Via WebFri, Feb 27, 9:55 AM
GOIII added a subscriber: GOIII.Via WebSat, Feb 28, 9:29 AM
matmarex changed the title from ".editsection links should not be part of the <h#> element" to ".mw-editsection links should not be part of the <h#> element".Via WebSun, Mar 1, 11:59 PM
wctaiwan raised the priority of this task from "Lowest" to "Normal".Via WebMon, Mar 2, 4:01 AM
wctaiwan added a subscriber: wctaiwan.

I don't think accessibility issues should have "lowest" priority. Even if no one is willing to commit to working on this, it is something we should try to fix sooner rather than later.

wctaiwan edited the task description. (Show Details)Via WebMon, Mar 2, 4:12 AM
wctaiwan edited the task description. (Show Details)Via WebMon, Mar 2, 4:24 AM
MZMcBride added a subscriber: MZMcBride.Via WebMon, Mar 2, 4:25 AM
Quiddity added a comment.Via WebMon, Mar 2, 4:26 AM

I don't think accessibility issues should have "lowest" priority. Even if no one is willing to commit to working on this, it is something we should try to fix sooner rather than later.

Serious or commonly occurring accessibility issues, definitely shouldn't. I believe this particular bug is especially annoying for screenreader users, possibly even warranting high-priority; it's been at the top of Graham87's wishlist for years: http://www.wikimedia.org.au/wiki/User:Graham87/Accessibility_wishlist

MZMcBride added a comment.Via WebMon, Mar 2, 4:39 AM

So:
<header>
<h2>Heading 2</h2>
<span>[edit section]</span>
</header>

This seems reasonable to me.

I've read T13555#167281 a few times and still don't understand the objection.

Perhaps we should set up a quick test using <header> and have @Graham87 and others make sure that this is a viable solution before proceeding?

matmarex claimed this task.Via WebMon, Mar 2, 6:34 AM

I'll try to revive TheDJ's patch. Changing this fully is not simple (backwards-incompatible change to HTML output), but a quick test should be straightforward to set up.

Ricordisamoa added a subscriber: Ricordisamoa.Via WebTue, Mar 3, 6:50 AM
GOIII added a comment.EditedVia WebTue, Mar 3, 11:51 PM

So:
<header>
<h2>Heading 2</h2>
<span>[edit section]</span>
</header>

This seems reasonable to me.

I've read T13555#167281 a few times and still don't understand the objection.

Perhaps we should set up a quick test using <header> and have @Graham87 and others make sure that this is a viable solution before proceeding?

Its a "mis-use" of the header element under HTML5 (which, if followed as depicted above, would make any future implementation of Flex HolyGrail.htm a galactic pain-in-the-ass to put it mildly).

If I followed this discussion coherently -- the goal is to "wrap" one or more h# elements AND the content found under each -- within a parent element -- then we're looking to use the section tag; not header.

If we're looking to just wrap a single header, the title/label, the int:edit link, the new § anchor and/or similar, then neither tags are appropriate; a DIV is.

More: https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Sections_and_Outlines_of_an_HTML5_document

MZMcBride added a comment.Via WebWed, Mar 4, 12:05 AM

Its a "mis-use" of the header element under HTML5 (which, if followed as depicted above, would make any future implementation of Flex HolyGrail.htm a galactic pain-in-the-ass to put it mildly).

I read pages such as http://html5doctor.com/the-header-element/ and it didn't seem like a mis-use to me. Can you elaborate?

If I followed this discussion coherently -- the goal is to "wrap" one or more h# elements AND the content found under each -- within a parent element -- then we're looking to use the section tag; not header.

<section> seems a lot more wrong than <header>, from my understanding. I read the spec to mean that <section> is intended to hold page sections, not just groups of related elements.

If we're looking to just wrap a single header, the title/label, the int:edit link, the new § anchor and/or similar, then neither tags are appropriate; a DIV is.

<div> is the most semantic tag. ;-) But seriously, I'm fine with using <div> here if you really don't like <header>. Either seems fine to me.

TheDJ added a comment.Via WebWed, Mar 4, 12:10 AM

" AND the content found under each", not sure where you are getting that from, but that most certainly is NOT the plan.

The plan is this:

<header>
<h2>Heading 2</h2>
<span>[edit section]</span>
</header>

With the desire to at some point see if we can reach this:

<section>
<header>
<h2>Heading 2</h2>
<span>[edit section]</span>
</header>
section content
</section>

But I'm OK with the following, if people are scared of new elements.

<div>
<h2>Heading 2</h2>
<span>[edit section]</span>
</div>
GOIII added a comment.EditedVia WebWed, Mar 4, 12:37 AM

But I'm OK with the following, if people are scared of new elements.

??? I'm using these elements outside of wiki____ already.

Please download/copy HolyGrail.htm to your local setup & open.

First, shrink your browser window's width until the desktop mw mock-up view automatically switches to Mobile Mode mock-up the appropriate @ media rule. Welcome to the possibilities.

Then please inspect the raw html - simple header - div wrapper of nav (-> sidebar) article (-> mw-content) aside (--> ref notes / side notes) - simple footer.

If article had H1 ~ H6's within it's content, section tag(s) would appear as row container(s) for any combination of H# level ranks within.

GOIII added a comment.Via WebWed, Mar 4, 12:58 AM

I read pages such as http://html5doctor.com/the-header-element/ and it didn't seem like a mis-use to me. Can you elaborate?

GOIII added a comment.Via WebWed, Mar 4, 1:20 AM

This is one "way" I've been doing html5-ish stuff (i.e. a graceful failure more often than not for old/troublemaking browsers)

<header></header>
 <nav>
   <ul>
    <li>Division</li>
    <li>Title</li>
    <li>Section</li>
  </ul>
 </nav>
 <hgroup>
  <section>
   <h1>Division label</h1>
     <p>. . . .  by the 112th Congress</p>
  </section>
  <section>
   <h2>Title label</h2>
     <p>. . . . . An Act for...</p>
   </section>
  <section>
   <h3>Section label</h3>
     <p>. . . . .Preamble paragraph</p>
   </section>
  <section>
   <h4>subsection (a)</h4>
     <li>(1)</li>
     <li>(2)</li>
   </section>
 </hgroup>
<footer> </footer>

Doh! Please make note!!! I left out the hgroup element (above) in my previous

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.