Page MenuHomePhabricator

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

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.

Details

Reference
bz11555

Event Timeline

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

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

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.

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 lowered the priority of this task from Low to Lowest.Nov 25 2014, 11:57 PM
Krinkle updated the task description. (Show Details)
Krinkle set Security to None.
Krinkle removed a subscriber: Unknown Object (MLST).
matmarex renamed this task 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 Medium.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.

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?

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.

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

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

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.

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

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

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.

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?

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

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.

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

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

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

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 ?

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

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.

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.

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

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

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.

One thing related, noticed in conversation with screenreader user browsing a desktop article of Finish Wikipedia, the brackets are read out every time as well. 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. Posting here, as this is mainly related to the edit links experience, but happy to carve the topic out in a separate task.

One thing related, noticed in conversation with screenreader user browsing a desktop article of Finish Wikipedia, the brackets are read out every time as well. [snip]

We could consider adding aria-hidden="true" to the brackets. .... but happy to carve the topic out in a separate task.

Yeah, maybe better to have a separate task for that.

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