See the comments including mine at: https://en.wikipedia.org/wiki/Wikipedia_talk:Linter#Wikipedia_Mobile_App:_Image_Recommendations_and_New_Lint_Error

As a screen reader user, I think this sounds really cool ... I'd never heard of this type of CAPTCHA before! Thanks for your work on this and putting up the demo. I'm scoring around 90 as well ...

Re previous comment: I didn't think that would work because of the 5,000-revision limit. And it doesn't ... I get a database error: [69c60177-c216-46bf-9221-09dde7012903] 2023-10-26 02:26:49: Fatal exception of type "Wikimedia\Rdbms\DBQueryError. There are way too many revisions there for even a steward to handle safely. Also see my above ramblings at T52031#555714, where this time I'll mention the revision move task in the modern format: T23312

I do history-merging on enwiki (though not as often as previously) and the main reason I don't use Special:MergeHistory (except in unusual cases) is the lack of annotation. I think it should be annotated like any other edit/admin action that affects a page (yes when done cleanly the history should still seem natural, but sometimes history merges hard/impossible to do cleanly).

I also got this while trying to move:
https://commons.wikimedia.org/wiki/File:Dandrieu_Fugue_AveMariStela.ogg

In T169452#9012321, @rook wrote:

In T169452#9012318, @Graham87 wrote:

I'm an irregular user of Quarry but find it very useful when I do need it. I found some major accessibility problems with Superset with both JAWS (my primary Windows screen reader) and NVDA, when I tried it with a query I'd just done on Quarry (I have no accessibility issues at all with my limited use of the latter program):
If someone could perhaps report these issues upstream in a more useful way than what I've just done, I'd appreciate it. Or at least help me to formulate more useful issue reports ...

These are important issues to report. Unfortunately I have no experience with JAWS or NVDA, you would be the much better person to report to superset, being able to describe your experience directly, and offer insight to any questions that may arise. Please do open an issue at https://github.com/apache/superset/issues

Fair enough, done ... after a bit more testing the settings menu item is a bit weird with screen readers too. Anyway here they are: https://github.com/apache/superset/issues/24687 and https://github.com/apache/superset/issues/24688

I'm an irregular user of Quarry but find it very useful when I do need it. I found some major accessibility problems with Superset with both JAWS (my primary Windows screen reader) and NVDA, when I tried it with a query I'd just done on Quarry (I have no accessibility issues at all with my limited use of the latter program):

• I can't figure out how to get from the homepage to the SQL Labs section with either screen reader. When I press enter on the SQL button/menu item/whatever it is, nothing seems to happen. I only managed to get there from the link at Wikitech. The settings button at least seems to work though.
• When the query results come up, the table seems to be some auto-scrolly thing that barely works in NVDA and almost doesn't work at all in JAWS.

Yeah I've thought something like this has been needed for a while. I'd been thinking of the idea of adding a log entry at the target as well as the source, and that wouldn't go astray either, but that would probably not be so easy ...

Yeah the transcript should be in the alt text in a case like this ... that's how I've encountered that sort of thing on Mastodon. Nah it didn't make me personally laugh but it'd be good for the transcript to be there for people who are amused by it. This is getting waaaaaay off-topic though ...

I'm not a heavy Phabricator user but I can't think of anything that needs to be fixed accessibility-wise these days. I use the latest version of JAWS for Windows as my screen reader under Chrome 113. I haven't tested it thoroughly though and I don't have any particular accessibility expertise beyond lived experience.

In T325796#8656198, @dom_walden wrote:

@Graham87 just checking you are OK with the change of wording.

Sure, sounds good.

This works fine now, probably thanks to T183489.

In T325796#8648310, @Nardog wrote:

Is it worth making the label customizable? So that more specific details could be provided when required? e.g.

<phonos file="intro.mp3" aria-label="Listen to the opening bars of the piece" />

Nah, probably not worth it. Most people won't customise what they can't see.

Indeed fixed in T167246.

In T325796#8636073, @dom_walden wrote:

@Graham87 What about the case when you have multiple IPA pronunciations on a page, for example for Australian vs. British English? Are people going to be able to distinguish them?

Yes, by the surrounding context.

As a screen reader user, I'd prefer "Listen to pronunciation" ... or something; much snappier.

Lightly paraphrased from my comment on the WikiProject Accessibility talk page: I've just had more of a play with this using the information above with JAWS and NVDA, the two most common Windows screen readers. In JAWS the button to get to the table of contents is called "Unlabelled button 0" and in NVDA it's read out as "Menu button". This is not exactly ideal.

At the moment I mostly check diffs by going in to the HTML source and searching for "diffch" ... which I've been doing for many years now. I'm generally alright with that, but of course it does fail horribly when line breaks are removed, etc. Recently more screen readers have better support for deletion/insertion annotation; when it comes to Windows screen readers, both JAWS and NVDA support reading them while NVDA supports moving between annotations. It could be nice to have some mode (enabled/disabled on the fly) that *only* shows the text that's changed and not the surrounding text.

We kinda do now with the del/ins markup which is now read by JAWS and NVDA ... and I've heard VoiceOver on iOS at least also indicates it. I mentioned this in T280749.

In both the demos, the label is read (i.e. for Special:Log) and the options are read once, as intended. I like demo 2B better because it's more stable when I fiddle around with it, doing things I probably wouldn't do in a real-life situation (e.g. going quickly in and out of forms/focus mode, tabbing in and out of the dropdown box, etc.) Even the demo of the old version couldn't really handle this kind of thing. I'm not sure what you mean by the additional label in the namespace selector.

Thanks very much! They do read now ... but JAWS reads the combo box items out twice (NVDA reads them out once). Also, in JAWS (but not NVDA), I was still able to get Chrome to become unresponsive by pressing enter on the import log item (as an example) in the new demo. It seems for some reason that presseng enter in JAWS in both the current and new versions (but not the old one) tries to set the state of the dropdown box to expanded, but it didn't do so in the old version.

No worries, these things happen. By "expand the combo box", I mean pressing enter on an option to select it, which causes the combo box state as reported by JAWS to change from collapsed to expanded. JAWS is notorious for hooking deep into Windows, so I can see it causing crashes like that (but they're still quite unusual for Chrome). I'll be happy to test things out when they're ready.

Update: JAWS has re-added the reading out of del/ins semantic markup as a togglable feature ... it defaults to being on (I used the Wayback Machine to link to the announcement as this isn't a stable URL). Now that it can be turned on and off, I imagine this feature will stay around for the long term.

Indeed, the tooltip wouldn't be helpful for screen reader users. I'm OK with the lack of tooltip in Vector2022 as it is (I just tested it).

Re previous comment: yeah that's pretty much it. I imagine a lot of sighted users won't like the new headings or will be freaked out by them, at least temporarily ... they're not that useful on a page that only occasionally gets edits. Ifor one am slightly warming to the feature but still not really *enjoying* it ...

Re the substance of your previous comment: thanks very much. Just because I'm like that, I feel the need to point out this much more accessible way into the comic: https://www.explainxkcd.com/wiki/index.php/1172:_Workflow ... lol!

In T298638#7738280, @Tacsipacsi wrote:

Special:WhatLinksHere shows “Displayed 50 items.” at the top (it was done in T44357). Would that work for you (potentially visually hidden)?

Oops, missed this question. It'd work but wouldn't be optimal because it wouldn't be as convenient as it was before. In the past I could just press "l" one or two times to move between lists and get "list of 50 items" or whatever. I guess the notice could be made into a heading/list item/something but that's markup abuse as well.

In T298638#7737721, @matmarex wrote:

@Graham87 Thank you for commenting. I'm filling in for @Jdlrobson on these changes (he's currently on vacation).

I've proposed patches for the issues you noted, that is:

• Reveal the headers to screen-readers to make it more clear that there are multiple lists
  • [also requested by @stjn in T298638#7712126]
• Group the edits by date in the user's timezone
• Add a <section> wrappers around the lists to make it easier to jump to the end (at least, I hope this helps, I'm only an amateur screen reader user – if it doesn't, then we should think about other approaches)
  • [also requested by @Nardog in T298638#7726770]
  • [this should also make it easier to write the gadgets to number these lists, as discussed by @Tacsipacsi and @Nardog in T298638#7731808 and below]

...

Also, the headings seem to be based on the UTC date and don't take into account time zone preferences (unlike the watchlist, at least), which makes things even more confusing. On a 8 time zone preference this page history is just plain weird: https://en.wikipedia.org/w/index.php?title=Kenneth_and_Mamie_Clark&dir=prev&offset=20210125151819|1002670209&action=history

In T298638#7712126, @stjn wrote:

b) If desktop skins will hide these headings completely, screen reader users would lose all the information as to why there is a dozen of separate lists on the page, as opposed to just one like before. This should probably be done with visual hiding instead, though I am not sure.

FWIW I've just discovered that this bug was fixed by the resolution of T183489.

I'm not marking this as resolved because I don't know whether this is really considered a problem as such ... but all revisions from before the MediaWiki 1.5 upgrade (in June 2005) in all formerly Latin1 wikis, including English and French, will be encoded in Latin1 unless they've been deleted and re-deleted since the upgrade. That's exactly what the option $wgLegacyEncoding is for. See: https://www.mediawiki.org/wiki/Manual:$wgLegacyEncoding

Marking as resolved, because the links appear to do what they're supposed to now. Also I undeleted the old revisions of the page Meat helmet which previously didn't have revision ID's and exported them to find out that their revision ID's were 834623930 and 834984315 (which indicates that the ID's were assigned around April 2018), a while after I reported this bug. Some process obviously went through and fixed the orphaned revision ID's. This bug is now fixed as far as I'm concerned.

Looking at this a bit further, it seems the revisions are simply listed in ascending order rather than descending. It also only happens when dir=prev is selected ... compare https://nostalgia.wikipedia.org/w/index.php?title=Tattoo&action=history this normal history link with this one with dir=prev.

I'm not in the right position to directly answer that (cf other skins ... and the fact that Monobook's property of exposing all the controls at once by default is very handy for screen-reader-using editors like me), but I can confirm that the notifications would appear on top with all screen readers when using vector on test.wikipedia.

I just found a particularly blatant example of a common username in the 2001 dump being later taken by a completely different user ... a good reason to be careful here! https://en.wikipedia.org/wiki/User:Aboyd_(2001_editor)

Yeah, it is perhaps a screen reader problem. I think in JAWS the option to read inserted/deleted text is only available in Google Docs.

In T20493#6030042, @daniel wrote:

History splits in particular should be rare - ideally, they would really just consist of undoing a previous history merge (or import - importing can result in a history merge). Am I right about this? Is there any other situation where a history split is needed?

It obviously hasn't ... the problem still occurred here:
https://www.wikidata.org/w/index.php?title=Q615468&diff=prev&oldid=1081872742

Has this bug been fixed (or almost fixed) recently as a side effect of something else? I've done several history merges involving deleting and restoring pages (e.g. "lorazepam" (Q408265) and fresh water (Q102192)) and haven't noticed this problem lately.

I'm a screen reader user who commented waaaaaay above. If a link *had* to be added, adding it after the "edit" link would be best. However screen readers will generally read the link text, not the title, unless instructed otherwise, so they'd here, for example, "Early life edit share". I for one think an edit link is relatively straightforward, but a share link would be confusing ... the average user would be thinking "share what? With whom? How? The same would apply to a lesser extent with "Share this section", but that's more words. I don't know about anybody else, but I would use this rarely enough that I would disable it immediately if it was ever enabled by default on Wikimedia wikis.

Wow, makes sense. Pretty weird though.

Is this bug in the process of being fixed, or has some script been run that has fixing this bug as a side effect? See "Usernames_underlined_or_with_lowercase_letters" at User talk:Graham87/Import. The edits display with the correct username but aren't in special:contributions for that username yet .... this can most easily be demonstrated by this diff, with an edit from 17 January 2002 (UTC), and this contribs page, which is set to display edits from 25 January 2002 or earlier but whose latest edit is from 6 January 2002 (UTC).

In T20493#5384301, @Krinkle wrote:

One of the open questions here is whether we need the ability for revisions to be entirely omitted from the history page pagination (which is currently possible by deleting the whole page and selectively undeleting all-but-one revision). My "Proposal 1" currently suggests that we do keep this ability, and that it would become one of the options of "Revision delete" - just like how we have several options already about visibility of user name, timestamp and content. Another could be to omit the entry entirely. For the user-interface, this could look like a checkbox on "Special:RevisionDelete", or it could look like "Special:Undelete" - that's a separate question.

*While I display some reluctance in that matter insofar as it applies to HomePage (which contains Wikipedia's first ever edit), I'm overall neutral as to whether holding off of creating such gaps is beneficial. Perhaps I can make a list of such pages if it would be of use.

I've just done the Homepage import. I've got my own list of pages to import; if you want to create your own, go ahead.

In T155014#5371668, @John_M_Wolfson wrote:

I just created a Wikipedia page on this topic (https://en.wikipedia.org/wiki/Wikipedia:Starling_archive_imports) and was just about to bring it somewhere when I stumbled upon this task.

From what I've seen, a good number of these pages have uncomplicated histories with single-digit numbers of missing revisions, so they can be imported by hand (by directly modifying the XML file with the new revisions and re-importing it if I'm not mistaken). On the other hand, there are some pages such as HomePage, with 418 missing revisions, that should most probably be imported with some sort of script or bot. (I know I'm saying that like it's something easy.)

It's just the links; I've marked them as dead explicitly.

A more serious omission from the dump is edits to "The Most Remarkable Formula In The World" ... the dump only has history upto the end of March 2001 but the Nostalgia Wikipedia has many other edits from July.

I've never used this system because I don't have a Braille display; they're frightfully expensive (though there are projects underway to change that) and as far as I understand they're most readily available in Western Europe, though it's possible (but sometimes difficult) to get them in the US/UK/Australia/New Zealand through rehabilitation grants (which I'm planning to do in the medium/long-term, partially so I can use Braille music digitally). BRF files are just text files that use Braille ASCII and I can, rather laboriously, interpret them through speech, so there shouldn't be a problem supporting them on Commons.

I recently noticed this problem at:
https://en.wikipedia.org/w/index.php?title=AD_42&limit=1&dir=prev&action=history

Nope, the access keys are working fine here now.

Yes, it would.

at https://en.wikipedia.org/wiki/Special:Contributions/Graham87 ... there is a line break between the <span class="comment comment--without-parentheses"> ... tag and the "<span class="mw-uctop">current</span> ..." tag, but not a space character; adding one would fix this problem. On some further testing with JAWS and NVVDA, the two most popular Windos screen readers, it only occurs in the former program, and only under the default scheme where everything is virtualised so it's easier to read, but the layout is flattened.

I appreciate the return of the list items back to the way they were, but now there is no space between the edit summary and the word "current" (where it appears), so for example my screen reader now reads one of my latest edit summaries as "wikilinkcurrent", which sounds like "wikilinkerant". Most screen readers do not distinguish text attributes unless told to do so.

I thought in your second example you were removing the HTML list entirely ... that's why I commented the way I did. If that wasn't your intention, then yes, that would be better than what is now on the English Wikipedia (i.e. with the inner lists).

I would much prefer the outer list (i.e. the <ul> containing, say, a list of 50 items, one per each edit) to be preserved. The inner uls for the diff/hist links can be spans; that'd be fine. If that configuration is not possible, I'd much prefer it the way it is now on the English Wikipedia rather than with no HTML lists at all.

I'm a screen reader user, and I don't like the fact that the diff/hist items are now in their own nested HTML lists on the English Wikipedia ... it just creates clutter and actually makes it slightly *harder* to navigate the contribs list with a screen reader, because now I hear "list of 2 items nesting level 1" and "list end nesting level 1" for no good reason. I use JAWS 2018 with IE11 but a friend of mine who uses NVDA/VoiceOver with Safari/Firefox also agreed that the new nested lists weren't a good idea. ?Semantic HTML lists are all well and good but when they're just lists of two items with no discernible benefit, there's no point.

However the dump doesn't contain all the edits to C. Northcote Parkinson ... rc.log contains four here while the dump only contains two. Hmmm ...

Left and right arrowing doesn't work that well with screen readers anyway because the key is overwritten by the screen reader (especially true for JAWS). I would think most screen reader users would just navigate around the page using their virtual cursor and press enter on the relevant tab.

Yes, that's correct. I could ignore it at all costs if it was added, but I still see it as completely counterintuitive to have different behaviour when links are tabbed to versus when they are cursored over with the virtual cursor. I'd think beginners would be more likely to try to tab over links too.

I've imported a few pages, including the page n admins an the one on Atlas Shrugged.

In T179832#4493953, @Battaglia01 wrote:

I sometimes get inconsistent behavior with this when importing users that do not exist, particularly as it pertains to user contributions. This is both for importDump.php and Special:Import. I am using Mediawiki 1.31

At times it automatically puts the "prefix>user" before the username. In the revision list, the resulting username is just ordinary text and not a clickable link. No user contributions are given to the nonexistent user. rev_user is 0 in the database.

Other times it doesn't do that and I just get a clickable link to "user". This link is clickable, it's blue rather than red for a non-existent user, and I am brought to the user contributions page for this user. There is no interwiki prefix. rev_user is still 0 in the database.

How this work is somewhat mysterious and I haven't been able to figure out why. Usernames that start with a capital letter tend to go to "prefix>username", whereas usernames that are all lowercase letters become just the clickable "username". Occasionally there is a counterexample to that rule. It's pretty bizarre.

In Special:Import, if I click "Assign edits to local users where the named user exists locally", it makes no difference to this behavior. Whatever I type for my interwiki prefix, it is only randomly assigned to some users in the manner mentioned above. The same happens if I use importDump.php, but since I do not get to choose a prefix, the prefix it choses is "imported>username".

Is there some way to make this consistent? I am importing another wiki and expecting users to re-sign up afterward. I don't care whether they automatically get their old contributions back when they do, or whether they are all imported as a disconnected "imported>user" prefix, but I would at least like for it to be consistent. Can I change something in the XML to make this work?

After replacing all instances where the title was "Vector_Space]" with "Vector_Space1", the XML file imported perfectly here!

The import script seems to halt on the title "Vector space]" or somewhere around there, using the filtered XML dump. So it's not working quite yet.

Oh I see now from the source code for importUseModWikipedia.php: the account UseModWiki admin needs to exist first.

I would be planning to work with them, but I get the following error using importDump.php to import them under MW1.25 (old, I know, but I don't think an update would fix this):
A database query error has occurred.
Query: INSERT INTO logging (log_id,log_type,log_action,log_timestamp,log_user,log_namespace,log_title,log_comment,log_params) VALUES (NULL,'move','move','20010322014545',NULL,'0','PythagoreanTheorem','','Pythagorean_Theorem\n1')
Function: WikiRevision::importLogItem
Error: 1048 Column 'log_user' cannot be null (localhost)

I only found out by accident, but appears XML versions of these dumps were put up on dumps.wikimedia.org last October ...
https://dumps.wikimedia.org/archive/2001-xml/

Naaaaah, I'm not a fan of this at all. On Windows, at least (with both NVDA and JAWS), it only works in FF, not IE (which many screen readers still use). It also doesn't work with these screen reader's accessibility cursors and only works when tabbing over the links, which screen reader users would never do. When it does work I don't like it ... it's just way too verbose and I just want to cut it off.

In T199210#4411589, @Aklapper wrote:

Please always include the actual error message in bug reports. Thanks!

In T196190#4266647, @Isarra wrote:

You don't actually benefit any from the responsive mode being any different, do you? Would it make sense for it to effectively remain the same as before the change, to screen readers?

I can't get the elements to be hidden on the beta labs cluster. However on Wikipedia it seems to have returned again with the same problems.

I would test it but that cluster's been down for an hour now ...