Thu, Oct 12
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.