Last modified: 2014-11-17 09:48:32 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 11555 - .editsection links should not be part of the <h#> element
.editsection links should not be part of the <h#> element
Status: NEW
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.12.x
All All
: Low normal with 7 votes (vote)
: Future release
Assigned To: Nobody - You can work on this!
: accessibility
: 19022 (view as bug list)
Depends on:
Blocks: semantic-html editlinks
  Show dependency treegraph
 
Reported: 2007-10-03 21:51 UTC by René Kijewski
Modified: 2014-11-17 09:48 UTC (History)
26 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Proposed change (412 bytes, patch)
2007-10-03 21:51 UTC, René Kijewski
Details
revised patch (2.00 KB, patch)
2007-10-04 21:10 UTC, Raimond Spekking
Details

Description René Kijewski 2007-10-03 21:51:03 UTC
Created attachment 4206 [details]
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.
Comment 1 Thomas "Tango" Dalton 2007-10-03 22:01:31 UTC
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?
Comment 2 Graham87 2007-10-04 02:47:55 UTC
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.
Comment 3 Raimond Spekking 2007-10-04 21:10:48 UTC
Created attachment 4213 [details]
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.
Comment 4 René Kijewski 2007-10-07 19:41:20 UTC
(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>".
Comment 5 Huji 2007-11-14 15:32:22 UTC
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;}
}
Comment 6 Leon Weber 2007-12-15 18:33:03 UTC
Applied Raymond's patch (4213) to svn trunk, r28517.
Comment 7 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-12-18 16:43:30 UTC
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.
Comment 8 Daniel Arnold 2007-12-18 22:15:18 UTC
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.
Comment 9 leeyc0 2007-12-19 10:15:32 UTC
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.
Comment 10 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-12-19 16:44:40 UTC
(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.
Comment 11 leeyc0 2007-12-20 00:26:11 UTC
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,
Comment 12 leeyc0 2007-12-20 00:55:10 UTC
Sorry, what I said should be shared.css, not common.css.
Comment 13 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-12-20 21:49:02 UTC
(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.
Comment 14 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-12-21 18:28:07 UTC
Other bugs related to section edit link formatting: bug 1629, bug 11270.
Comment 15 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-04-01 13:32:48 UTC
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.
Comment 16 Brad Jorsch 2009-05-31 15:07:56 UTC
*** Bug 19022 has been marked as a duplicate of this bug. ***
Comment 17 Roan Kattouw 2009-10-28 21:57:06 UTC
Comment on attachment 4213 [details]
revised patch

Marking patch as obsolete: it's ancient, and there's an up-to-date one on bug 11270
Comment 18 p858snake 2011-04-30 00:09:43 UTC
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
Comment 19 DieBuche 2011-07-27 17:00:35 UTC
Patched in r93284
Comment 20 Krinkle 2011-07-27 20:10:41 UTC
Reverted in r93299.
Comment 21 Sumana Harihareswara 2011-11-09 20:05:52 UTC
+reviewed
Comment 22 Krinkle 2012-06-03 15:42:34 UTC
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.
Comment 23 Krinkle 2012-06-03 15:42:51 UTC
Note that this part may be fixed as part of bug 31932.
Comment 24 Daniel Friesen 2013-05-10 12:57:51 UTC
Is this bug relevant anymore? [edit] links are now placed after the header text.
Comment 25 Michael Zajac 2013-05-10 14:36:52 UTC
(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.
Comment 26 S. McCandlish 2013-05-11 22:18:41 UTC
(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.
Comment 27 Sumana Harihareswara 2013-05-22 17:20:43 UTC
MatmaRex, would you mind taking a look at this? Please feel free to de-assign if you'd rather not make the attempt. Thanks!
Comment 28 Bartosz Dziewoński 2013-05-22 17:29:55 UTC
(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.
Comment 29 Bartosz Dziewoński 2013-05-22 18:48:18 UTC
I've created tracking bug 48717 and connected some bugs to it, including this one.
Comment 30 Elitre 2013-08-02 08:35:18 UTC
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.
Comment 31 Derk-Jan Hartman 2013-08-12 17:56:37 UTC
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>
Comment 32 Daniel Friesen 2013-08-12 18:06:55 UTC
That doesn't look like proper use of the header element to me.
Comment 33 Rezonansowy 2014-02-20 13:13:58 UTC
(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>
Comment 34 Michael Zajac 2014-02-21 01:34:53 UTC
(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?
Comment 35 S. McCandlish 2014-02-21 02:33:29 UTC
(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.
Comment 36 Gerrit Notification Bot 2014-09-03 12:07:19 UTC
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
Comment 37 Gerrit Notification Bot 2014-10-26 11:07:31 UTC
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

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links