- User Since
- Oct 12 2014, 11:29 AM (451 w, 3 d)
- LDAP User
- MediaWiki User
- Graham87 [ Global Accounts ]
Wed, May 24
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.
Mar 1 2023
Sure, sounds good.
Feb 27 2023
This works fine now, probably thanks to T183489.
Nah, probably not worth it. Most people won't customise what they can't see.
Feb 25 2023
Indeed fixed in T167246.
Feb 22 2023
Yes, by the surrounding context.
Feb 21 2023
As a screen reader user, I'd prefer "Listen to pronunciation" ... or something; much snappier.
Feb 1 2023
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.
Jan 13 2023
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.
Nov 30 2022
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.
Aug 12 2022
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.
Aug 11 2022
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.
Aug 9 2022
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.
Aug 7 2022
Jul 25 2022
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.
May 25 2022
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).
Mar 4 2022
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 ...
Mar 2 2022
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!
Feb 27 2022
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.
Feb 25 2022
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%7C1002670209&action=history
Jan 29 2022
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.
Oct 8 2021
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.
Aug 7 2021
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.
May 17 2021
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)
Apr 29 2021
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.
Jul 24 2020
Apr 5 2020
Apr 4 2020
Dec 23 2019
It obviously hasn't ... the problem still occurred here:
Dec 15 2019
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.
Oct 5 2019
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.
Aug 20 2019
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).
Aug 1 2019
Jul 30 2019
*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.
Jul 29 2019
Jul 27 2019
It's just the links; I've marked them as dead explicitly.
Jun 25 2019
Mar 23 2019
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.
Feb 7 2019
Jan 20 2019
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.
Jan 10 2019
I recently noticed this problem at:
Nope, the access keys are working fine here now.
Nov 30 2018
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.
Nov 11 2018
Nov 9 2018
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.
Oct 21 2018
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 ...
Sep 20 2018
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.
Sep 1 2018
Aug 22 2018
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.
Aug 10 2018
I've imported a few pages, including the page n admins an the one on Atlas Shrugged.
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')
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 ...
Aug 4 2018
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.
Jul 31 2018
Jul 10 2018
Jun 9 2018
Jun 8 2018
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.
Jun 7 2018
I would test it but that cluster's been down for an hour now ...
Jun 2 2018
I've changed the title to clarify exactly when the access keys aren't working, per the comments I just made about this issue at the village pump discussion. On the prototype, I can reproduce this issue in both JAWS and NVDA, the two most popular Windows screen readers, in both IE and Firefox (using the latest stable versions of all these programs)
May 27 2018
May 1 2018
Apr 27 2018
Wouldn't solutions 2/3 make it effectively impossible to do selective deletion/undeletion, since most revisions that aren't the first in the page history have a non-0 rev_parent_id? A major reason to do that these days is for history splits ... another reason to make a Special:HistSplit page yesterday/redo the rev_parent_id system altogether.
Apr 19 2018
The Special:SplitHistory idea sounds like revision move (T23312), which would be really really cool.
Apr 14 2018
IIRC it used to not even try to display the length in such cases, but it now displays it as empty. I can't think of any other examples of cases like this at the moment though.
Apr 5 2018
I know this bug is old and resolved, but I stumbled on it by accident while looking for something else ... for future reference, refreshing the page in your browser should restart the deletion, and doing that enough times should make it go through. I know that undeletions for history merges work that way.
Mar 14 2018
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.
Mar 6 2018
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.