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.

In T126319#2011478, @Krenair wrote:

Do you think those WP: entries (select count(*) from logging where log_title like 'WP:%'; returns 2022 on the labs replicas) should be edited to point to the Wikipedia namespace?

In T125480#1990627, @Fomafix wrote:

I tested with Claws. It does not output any CSS generated content like

sup.reference:before {
	content: "Foo";
}

Does your screen reader include such CSS generated content?

Nope.

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.

The first option would probably be best. I've done it, I think.

I got the necessary rights and ended up doing quite a lot with them, but there's still more to do:
https://en.wikipedia.org/wiki/User:Graham87/Page_history_observations
https://en.wikipedia.org/wiki/User:Graham87/SHA-1

In the mobile version, the edit links are still read out when navigating by heading here.

In T13555#1812616, @GOIII wrote:

Javascript trick? Even when I'm not logged in, the edit link is ~1em to the right of the section heading. Its been some time since the Edit link loaded at the far right of the section heading (unless there some difference in the skin being used or something.

Anyway if you can double check that javascript thing and re-check the test page from earlier once again (I tweaked it some more), I'll stop pestering you and go dig up a screen reader of my own to look into this aspect on my own.

Thanks again

In T13555#1809839, @GOIII wrote:

That said.. what is currently your experience with headings and screen-readers?

It sounds like the current state of affairs for you is indeed "reading out" all the "text" being "detected" but for some reason you are unable to actually invoke an edit session as you once were able to prior to the ~2007 change?

Oops, I missed this comment until now. The English and German Wikipedias (and perhaps others?) use a JavaScript trick to put the edit link *after* the section name, so when I navigate by heading I hear "<heading name> edit". I can access the section editing link fine; it's just annoying to hear the word "edit" after each section name.

@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.

In T13555#1809538, @GOIII wrote:

My first question even before bringing up the possible redesigning of the section and edit link generation scheme is if anybody has simply tried to use css/media rules to prevent the "reading" of the unwanted Edit term instead?

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:
https://en.wikipedia.org/w/index.php?title=Talk:Netherlands&dir=prev&action=history

Yes, the truncated IP address contained two octets.

Scott, thanks for adding me in. Yes, I created the 10.26 account to avoid impersonation, before T36873 was a thing.

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."

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:

Unfortunately that character won't be supported by screen readers.

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.

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.

In T18691#1076536, @Fomafix wrote:

@Graham87 Would

.mw-headline-anchor:focus {
	opacity: 1;
}

solve this?

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.

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.

In T18691#1076407, @Ciencia_Al_Poder wrote:

Since it should be interesting for screen readers (which may be different from the edit section link, if people using screen readers are even able to edit pages), we could add .mw-headline-anchor { speak:none; } to CSS and prevent screen readers from reading it.

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:
https://en.wikipedia.org/wiki/User:Graham87

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.