Wed, Mar 14
Nope, neither NVDA or JAWS can read out the target URL. But it doesn't really matter anyway. with the regular external link icon. I'm more concerned about links to files like PDF's ... but it seems they don't get any special treatment now for sighted users either.
Tue, Mar 6
Feb 20 2018
Thanks, the tables sound good.
Thanks very much; they work! I would slightly prefer if the month/year counts were displayed in an HTML table rather than a div (especially the month counts), so I could navigate up an down the data more easily. The only other accessibility-related problem I've noticed is I can't read what I've found out is a tooltip (through the HTML source) just above the listing for the number of articles created.
Feb 16 2018
Yeah, that's really not a good thing. It used to be the case that deleting and undeleting pages would fix these byte count problems. I actually relied on this feature last night my time when doing a very convoluted history merge/split to the articles "Power set" and "Powerset (company)". A very problematic revision is revision ID number 196132373 from the "Powerset (company)" page with the edit summary "moved PowerSet to this, which was previously a redirect to Power set" (with links removed). It shows up in the history as having added 6,400 bytes to the page, despite both it and the previous revision having been 6,422 bytes. That's because the parent ID of the offending revision is 189554283, which now belongs to the Powerset page after my history merges/splits. If a maintenance script went through and made sure all parent IDs were in chronological order (and that was enforced from now on), that would solve quite a few problems such as this one ... AFAIK it would only negatively affect revisions with out-of-order dates, such as those in T4219.
Feb 14 2018
Thanks very much. The screen reader I use is JAWS.
Feb 13 2018
The new wikitext option in the edit counter kinda resolves this for me; I can preview the result in my sandbox and it works fine ... I can even access the timecards now! If a text-only option was added that basically provided a more user-friendly way to do that, I'd say the bug would be completely resolved.
Feb 12 2018
Jan 25 2018
Jan 24 2018
Jan 17 2018
Dec 26 2017
Yep, that's what I'm talking about. That fix sounds cool.
There aren't currently any edits on enwiki with rev_user_text pointing to User:0 and rev_user being 0, so I'm not sure why you're
There were, but it looks like they were changed to the current userid of 0 by the script in T181731 ... see the end of this list of contribs:
Dec 25 2017
Also, for example, this link should show far more than 194 edits:
Dec 20 2017
Dec 14 2017
Would we able to undo the results of this script or reconfigure it for the Nostalgia Wikipedia? One of the good things about that site (a copy of the Wikipedia database from 20 December 2001) is that it made it fairly easy to compare edits from 2001 between enwiki and the Nostalgia Wikipedia database. Now that's impossible:
Dec 8 2017
Also, the script should probably increment user_editcount in the user table if that's not done automatically by some other process.
Also, a relevant technical village pump thread:
Another complication relating to this script would be T2323, involving usernames stored with underlines, extra spaces and initial lower-case letters. Quite a few edits affected by this bug also have a rev_user of 0 ... they can probably be found in all the tables besides the "/Positive rev_user" one here: https://en.wikipedia.org/wiki/User:Nemo_bis/Bug_323_revisions
Oct 12 2017
Sep 8 2017
Aug 12 2017
Yes, controls should be standardised and should be keyboard-accessible. I should at least be able to write queries in the edit box and use the combo box filters using standard keystrokes for those things.
Aug 1 2017
@TheDJ: JAWS doesn't announce the definition lists in colon-indented discussions. NVDA does though.
I'd really like to have some understanding about how @Graham87 currently interacts with this. Especially, as I know he does make use of the indentation. I wonder if he just counts the colons in the wikitext, or if he also uses the dl nesting structure of the HTML to figure out who is replying to who... In case of the latter, then adding role="presentation", might actually make the accessibility even worse.
Jul 5 2017
If I didn't know any better, I'd say that this bug occurs because revisions deleted before Wikipedia was upgraded to MediaWiki 1.5 don't have a revision ID number (see T20104).
Apr 28 2017
I did searches for "Joni" and "Banff", two terms in the first URL in the edit to Joni Mitchell linked above, in the Wayback Machine for http://music.cbc.ca. FWIW it coughed up the following URLs, neither of which actually work:
Those URL's don't work now, but certainly did in the past (I distinctly remember reading at least one of the pages there). Lemme see if I can find anything useful there; I'll report back if I do. Yes,
that web developer needs to be fired, if he/she wasn't already.
Apr 27 2017
Mar 29 2017
Viewing contributions through the API rather than the interface used to be a way to get around this bug; that is no longer the case.
Mar 22 2017
Cool. Could you also check to see if the bot has accidentally overwritten any other archive pages in this way? I've checked other pages about Australian Paralympians, where I've used the Pandora Archive often, but can't find any more examples.
Feb 8 2017
Feb 7 2017
Also, re the actual 2001 dump, I think it'd be best to only import edits when there is no or only a trivial gap in the page history between the last edit in those dumps and the first surviving one in the Wikipedia database.
I've already checked the so-called January 2002 dump ... It's just a UseModWiki version of the Nostalgia Wikipedia dump.
Oct 2 2016
I'm subscribed to this bug and don't get mentions, soooooo ... this one's really interesting: T147146
Jul 16 2016
May 25 2016
@TheDJ: Yes, you are correct.
Apr 23 2016
Now that I think about it, further examples might help. Both of these displayed correctly when I did them (2008/2009), but no longer do so.
Oops, sorry Cyberpower for removing you as a subscriber ... I was trying
to figure out how to subscribe *myself* and was having great difficulty
due to my screen reader. I finally managed it with Firefox ...
Feb 10 2016
The other problem is accessing the deleted edits themselves (that's impossible using the first link in my description). But maybe that's another bug.
Feb 9 2016
Feb 3 2016
Feb 2 2016
Nope. Screen readers don't follow the CSS rules that have been designed for them.
Which admittedly doesn't sound that bad *before* a reference ... but I could still do without it.
The zero-width joiner reads as a question mark for me in the latest versions of both JAWS and NVDA, which are among the most popular screen readers for Windows.
Dec 8 2015
The first option would probably be best. I've done it, I think.
Dec 6 2015
I got the necessary rights and ended up doing quite a lot with them, but there's still more to do:
Nov 18 2015
In the mobile version, the edit links are still read out when navigating by heading here.
Nov 17 2015
@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.
Oct 15 2015
Oct 11 2015
They became out-of-order because they were deleted before Wikipedia was upgraded to MediaWiki 1.5in June 2005. As a result, they lost their original revision ID numbers because they weren't saved when a revision was deleted back in those days. The bug summary isn't about imports ... it's about this entire situation in general, so I don't see the point of creating a new task for situations like the one I've just described (but you can if you want).
Not all of these problems are caused by imports; some are caused by out-of-order revision ID's, like this example:
Sep 12 2015
Yes, the truncated IP address contained two octets.
Aug 23 2015
Scott, thanks for adding me in. Yes, I created the 10.26 account to avoid impersonation, before T36873 was a thing.
Jul 9 2015
May 13 2015
I accidentally filled out this bug without submitting a description ... but on each page on the Nostalgia Wikipedia, there's an error message which begins: "Whoops! The default skin for your wiki, defined in $wgDefaultSkin as nostalgia, is not available."
May 11 2015
This bug causes an accessibility issue for screen reader users like myself, allbeit a minor one, because it makes it difficult to create HTML paragraphs that are semantically correct, as discussed at:
Apr 29 2015
Mar 25 2015
Unfortunately that character won't be supported by screen readers.
Mar 3 2015
I use JAWS 15 and IE11; I tried it on JAWS 16 (which I don't use normally for various reasons) and it had the same result.
The ARIA fix works in NVDA, the free Windows screen reader (under both Firefox and Internet Explorer). However it only works in Firefox with JAWS, the most popular screen reader. Firefox does interesting things with JAWS (e.g. it doesn't take into account personalised settings and it reads red links as blue), so I use JAWS with Internet Explorer.
Mar 2 2015
Yes, or either (a) remove it from the <h2> element or (b) imbed it into the heading title.
When viewing webpages, screen readers don't actually take into account what's on the screen ... instead they view the generated HTML through the browser's document object model to figure out how to display items in a way that makes sense for speech/braille users. Therefore, opacity has no effect on them.
Nope, because screen readers don't process opacity. I've tested it just to make 100% sure and it doesn't work.
Solution #3 sounds good in the short-term, if screen readers handle it OK (which I can test out). I'd also be happy to test fixes for T13555.
Mar 1 2015
If the actual section header were clickable, it wouldn't be a problem. It's just that adding an extra link to the eader would not be a good thing.
Oral CSS statements like that aren't supported by the major screen readers. And yes, it's possible for screen reader users to edit pages on Wikipedia, as I prove every day:
I found out about this change through the Tech News service. As a screen reader user, I object to it in the strongest terms. Users of screen readers navigate by headings, and adding a "section" link within the <h2> element will clutter the interface even more (compare T13555, about the edit link/s also being in the heading as read by screen readers). At
the page I created at: https://www.mediawiki.org/wiki/User:Graham87/sandbox
the headings are read out as ""Section Test 1 edit edit source" and "Section Test2 edit edit source". The extraneous text after the section name can be dealt with, but the text before it is far more disruptive, because screen reader users like to be able to cut off speech when they decide an item isn't interesting to them ... and adding redundant text *before* the item of interest (the heading name in this case) is most unhelpful.