In T298638#7731808, @Tacsipacsi wrote:

It’ll break https://hu.wikipedia.org/wiki/MediaWiki:Gadget-listNumbers.css, and I don’t really have an idea how to fix it. The idea behind this gadget is to make the special page lists enumerated instead of bullet-point so that one can see how many items it has simply by looking at the last number. As there are now several lists, all start from one, so the whole enumerating doesn’t make much sense (except when the user makes many edits a day and thus only a few dates are visible at once).

mediawiki.org (wmf.23)	huwiki (wmf.22)

Does anyone have an idea how this gadget could continue to work as expected?

You can use counter-reset / counter-increment CSS.
e.g.

body {
  counter-reset: list-number;
}

#bodyContent ul {
    list-style: none;
}

 
#bodyContent li {
  counter-increment: list-number;
}

#bodyContent li:before {
  content: counter(list-number) '. ';
}

Test Result - Beta

Status: In Progress
Environment: beta
OS: macOS Monterey
Browser: Chrome
Device: MBP
Emulated Device:NA

Test Artifact(s):

QA Steps

@Jdlrobson, As far as visual changes I've captured screenshots where I could. I have not completed the CSS testing as I am uncertain if the CSS is correct. I will reach out directly.

AC1: On desktop / mobile, I shouldn't see any visual changes between production and beta cluster for the pages listed below.

Page	Beta-Desktop	Prod-Desktop	Beta-Mobile	Prod-Mobile
✅ Special:NewFiles
⬜ Special:DeletedContributions Not enough permissions to compare to prod.		No Permissions		No Permissions
❓ Special:Contributions //It looks like the margins in prod are smaller. The user menu icon is much further to the right./
✅ Special:NewPages
❓ Special:MergeHistory		No Permissions		No Permissions
✅ Special:Log
✅ Spain?action=history

In T298638#7732543, @Jdlrobson wrote:

You can use counter-reset / counter-increment CSS.
e.g.

body {
  counter-reset: list-number;
}

#bodyContent ul {
    list-style: none;
}

 
#bodyContent li {
  counter-increment: list-number;
}

#bodyContent li:before {
  content: counter(list-number) '. ';
}

That would give common serial numbers to all <ul> elements on the page, including sublists of WhatLinksHere, and wrapped lines in a bullet would begin at the same horizontal axis as the number. Targeting the contribs list specifically and using ::marker rather than ::before would avoid these problems (lesser browser support notwithstanding).

That would give common serial numbers to all <ul> elements on the page,

My intention was to demonstrate how, not solve the issue for you :-) I've not tested this out, but yes of course you'd need to scope the CSS selectors to the lists you care about.

Test Result - Beta

Status: In Progress
Environment: beta
OS: macOS Monterey
Browser: Chrome
Device: MBP
Emulated Device:NA

Test Artifact(s):

QA Steps

@ovasileva I modified my css and I still don't see any difference in beta for these three pages with or without css in beta.

❓ AC2: If I edit my user CSS e.g. User:<your username>/common.css .mw-changeslist-time, .mw-index-pager-list-header { display: !important; } all edits on the Special:Contributions, Special:MergeHistory and history page should be separated by date.

Page	Beta-Desktop with CSS	Beta-Desktop no CSS
Special:Contributions
Special:MergeHistory
Spain?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.

Yeah as a screen reader user, I really, really, really don't like this at all for that exact reason. When I first noticed this on Wikidata, I thought the page history was only displaying two edits at a time and I thought there was an "Unbreak now!" issue with history retrieval or something. It's only now that I've noticed this on Wikipedia that I've realised that this change is very much intentional. Not only are small HTML lists like this a pain to navigate with a screen reader, this change also ruins my workflow of getting to the end of a page's history by navigating to the end of what used to be a list of 50 items. I also question the wisdom of adding date headings to the history page in the first place ... on the vast majority of pages, there are only one or two edits a day, as opposed to the much higher rate of edits on both RecentChanges and the watchlist. I'd appreciate it if this particular change to the HTML could be seriously reconsidered.

The impacted pages in the QA section should be a single list (<ul>...</u>), not many lists split by date.

If mobile needs to split by date for reasons not enumerated here, then please find a different way to do it other than splitting the lists on desktop.

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

Fixed invalid CSS in the description (h/t Izno). I don't know why .mw-changeslist-time was included (outside the backticks no less) when times are already visible.

Change 766097 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] Add <section> wrappers around pagers grouped by date

https://gerrit.wikimedia.org/r/766097

Change 766098 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] ReverseChronologicalPager: Group by dates in the user's timezone

https://gerrit.wikimedia.org/r/766098

Change 766099 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] Show pager date headers to screen-readers

https://gerrit.wikimedia.org/r/766099

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

If you have a moment, you can try these fixes out on a demo wiki I just created. I imported the recent history of the page "Kenneth and Mamie Clark" here: https://patchdemo.wmflabs.org/wikis/962b298fe3/w/index.php?title=Kenneth_and_Mamie_Clark&action=history

Please also say if anything else should be changed. I'll make sure that next week, either those changes are deployed (if you confirm that they are helpful), or that the original change is reverted and I'll ask the team to consider other options.

In T298638#7736860, @Edtadros wrote:

QA Steps

@ovasileva I modified my css and I still don't see any difference in beta for these three pages with or without css in beta.

❓ AC2: If I edit my user CSS e.g. User:<your username>/common.css .mw-changeslist-time, .mw-index-pager-list-header { display: !important; } all edits on the Special:Contributions, Special:MergeHistory and history page should be separated by date.

There's a mistake in that CSS. I think the correct CSS should be:

.mw-index-pager-list-header { display: block !important; }

Updated the global search query for $( 'ul.mw-contributions-list' ) in the description, seems there isn't "0 impacted scripts" anymore.

@matmarex - thanks for taking over! Just tested the patchdemo and it looks ok to me. From the team's perspective, we've okay with reverting if any additional significant changes occur.

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]

...

Thanks very much for the help; I tested them out (even creating an account to test out the time-zone thing). The first two worked fine; it took me a while to figure out how to use the section wrapper ... I had to use the HTML source to figure out it was a div and then I realised I could press z to navigate past it. There is also a problem that the last item in the page history seems to be a list item by itself, not attached to any date.

Having said all that, I'd honestly much prefer it if the original change was reverted for now. The fixes reduce it from a 9 out of 10 annoyance factor to about 6 out of 10 for me; I use the history/contributions pages all the time and the new layout makes it more difficult to figure out basic things like the number of edits listed on a page, etc. (I know sighted users have problems getting exact numbers, but at least they can quickly look down the screen to make a rough estimate, and can always tell whether there are, say, 5 or 45 edits in a list). I don't think it's particularly fair to expect screen reader users to have to change their workflows when almost no other desktop users are affected by this change.

In T298638#7737721, @matmarex wrote:

• 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)
  • [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]

So I can expect that lists that are children (and not deeper ancestors) of section.mw-pager-body, and only those lists, use this new structure? Thanks, that makes things a lot easier!

In T298638#7737872, @Graham87 wrote:

[…] the new layout makes it more difficult to figure out basic things like the number of edits listed on a page, etc.

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

Change 766160 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] HistoryPager: Refactor to avoid special handling for the last row

https://gerrit.wikimedia.org/r/766160

In T298638#7737790, @matej_suchanek wrote:

Updated the global search query for $( 'ul.mw-contributions-list' ) in the description, seems there isn't "0 impacted scripts" anymore.

3 scripts are not found there, but are also affected (or better: one for sure, two others I assume).

I use de:Benutzer:Schnark/js/topcontrib.js and noticed it did not work reliably anymore. (Schnark once was very active on updating his scripts, but is unfortunately inactive for more than a year now.) Since this is a fork of en:User:Ais523/topcontrib.js which has at least another fork in en:User:Venkat TL/ColourContrib.js I assume also these two do not work anymore.

Because these scripts do expect a single list I would be happy if the change could be reverted, so following @Graham87. I know, my reasons are not as valid as his, though. Or someone could write an adjusted version.

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)?

But this is a totally other thing and not good for a fast overview. The total number of edits can be found on every page information page, but this is one of many other items on this page.

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#7737789, @Ammarpad wrote:

In T298638#7736860, @Edtadros wrote:

QA Steps

@ovasileva I modified my css and I still don't see any difference in beta for these three pages with or without css in beta.

❓ AC2: If I edit my user CSS e.g. User:<your username>/common.css .mw-changeslist-time, .mw-index-pager-list-header { display: !important; } all edits on the Special:Contributions, Special:MergeHistory and history page should be separated by date.

There's a mistake in that CSS. I think the correct CSS should be:

.mw-index-pager-list-header { display: block !important; }

Thanks @Ammarpad , I will try that and update my screenshots.

Change 766097 merged by jenkins-bot:

[mediawiki/core@master] Add <section> wrappers around pagers grouped by date

https://gerrit.wikimedia.org/r/766097

Change 766098 merged by jenkins-bot:

[mediawiki/core@master] ReverseChronologicalPager: Group by dates in the user's timezone

https://gerrit.wikimedia.org/r/766098

Change 766099 merged by jenkins-bot:

[mediawiki/core@master] Show pager date headers to screen-readers

https://gerrit.wikimedia.org/r/766099

hi @brennen -- afaict all the patches related to this ticket have been merged with the exception of https://gerrit.wikimedia.org/r/c/mediawiki/core/+/766160/ which is still waiting for review - @matmarex is that patch a blocker?

I think it doesn't block wmf.24, although I'd like us to backport a fix this week. I guess I'll move this to next week's blockers.

I think it doesn't block wmf.24, although I'd like us to backport a fix this week. I guess I'll move this to next week's blockers.

Thanks @cjming, @matmarex.

This should not have been rolled out without discussion of accessibility, especially since breaking up an HTML list is a classic a11y concern. It should be reverted until an accessible version can be rolled out, rather than left in production while a fix is worked on. I don't think we'd be okay with a comparably aggrevating change (based on what @Graham87 has said) staying in prod if it had comparably disruptive changes for non–screenreader users. If that accessible version can also not break list numbering (a tool I find invaluable in my workflow on-wiki... and yes, yes, https://xkcd.com/1172/, I know), that would be a great added benefit, but my primary concern is a11y.

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!

Hello, I'm back. Firstly I want to apologize wholeheartedly for the disruption to your workflows. In this case, I underestimated the impact on screen reader users and for that I apologize. I will learn from this experience. Thank you @Graham87 for taking the time to raise this issue and for @matmarex for taking care of this problem in my absence.

Just to make sure I have understood what the problem was here: The problem was not the fact that there were multiple lists, but the fact that these lists lacked headings? The reason I ask is that the RecentChanges and Watchlist pages have multiple lists with headings, so am I correct in understanding they do not have this problem? We plan to show these headings to non-screen readers as well but my understanding is when we do that, this wont cause further disruption.

These headings should now be visible on all projects to screen readers, so I think this issue should now be resolved. Please let me know if more follow up work is needed.

The problems were / are:

• The list of edits was split by date, but the date headers were hidden from screen readers, making it impossible to understand why the change occurred
  • fixed by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/766099
• The grouping by date did not consider the user's timezone, so the grouped items were not obviously related
  • fixed by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/766098
• The grouping makes it more difficult to navigate the whole list
  • improved by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/766097, but it's not clear whether the current state is good enough
• The last entry on the history page is in a list on its own, regardless of date grouping
  • not fixed yet, patch pending review: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/766160

(Corrections welcome if I misunderstood)

I think the two fixes downgraded this problem from unbreak-now, and that's why I didn't revert the changes. I hope we resolve the rest soon.

To elaborate a little on "The grouping makes it more difficult to navigate the whole list":

(summary based on my understanding of comments from @Graham87, and also IRC conversation with @Tamzin)

Previously, screen readers reported a single list containing e.g. 50 items; now they report multiple lists, often (for infrequently edited pages) each one of them containing just one item. This is different from the watchlist or recent changes, where you'll usually find long lists under each date. This makes it more difficult to judge the state of the history at a glance. Perhaps it could be improved by adding a summary at the top, like "Displaying 37 edits" (I think also many sighted users would find this helpful, judging by the existence of many gadgets for making the list numbered, but I'm not sure how convenient it would be for screen reader software).

When navigating through the history, you now need multiple keystrokes to move from one list, over the heading, and into the next list. I'm not sure whether this makes the experience worse or just different.

Prior to the partial fix, you also needed multiple keystrokes to go to the beginning/end of the grouped lists, and access the navigation links. I hope that after the patch that added section wrappers containing all of the lists, this is just as easy as before (although it's a different navigation action).

All in all, the current experience would probably be acceptable if this was a new feature, but it is different than it was before, and it is arguably worse than before.

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

Is there no way to add a setting for reverting this change in Special:Contributions or at least for an according script or scriptlet, so that user scripts can work, again (so that there is again one ul element per page)? I actually do not see a benefit of date headers on this page.

@Speravir we're not reverting this change. It's been requested by mobile users. If you are having problems with user scripts, please ping me on wiki at User:Jdlrobson, to tell me which scripts you are having problems with and I'll happily help get them fixed for you.

we're not reverting this change. It's been requested by mobile users.

You should. A mobile feature request doesn't mean it should negatively impact desktop users. Dates are a meaningless separator when reviewing a page history (as an example).

In T298638#7754438, @Jdlrobson wrote:

we're not reverting this change. It's been requested by mobile users.

I didn't speak of mobile front end and I did not request a total revert. English is not my natural language, with “reverting” I meant some kind of setting which resets to the old behaviour with one huge list per page, i.e. one ul element in html output without breaks inside. Or a clue for user script writers, how to update their scripts (difficult when they aren’t active anymore).

Anyway, I meanwhile noticed, that the user script I use and mentioned above in T298638#7739798 started working again, and got aware of your edit. So, thank you for that. Interesting that the necessary change is that simple (nethertheless I wouldn’t have been able to do this).

In general though, similar to @JJMC89 I do not get it why a change for mobile front end has to have consequences for desktop front end.

In T298638#7754488, @JJMC89 wrote:

we're not reverting this change. It's been requested by mobile users.

You should. A mobile feature request doesn't mean it should negatively impact desktop users. Dates are a meaningless separator when reviewing a page history (as an example).

@JJMC89 - are you seeing any visual changes to desktop? The work in this task should not result in any changes to the desktop interface.

It is about the HTML changes (T298638#7736887) and the intention to show the headings in the future.

We plan to show these headings to non-screen readers as well but my understanding is when we do that, this wont cause further disruption.

and the intention to show the headings in the future.

We plan to show them on mobile only (at least for now) so this would not negatively impact desktop users: T301798.

I do not get it why a change for mobile front end has to have consequences for desktop front end.

The desktop and mobile site share the same content (HTML), they are just styled differently in the same way Monobook looks different from Vector. On mobile, we heard from users when we removed some unmaintained code from our stack, that the headers were helpful. In Vector we are hiding them to retain the old look and feel,

So, thank you for that. Interesting that the necessary change is that simple (nethertheless I wouldn’t have been able to do this)

Glad that helped. I understand a lot of important/useful gadgets/scripts have lost maintainers, and I am more than happy to help fix those as I believe the underlying technical change here we've made is important for the long-term health of the project.

If you see any other broken gadgets, please feel free to share links and I'll help fix them.

UPDATE: I've opened T303210 to capture the remaining work so that there's a clear request from the platform team for their time.

We plan to show these headings to non-screen readers as well

Which ticket should we watch for updates on these plans?