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

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.

There are a very large number of changes, so older changes are hidden. Show Older Changes

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.

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.

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.

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,

lee_yiu_chung wrote:

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

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.

ayg wrote:

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

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.

  • Bug 19022 has been marked as a duplicate of this bug. ***

Comment on attachment 4213
revised patch

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

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

Patched in r93284

Reverted in r93299.

sumanah wrote:

+reviewed

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.

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

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

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.

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.

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!

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

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

Elitre added a comment.Aug 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.Aug 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>

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

(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>

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?

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.

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

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

Krinkle edited the task description. (Show Details)Nov 25 2014, 11:57 PM
Krinkle lowered the priority of this task from "Low" to "Lowest".
Krinkle set Security to None.
Krinkle removed a subscriber: Unknown Object (MLST).
GOIII added a subscriber: GOIII.Feb 28 2015, 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".Mar 1 2015, 11:59 PM
wctaiwan raised the priority of this task from "Lowest" to "Normal".Mar 2 2015, 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)Mar 2 2015, 4:12 AM
wctaiwan edited the task description. (Show Details)Mar 2 2015, 4:24 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

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.Mar 2 2015, 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.

GOIII added a comment.EditedMar 3 2015, 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

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.Mar 4 2015, 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.EditedMar 4 2015, 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.Mar 4 2015, 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.Mar 4 2015, 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

TheDJ added a comment.EditedMar 11 2015, 10:57 AM

hgroup never made it to the final html5 right ?

Since we cannot introduce sections right now, and because the spec for header defines: "The header element represents introductory content for its nearest ancestor sectioning content or sectioning root element", we should not use the <header> element right now (because we only have the body section), but I really see no reason why when we ARE introducing sections, we cannot turn this new div straight into a <header> element.

The whole purpose of a header element is to group introductory content of a section (any section, including body, main, article etc). What is implied is that any structure at the start (or in case of footer at the end) of a section, that is separately identifiable from the content of the section, qualifies as a header or footer. Our edit links seem to make that qualification in my opinion.

I also see no reason why that would interfere with flex, or media queries, the holy grail is just ONE simple version of using these, not by a long shot the only way to do so.

GOIII added a comment.Mar 12 2015, 5:17 AM

Further down in the same revision of the recommended spec (or even in the nightly draft for that matter), it goes on to note...

Note: The header element is not sectioning content; it doesn't introduce a new section.

These new elements augment the rank-based (h1-h6) heading elements but have no effect on the actual outline (they are more conceptual than tangible compared to the "old" approach with h1-h6 in other words). That makes using a div now and hoping to "swap it out" somehow later a non-starter because its accounting (a block/box level element) will always effect structure (outline).

Ltrlg added a subscriber: Ltrlg.Mar 23 2015, 10:47 AM

Change 200312 had a related patch set uploaded (by TheDJ):
[WIP] Move edit-section out of h1-h6

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

matmarex reassigned this task from matmarex to TheDJ.Mar 28 2015, 3:56 PM
TheDJ added a comment.Mar 28 2015, 4:11 PM

So let's get a road plan for this:

  • Design new layout (see my changes to Linker)
  • Rollout new CSS before deploying Linker changes
  • Find out which existing code this will impact functionally
    • Parsoid
    • VisualEditor
    • MobileFrontend
  • Find out what extensions have indirect dependencies (I see tests in CommonsMetadata that would break for instance)
  • Fix everything to either
    • no longer depend on this
    • be able to handle the new layout
    • work in a 'dual' mode? (use global var?)
  • deploy, revert, deploy, fix, fix, fix, fix

Anyone got any clue how to gather all this data ?

(Vaguely related: T18190)

DieBuche removed a subscriber: DieBuche.Apr 10 2015, 7:18 AM
TheDJ removed TheDJ as the assignee of this task.May 16 2015, 8:52 AM

Change 200312 abandoned by TheDJ:
[WIP] Move edit-section out of h1-h6

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

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 27 2015, 6:20 PM
GOIII added a comment.EditedNov 16 2015, 11:56 PM

Just to refresh the current state of affairs from the 6 ~ 7 years since things were first reported for clarity...

Currently, an input of...

== Heading level 2 ==

... creates an underlying HTML of...

<h2>
<span class="mw-headline" id="Heading_level_2">Heading level 2</span>
<span class="mw-editsection">
	<span class="mw-editsection-bracket">[</span>
		<a title="Edit section: Heading level 2" href="/w/index.php?title=Headings&amp;action=edit&amp;section=2">edit</a>
	<span class="mw-editsection-bracket">]</span>
</span>
</h2>

... roughly rendering as so upon viewing.

Heading level 2 [Edit]

.
Please Note: since we are "under" the wiki-mark-up, near-all heading tag enclosed content (or section titles) are automatically rendered along with a link to the right ( [edit] as shown in the final rendering depiction above). This Edit link allows the direct editing of a specific section of an article.

Apparently; [all | some] screen readers initiate an "audio cue" whenever it's focus "lands" on a H1 thru H6 heading tag, where [any | all] of the $text detected between the opening & closing heading tags (in essence) becomes that "audio cue" and is 'read out loud' for the benefit of the User:

Taking this current 'recap & review' given above [re]framed with the original problem reported, the issue is that the 'audio cue' read aloud is...

"Heading level 2 edit"

... when it should be omitting the automatically inserted section Edit link and read aloud as...

"Heading level 2"

... instead.


My first question even before bringing up the possible redesigning of the section and edit link generation scheme is if anybody has simply tried to use css/media rules to prevent the "reading" of the unwanted Edit term instead?

In Other Words: Does applying the following to the appropriate css in play change anything?

@media speech, print {
	.mw-editsection, .mw-editsection-like, .mw-editsection > *, .mw-editsection-like > * {
		display: none;
		speak: none;
	}
}

My first question even before bringing up the possible redesigning of the section and edit link generation scheme is if anybody has simply tried to use css/media rules to prevent the "reading" of the unwanted Edit term instead?

Screen reader users like myself would want the "edit" term read out, so we can edit each section like everybody else. The media attribute isn't supported well by screen readers anyway. I for one would just like the old behaviour (pre-2006) where the edit link is outside the section name.

GOIII added a comment.EditedNov 17 2015, 1:14 AM

Screen reader users like myself would want the "edit" term read out, so we can edit each section like everybody else. The media attribute isn't supported well by screen readers anyway. I for one would just like the old behaviour (pre-2006) where the edit link is outside the section name.

Preferences are OK; the more choices & the more options available to the User, the better the Wiki experience can be, but this should never be achieved by placing 'an overbearing cost' upon other User's preferences or needs (whenever possible).

That said.. what is currently your experience with headings and screen-readers?

It sounds like the current state of affairs for you is indeed "reading out" all the "text" being "detected" but for some reason you are unable to actually invoke an edit session as you once were able to prior to the ~2007 change?

The whole point I'm trying to make here is why not try to make both possibilities a "reality" that's also "easy" all around if possible? See the semi-relevant points made in T33932 for example.

GOIII added a comment.Nov 17 2015, 7:55 AM

@Graham87, I applied some screen-reader specific .css to the test2.wikipedia.org test site.

Can you tell us if the [Edit] links are still being displayed and work to open an edit session but are no longer "read aloud" with your screen reader now?

Try https://test2.wikipedia.org/wiki/Headings for starters or you can make your own testbed to check against.

wctaiwan removed a subscriber: wctaiwan.Nov 17 2015, 8:03 AM

@GOIII: The headings on that page read exactly the same as they do on the regular site on the latest release versions of both JAWS and NVDA.

That said.. what is currently your experience with headings and screen-readers?

It sounds like the current state of affairs for you is indeed "reading out" all the "text" being "detected" but for some reason you are unable to actually invoke an edit session as you once were able to prior to the ~2007 change?

Oops, I missed this comment until now. The English and German Wikipedias (and perhaps others?) use a JavaScript trick to put the edit link *after* the section name, so when I navigate by heading I hear "<heading name> edit". I can access the section editing link fine; it's just annoying to hear the word "edit" after each section name.

Oops, I missed this comment until now. The English and German Wikipedias (and perhaps others?) use a JavaScript trick to put the edit link *after* the section name, so when I navigate by heading I hear "<heading name> edit". I can access the section editing link fine; it's just annoying to hear the word "edit" after each section name.

Javascript trick? Even when I'm not logged in, the edit link is ~1em to the right of the section heading. Its been some time since the Edit link loaded at the far right of the section heading (unless there some difference in the skin being used or something.

Anyway if you can double check that javascript thing and re-check the test page from earlier once again (I tweaked it some more), I'll stop pestering you and go dig up a screen reader of my own to look into this aspect on my own.

Thanks again

Javascript trick? Even when I'm not logged in, the edit link is ~1em to the right of the section heading. Its been some time since the Edit link loaded at the far right of the section heading (unless there some difference in the skin being used or something.

Anyway if you can double check that javascript thing and re-check the test page from earlier once again (I tweaked it some more), I'll stop pestering you and go dig up a screen reader of my own to look into this aspect on my own.

Thanks again

I don't know how it was done ... but I seem to recall the position of the section edit links was changed some time ago.

I've checked the test page again; still no change.

GOIII added a comment.Nov 18 2015, 2:33 AM

I don't know how it was done ... but I seem to recall the position of the section edit links was changed some time ago.

Well "in the beginning", the default __rendering__ of the [Edit] link was at the very-most far right of the section heading and at some point later on they had it display immediate after the section heading with approx. 1.00em spacing in between the two.

I believe the default __positioning__ of the html element 'holding' that auto [Edit] link generation has gone once or twice from being 'placed' before then and/or after the H# tag and/or currently to within the H# tag itself -- switching from DIV to SPAN tags (and back) accordingly.

So the positioning of the element tags within the html document outline didn't necessarily correlate to the change in the rendering of the [Edit] link; the two aspects are associated but independent of each other. In your case, however, once the positioning of the link was placed within the H# tags, it seems to have affected your screen reader's behavior.

I've checked the test page again; still no change.

Damn that's odd. There is no reason for those settings failing to prevent the reading aloud of Edit. The last thing I can think of trying is "setting" the volume for that containing element to 'zero' but that's sort of hackish; so I'd rather not. I'm curious to hear what happens if you switch to Mobile-mode where the [[Edit]] link becomes a pencil icon. Either way, if I come across anything worth trying, I'll touch-back with it here.

In the mobile version, the edit links are still read out when navigating by heading here.

Add Comment