Last modified: 2014-11-17 09:48:32 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.
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?
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.
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.
(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>".
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;} }
Applied Raymond's patch (4213) to svn trunk, r28517.
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.
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.
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.
(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.
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,
Sorry, what I said should be shared.css, not common.css.
(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.
Other bugs related to section edit link formatting: bug 1629, bug 11270.
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 [details] 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.
+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.
(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.
(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.
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.
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>
(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?
(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
