I'm user:Graham87 on the english wikipedia. I use a screen reader called JAWS from Freedom Scientific at: www.freedomscientific.com It is the most popular Windows screen reader at the moment.
My problem is that it appears that the edit link has become part of the title of each section created with wiki markup. This problem is compounded when using quick navigation keys to navigate between sections; in this case, JAWS will stop reading a heading title when it encounters a link. Therefore, each heading title will be read as either "left bracket" or "edit" when I navigate between editable sections on a MediaWiki page. I tested this with JAWS 5.1 and 6.0, which aren't the most recent versions but are still widely used and the problem appears on both of them. I am using Windows XP with IE 6 (Firefox only works well with the latest versions of JAWS). The headings were working fine late last night my time (about 15:30 UTC on 21 October).
I would like this fixed as soon as possible so only the section title is spoken when navigating through headings.
Thanks, Graham
I've checked out the html source for the new layout of edit links, and found that the link title is informative: "edit section: foo" or name of transcluding template. However, JAWS never reads the link title unless it's asked to; it will *always* read the screen text of a link (in this case always "edit") by default. All I really want is for the section editing link not to be part of a heading so JAWS can read the actual heading title of the page. As for display:none, I'd like it nuked; and speak:none isn't recognised by all versions of JAWS so shouldn't be used either.
Graham
-----Original Message----- From: wikitech-l-bounces@wikimedia.org [mailto:wikitech-l-bounces@wikimedia.org]On Behalf Of Graham Pearce Sent: Sunday, 22 October 2006 1:28 PM To: wikitech-l@wikimedia.org Subject: [Wikitech-l] major accessibility problem recently introduced toMediaWiki
I'm user:Graham87 on the english wikipedia. I use a screen reader called JAWS from Freedom Scientific at: www.freedomscientific.com It is the most popular Windows screen reader at the moment.
My problem is that it appears that the edit link has become part of the title of each section created with wiki markup. This problem is compounded when using quick navigation keys to navigate between sections; in this case, JAWS will stop reading a heading title when it encounters a link. Therefore, each heading title will be read as either "left bracket" or "edit" when I navigate between editable sections on a MediaWiki page. I tested this with JAWS 5.1 and 6.0, which aren't the most recent versions but are still widely used and the problem appears on both of them. I am using Windows XP with IE 6 (Firefox only works well with the latest versions of JAWS). The headings were working fine late last night my time (about 15:30 UTC on 21 October).
I would like this fixed as soon as possible so only the section title is spoken when navigating through headings.
Thanks, Graham
_______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On 10/22/06, Graham Pearce grahamwp@optusnet.com.au wrote:
My problem is that it appears that the edit link has become part of the title of each section created with wiki markup. This problem is compounded when using quick navigation keys to navigate between sections; in this case, JAWS will stop reading a heading title when it encounters a link. Therefore, each heading title will be read as either "left bracket" or "edit" when I navigate between editable sections on a MediaWiki page. I tested this with JAWS 5.1 and 6.0, which aren't the most recent versions but are still widely used and the problem appears on both of them. I am using Windows XP with IE 6 (Firefox only works well with the latest versions of JAWS). The headings were working fine late last night my time (about 15:30 UTC on 21 October).
Ah . . . this is my fault. I would have preferred for the order of the spans inside the headings to be logical (title first, then edit link), but that didn't work with the floats. I'll try to find a way to fix this ASAP. (The span was moved inside the header to start with mainly because of poor visual display, with a secondary goal of more logical HTML markup.)
On 10/22/06, Simetrical Simetrical+wikitech@gmail.com wrote:
Ah . . . this is my fault. I would have preferred for the order of the spans inside the headings to be logical (title first, then edit link), but that didn't work with the floats. I'll try to find a way to fix this ASAP. (The span was moved inside the header to start with mainly because of poor visual display, with a secondary goal of more logical HTML markup.)
Please test your changes very carefully before committing them. There has been a lot of irritation at various projects when the user interface changed. Please also remember that individual projects use their own global javascript to manipulate MediaWiki pages (e.g. German Wikipedia which had a script that moves the edit-links from the far right of the page to right next to the heading). If you do decide to make such changes, please make sure it's widely announced. For reasons somewhat outside understanding, users seem to react more allergic to cosmetic changes to the user interface than actual functionality.
Regards,
Sebastian Moleski
On 10/22/06, Sebastian Moleski sebmol@gmail.com wrote:
Please test your changes very carefully before committing them. There has been a lot of irritation at various projects when the user interface changed. Please also remember that individual projects use their own global javascript to manipulate MediaWiki pages (e.g. German Wikipedia which had a script that moves the edit-links from the far right of the page to right next to the heading). If you do decide to make such changes, please make sure it's widely announced. For reasons somewhat outside understanding, users seem to react more allergic to cosmetic changes to the user interface than actual functionality.
I did test my changes carefully before committing them. I just don't have access to a screenreader, so I tested them carefully in visual browsers. I dropped a note at the German and French Wikipedias' Monobook.js talk page informing them of the upcoming change.
And the changes were not merely cosmetic; a usability study posted to this list a while back found that of the two participants who tried using section edit links, both thought they belonged to the section above due to their misplacement, and both blanked the unexpected sections. This is obviously quite undesirable.
On Sun, Oct 22, 2006 at 02:54:02PM -0400, Simetrical wrote:
And the changes were not merely cosmetic; a usability study posted to this list a while back found that of the two participants who tried using section edit links, both thought they belonged to the section above due to their misplacement, and both blanked the unexpected sections. This is obviously quite undesirable.
And I'll throw my oar in here: I'm a savvy-user, with lots of practice intuiting from poorly designed UI's... and I often misread where an edit link goes.
Cheers, -- jra
On Mon, Oct 23, 2006 at 11:40:55AM +1000, Tim Starling wrote:
Simetrical wrote:
I did test my changes carefully before committing them. I just don't have access to a screenreader, so I tested them carefully in visual browsers.
I wonder if Freedom Scientific would be prepared to donate a few licenses for the [Wikipedia] developers.
One of my compatriots who was the lead developer in the HJ days, and went to Microsoft may have a contact; I'm carboning him on this.
Cheers, -- jra
Tim Starling Wrote:
I wonder if Freedom Scientific would be prepared to donate a few licenses for the developers.
The demos of JAWS are fully functional - they will run for forty minutes and then the computer must be rebooted to run them again. The last time I checked, the ILM versions ran like this indefinitely but the "free demo" downloads will run for 60 days. See: http://www.freedomscientific.com/fs_downloads/jaws.asp http://www.freedomscientific.com/fs_downloads/morejaws.asp http://www.freedomscientific.com/fs_downloads/morejaws2.asp And for a summary of the new features for each version since 2001, see: http://www.freedomscientific.com/fs_products/software_jawsfeatures.asp An ILM license will run JAWS versions 5.1 or above and the Quella license will run JAWS versions 3.0 to 5.1. There are two versions of JAWS: standard, which runs on windows 9x/ME/XP home and professional which runs on windows NT/2000/XP pro. The latter is much more expensive to purchase and maintain. http://www.freedomscientific.com/fs_products/JAWS_HQ.asp #Purchasing Information
Window-Eyes is also a widely-used screen reader - it used to be Vocal-Eyes for DOS. The demo has similar limitations; its address is: www.gwmicro.com
Graham
Please test your changes very carefully before committing them. There has been a lot of irritation at various projects when the user interface changed.
That's a bit harsh. The changes were made in response to user requests, plus a separate user-interface study that indicated new users frequently got confused about what the [edit] links were editing, because they were too high off the line. So the changes were made to reduce user-interface irritation.
Furthermore those changes were made in subversion on Wednesday, but were not rolled out to be live for approximately 4 days, which is probably a longer delay that usual. And in that time, the developers (who use a variety of platforms and browsers) had time to test it, and report/fix any problems found before they impacted general users. I certainly tested it before it was rolled out in the browsers that I use, and I didn't find any problems, and as far as I'm aware neither did anyone else.
It's easy to be wise after the event, but the unfortunate fact is that sometimes you only find out about problems after you've gone live. If anyone wants to help reduce this by testing SVN head, I'm sure we'd all be glad to hear of any problems they find.
All the best, Nick.
Nick Jenkins wrote:
Please test your changes very carefully before committing them. There has been a lot of irritation at various projects when the user interface changed.
That's a bit harsh. The changes were made in response to user requests, plus a separate user-interface study that indicated new users frequently got confused about what the [edit] links were editing, because they were too high off the line. So the changes were made to reduce user-interface irritation.
Except, for some reason that hasn't been specified (or I didn't see it), only half the change was made. Instead of simply placing the edit link after the section header's text, as it is both recommended by the study *and* already implemented by the German Wikipedia, you placed it before the section header's text in the source...
On 10/27/06, Timwi timwi@gmx.net wrote:
Except, for some reason that hasn't been specified (or I didn't see it), only half the change was made. Instead of simply placing the edit link after the section header's text, as it is both recommended by the study *and* already implemented by the German Wikipedia, you placed it before the section header's text in the source...
I did specify: "It might be better to have the edit text as de-wiki has it, but that's not a decision I'm willing to commit to by myself; people are bound to object to a perceptible change to the status quo. If someone like Tim or Brion agrees, that would certainly make the solution simpler, but I'm not doing it myself." People are going to complain about not getting consensus, etc.
On 10/27/06, Timwi timwi@gmx.net wrote:
Except, for some reason that hasn't been specified (or I didn't see it), only half the change was made. Instead of simply placing the edit link after the section header's text, as it is both recommended by the study *and* already implemented by the German Wikipedia, you placed it before the section header's text in the source...
I did specify: "It might be better to have the edit text as de-wiki has it, but that's not a decision I'm willing to commit to by myself; people are bound to object to a perceptible change to the status quo. If someone like Tim or Brion agrees, that would certainly make the solution simpler, but I'm not doing it myself." People are going to complain about not getting consensus, etc.
I'm not certain, but I think what Timwi might be saying is that perhaps instead of this: ============================= <a name="X"></a><h2><span class="editsection">[<a href="/wiki/index.php?title=Main_Page&action=edit&section=2" title="Edit section: X">edit</a>]</span> <span class="mw-headline"> X </span></h2> =============================
The HTML source could perhaps be: ============================= <a name="X"></a><h2><span class="mw-headline"> X </span><span class="editsection">[<a href="/wiki/index.php?title=Main_Page&action=edit&section=2" title="Edit section: X">edit</a>]</span> </h2> ============================= (I.e. the headline span before the editsection span, inside the header tag).
Upside: * When copy-and-pasting the web page into a text editor, instead of getting "[edit] Section Title" (which is what happens at the moment), it would probably give "Section Title [edit]", which corresponds to the rendered output we see. * Related to this, maybe it'd be better for screen-reading software?
Downside: This comment indicates that it was tried and does not work: // Yes, the headline logically goes before the edit section. Why isn't it there // in source? Ask the CSS people. The float gets screwed up if you do that. // This might be moved to before the editsection at some point so that it will // display a bit more prettily without CSS, so please don't rely on the order. $head[$headlineCount] .= ' <span class="mw-headline">'.$headline.'</span></h'.$level.'>';
All the best, Nick.
On 10/29/06, Nick Jenkins nickpj@gmail.com wrote:
Downside: This comment indicates that it was tried and does not work: // Yes, the headline logically goes before the edit section. Why isn't it there // in source? Ask the CSS people. The float gets screwed up if you do that. // This might be moved to before the editsection at some point so that it will // display a bit more prettily without CSS, so please don't rely on the order. $head[$headlineCount] .= ' <span class="mw-headline">'.$headline.'</span></h'.$level.'>';
Correct. As it turns out, the CSS people are fine with it, it's the Mozilla and Microsoft people who've screwed up. Basically they seem not to want to evaluate already-drawn text for possible redrawing when drawing floats, so if they encounter a float that's not at the beginning of a line they bump it down a line. https://bugzilla.mozilla.org/show_bug.cgi?id=50630 So no, that's not going to happen.
I tried out tables, but the insurmountable flaw *there* is that for some reason the CSS people (it actually is their fault this time ;) ) said that only line boxes compress for floats, nothing else. So any floats from the previous section overlap the headers horribly. I'm agreeing with Timwi at this point, the only way to solve all this is to just put the links right next to section headers, and any wikis that don't like it can deal with it how they like. I'm still going to ask Tim or Brion before going ahead, though, because this will certainly result in complaints.
Simetrical wrote:
I'm agreeing with Timwi at this point, the only way to solve all this is to just put the links right next to section headers, and any wikis that don't like it can deal with it how they like. I'm still going to ask Tim or Brion before going ahead, though, because this will certainly result in complaints.
This is how German and Swedish Wikipedias have customized it; it's probably fine though I'm not sure I like it... I keep having to wander around to find the link, which is no longer in a consistent clickable position.
We'd want to announce such a change a few days ahead and make sure everybody can whine and complain and be prepared to fix their Monobook.js/css :)
-- brion vibber (brion @ pobox.com)
On 10/30/06, Brion Vibber brion@pobox.com wrote:
This is how German and Swedish Wikipedias have customized it; it's probably fine though I'm not sure I like it... I keep having to wander around to find the link, which is no longer in a consistent clickable position.
I've noticed that too, which suggests that the edit link should perhaps go *before* the header text. (It could then actually be floated with just CSS, for those who wanted that.)
On 10/23/06, Sebastian Moleski sebmol@gmail.com wrote:
sure it's widely announced. For reasons somewhat outside understanding, users seem to react more allergic to cosmetic changes to the user interface than actual functionality.
This probably goes a long way to explaining why the GUI evolves so slowly - every change pisses off *someone* who is usually vocal about it. For some reason, skins don't seem to be solving this problem like they should - it should be possible to introduce changes to skins, so they only affect people who want to live on the bleeding edge. But in reality, everyone uses monobook.
Steve
On 23/10/06, Steve Bennett stevage@gmail.com wrote:
On 10/23/06, Sebastian Moleski sebmol@gmail.com wrote:
sure it's widely announced. For reasons somewhat outside understanding, users seem to react more allergic to cosmetic changes to the user interface than actual functionality.
This probably goes a long way to explaining why the GUI evolves so slowly - every change pisses off *someone* who is usually vocal about it. For some reason, skins don't seem to be solving this problem like they should - it should be possible to introduce changes to skins, so they only affect people who want to live on the bleeding edge. But in reality, everyone uses monobook.
I'd rather use Classic, but there are actually interface buttons no-one bothered putting anywhere but Monobook; saying "hey, I can't see the button" gets the response "use Monobook." So I've ended up having to switch to Monobook.
- d.
On 10/22/06, Simetrical Simetrical+wikitech@gmail.com wrote:
Ah . . . this is my fault. I would have preferred for the order of the spans inside the headings to be logical (title first, then edit link), but that didn't work with the floats. I'll try to find a way to fix this ASAP. (The span was moved inside the header to start with mainly because of poor visual display, with a secondary goal of more logical HTML markup.)
Okay, here's the situation. If the editsection span is placed after the heading proper in source, IE and Firefox don't want to reflow and so they move the float down below any already-rendered content. Opera, and apparently Safari, handle this correctly. I tried fiddling with CSS hacks to get it to display right, but gave up. Currently I'm thinking I'll revert to an in-source layout more like the previous one, with the editsection span placed before the entire h# element, and perhaps the h# element set to display as inline if that looks helpful. Any thoughts?
On 10/22/06, Simetrical Simetrical+wikitech@gmail.com wrote:
Okay, here's the situation. If the editsection span is placed after the heading proper in source, IE and Firefox don't want to reflow and so they move the float down below any already-rendered content. Opera, and apparently Safari, handle this correctly. I tried fiddling with CSS hacks to get it to display right, but gave up. Currently I'm thinking I'll revert to an in-source layout more like the previous one, with the editsection span placed before the entire h# element, and perhaps the h# element set to display as inline if that looks helpful. Any thoughts?
The best I could come up with was to move everything back to the old layout, but wrap headings in a div and change h#'s to display inline, then shift all padding/border/margin rules to affect the wrapper div rather than the h#. That makes the section edit link look good in Monobook, but for some reason it does basically nothing for other layouts.
Frankly, the only real way I can see to solve this properly is to use a table. That would solve this perfectly (the position of table cell contents can be much more simply coordinates than floats plus nonfloats), and would have the added benefit of solving http://bugs.wikimedia.org/show_bug.cgi?id=1629 (which can't be solved at all using CSS). It would also allow the French and German Wikipedias to implement their changes using CSS only, not JS.
Tables shouldn't be used unless necessary, but I've come to conclude that they're so much simpler and more effective here that this is a case where their use is justified. I certainly won't switch things over to tables unless I get the okay for it, but anyway, comments appreciated. I've been working on this for the past five hours and will be taking a little break now (good thing this got to me on a Sunday).
On 10/22/06, Simetrical Simetrical+wikitech@gmail.com wrote:
The best I could come up with was to move everything back to the old layout, but wrap headings in a div and change h#'s to display inline, then shift all padding/border/margin rules to affect the wrapper div rather than the h#. That makes the section edit link look good in Monobook, but for some reason it does basically nothing for other layouts.
Okay, I've finally done this, r17507. Let me know if the problem goes away whenever the next scap happens (probably a few days from now at most). Sorry it took so long.
Simetrical wrote:
Ah . . . this is my fault. I would have preferred for the order of the spans inside the headings to be logical (title first, then edit link), but that didn't work with the floats.
I don't understand why they're still floats? I thought the usability study clearly concluded that they shouldn't be, and that the way the German Wikipedia has implemented them now is more usable.
I agree with them. I say nuke the floats, and place the span after the section title into the h# element.
Timwi
On 10/22/06, Timwi timwi@gmx.net wrote:
I don't understand why they're still floats? I thought the usability study clearly concluded that they shouldn't be, and that the way the German Wikipedia has implemented them now is more usable.
The usability study concluded that people associated them with the section above. This should be fixed by the fact that they're now on the same level as the header text. It might be better to have the edit text as de-wiki has it, but that's not a decision I'm willing to commit to by myself; people are bound to object to a perceptible change to the status quo. If someone like Tim or Brion agrees, that would certainly make the solution simpler, but I'm not doing it myself.
Simetrical wrote:
On 10/22/06, Timwi timwi@gmx.net wrote:
I don't understand why they're still floats? I thought the usability study clearly concluded that they shouldn't be, and that the way the German Wikipedia has implemented them now is more usable.
The usability study concluded that people associated them with the section above. This should be fixed by the fact that they're now on the same level as the header text.
To be honest, I can't tell the different between the old look and the new look. They always have been on the same level to my eye.
-- brion vibber (brion @ pobox.com)
On 10/23/06, Brion Vibber brion@pobox.com wrote:
To be honest, I can't tell the different between the old look and the new look. They always have been on the same level to my eye.
In Monobook it's clearly a bit above, at least for h1's and h2's. There's a very visible gap separating the horizontal rule from the link. In most other styles, yeah, the difference is pretty much invisible.
Timwi schrieb:
I agree with them. I say nuke the floats, and place the span after the section title into the h# element.
Even though I agree with you and would like to see the behavior from de and fr to be default, there should be a possibility to switch to the old style. Most people on de.wiki like the new position of the links (or at least don't dislike it), but there are quiet some people that don't want to use it (http://de.wikipedia.org/wiki/Spezial:Search?ns2=1&search=oldEditsectionL...)
dbenzhuser wrote:
Timwi schrieb:
I agree with them. I say nuke the floats, and place the span after the section title into the h# element.
Even though I agree with you and would like to see the behavior from de and fr to be default, there should be a possibility to switch to the old style. Most people on de.wiki like the new position of the links (or at least don't dislike it), but there are quiet some people that don't want to use it (http://de.wikipedia.org/wiki/Spezial:Search?ns2=1&search=oldEditsec tionLinks&fulltext=Suche)
I like the way the edit section links are set up on de and fr; there also used that way on the english wikiversity: http://en.wikiversity.org/wiki/MediaWiki:Monobook.js In that configuration, the edit link is read after the section title and no brackets are read, so I think it makes more sense from an accessibility standpoint. I also think there should be an option to revert to the old behaviour, probably in special:preferences so it's easily accessible.
Graham
dbenzhuser wrote:
Timwi schrieb:
I agree with them. I say nuke the floats, and place the span after the section title into the h# element.
Even though I agree with you and would like to see the behavior from de and fr to be default, there should be a possibility to switch to the old style. Most people on de.wiki like the new position of the links (or at least don't dislike it), but there are quiet some people that don't want to use it (http://de.wikipedia.org/wiki/Spezial:Search?ns2=1&search=oldEditsectionL...)
Well duh. In the same way that it is possible to manipulate the current skin into de's/fr's layout using JavaScript, it is possible to do just the reverse as well, except this time the JavaScript would be in users' own .js pages where they actually belong.
Timwi
On 22/10/06, Graham Pearce grahamwp@optusnet.com.au wrote:
I'm user:Graham87 on the english wikipedia. I use a screen reader called JAWS from Freedom Scientific at: www.freedomscientific.com It is the most popular Windows screen reader at the moment. My problem is that it appears that the edit link has become part of the title of each section created with wiki markup. This problem is compounded when using quick navigation keys to navigate between sections; in this case, JAWS will stop reading a heading title when it encounters a link. Therefore, each heading title will be read as either "left bracket" or "edit" when I navigate between editable sections on a MediaWiki page. I tested this with JAWS 5.1 and 6.0, which aren't the most recent versions but are still widely used and the problem appears on both of them. I am using Windows XP with IE 6 (Firefox only works well with the latest versions of JAWS). The headings were working fine late last night my time (about 15:30 UTC on 21 October). I would like this fixed as soon as possible so only the section title is spoken when navigating through headings.
Here's a question: what happens in skins other than Monobook (the default)? e.g. does Classic do this?
(Not that Monobook shouldn't be fixed, since it's the default skin. But this may give you something usable in the meantime.)
- d.
On 10/22/06, David Gerard dgerard@gmail.com wrote:
Here's a question: what happens in skins other than Monobook (the default)? e.g. does Classic do this?
(Not that Monobook shouldn't be fixed, since it's the default skin. But this may give you something usable in the meantime.)
All skins will display the behavior until it's fixed.
On Sun, Oct 22, 2006 at 01:27:54PM +0800, Graham Pearce wrote:
I'm user:Graham87 on the english wikipedia. I use a screen reader called JAWS from Freedom Scientific at: www.freedomscientific.com It is the most popular Windows screen reader at the moment.
Is *that* where JAWS ended up?
I did a little work on it, away back in the DOS days; while Henter-Joyce still owned it...
Cheers, -- jra
wikitech-l@lists.wikimedia.org