For the record, ‘behaviour without JavaScript’ and ‘behaviour for screen readers’ are two different things. Screen readers have access to JavaScript and various features should be accessible to them with JavaScript enabled. It is not good to expect readers of Wikipedia to disable JavaScript to be able to use the website correctly. Since this is a script doing an animation of a chess board, it should have accessible buttons and the interface should announce the changes of movement to a screen-reader user, presumably via an element with attribute aria-live="polite".

I don’t have an opinion on mobile behaviour, I presume the mobile team would (theoretically you could even lazyload the chess board on mobile to appease the gods of performance).

Change 715603 had a related patch set uploaded (by TheDJ; author: TheDJ):

[mediawiki/extensions/ChessBrowser@master] Improve CSS and JS loading of ChessBrowser

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

• The RL modules need to be spec'ed as being compatible with mobile in order for them to work on mobile
• The buttons need to become actual buttons
• The buttons need to be not just image buttons
• The notation might possible have to be indicated as buttons...
• The play state change should probably be announced via aria-live... (though I'm not sure if PGN notation in screenreaders can be easily understood, I'll give it a try).

Change 715603 merged by jenkins-bot:

[mediawiki/extensions/ChessBrowser@master] Improve CSS and JS loading of ChessBrowser

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

Current state.

Without JS

• we show the game details table expanded
• we show the marked up PGN
• we show a JS is not enabled message

In print:

• we show the game details table expanded (toggle hidden)
• we show the marked up PGN
• we show the playboard in the selected state
• we hide the playboard controls

Keyboard control:

• The PGN selection is not keyboard controllable yet
• The playboard controls are not keyboard controllable yet

Screenreaders:

• The PGN script is read
• We might want to improve the indication of the steps.
• The controls are somewhat accessible in VO (but better with keyboard control implemented)
• The playboard announces the legend, but without a sensible order and it ignores the pieces (turn whole thing into a table?)
• The playboard controls are ignored

Mobile:

• the RL modules are not added as they are not marked as mobile compatible but we can probably easily do so
• The playboard controls might not find on smaller screens in the available width and drop to two lines ?
• The PGN script takes up a LOT of space
• Collapsible doesn't work on mobile, so the game details are shown completely.

Change 716571 had a related patch set uploaded (by TheDJ; author: TheDJ):

[mediawiki/extensions/ChessBrowser@master] Button accessibility improvements

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

I did some work on keyboard accessibility for the button/actions. TODO:

• Make the titles/labels of the stateful controls reflect that state (so split play/pause, and have flip announcing the side of white)
• I notice we send all the pieces into the payload of the html, but then in the JS we seem to throw all that away ? Is there anything useful we can do with outputting the pieces in HTML ? I mean which state of the game would you even show ? If they are really only made in JS, we should remove them from the HTML output
• We'd definitely want to make it so that state changes get announced using aria-live right ? (White Queen to F3, check) This shouldn't be too hard, with some parameterized messages i guess...
• Even better would be if you could also navigate the entire board and it announced which position you are on and what piece is on that spot if any... This would require some thought about how to build the dom for the board however. We'd need an additional overlay on the board, which is a grid that announces the position, but also looks up the position and announces which piece is on that position...

Change 716571 merged by jenkins-bot:

[mediawiki/extensions/ChessBrowser@master] Button accessibility improvements

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

In T239446#7326415, @TheDJ wrote:

• The playboard announces the legend, but without a sensible order and it ignores the pieces (turn whole thing into a table?)

Another option would be display: grid; I'm not sure what the trade-offs are for screen readers between table and grid, but I think grids let us set up the board without having a bunch of empty cells like a table might.

• The playboard controls might not find on smaller screens in the available width and drop to two lines ?
• The PGN script takes up a LOT of space

The updated task description links to tasks that address these along with related patches.

In T239446#7329684, @TheDJ wrote:

• I notice we send all the pieces into the payload of the html, but then in the JS we seem to throw all that away ? Is there anything useful we can do with outputting the pieces in HTML ? I mean which state of the game would you even show ? If they are really only made in JS, we should remove them from the HTML output

I think this is an artifact of the gadget-to-extension conversion that no one got around to fixing. The goal was to display the normal start position, but because of how the JS processes the data it just wound up showing the final position. Since the PHP processes all the board states, there's no reason we can't output a particular state in HTML; Danny was working on a similar idea at T248272.

• We'd definitely want to make it so that state changes get announced using aria-live right ? (White Queen to F3, check) This shouldn't be too hard, with some parameterized messages i guess...

This sounds like a good idea, but there will be some interesting corner cases (e.g. T287843).

• Even better would be if you could also navigate the entire board and it announced which position you are on and what piece is on that spot if any... This would require some thought about how to build the dom for the board however. We'd need an additional overlay on the board, which is a grid that announces the position, but also looks up the position and announces which piece is on that position...

This might be a reason to consider a css-grid layout over a table. From reading some web posts ( 1 and 2 ), it seems that grids are better for interactive content like this. Rather than each cell being it sown focus, the whole grid is a focus that can be navigated using keys and such.

Change 720717 had a related patch set uploaded (by TheDJ; author: TheDJ):

[mediawiki/extensions/ChessBrowser@master] [WIP] Add aria live captioning for moves

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

This might be a reason to consider a css-grid layout over a table. From reading some web posts ( 1 and 2 ), it seems that grids are better for interactive content like this. Rather than each cell being it sown focus, the whole grid is a focus that can be navigated using keys and such.

So funny thing.. Turns out that CSS grid is not actually an accessible grid... So likely, I'll use CSS flexbox + aria grid.

What i'm wondering is how to most easily find the piece (if any) that is at a position on the board, with the JS we currently have... Because I think its mostly piece -> position mapping that we do now (based on the FEN?). Any ideas ?

Change 721269 had a related patch set uploaded (by TheDJ; author: TheDJ):

[mediawiki/extensions/ChessBrowser@master] Add a11y chessboard grid with labels and pieces

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

These two patches should provide a decent amount of screenreader accessibility. It wasn't easy. Lessons learned:

• CSS grids cannot be aria grids (no rows)
• Aria grids are aria tables and thus can have headers, which could be used for the position (H4), but.....
• Only the header in the direction you move the cursor is generally pronounced. Screenreaders often still pronounce the column/row offset in numbers in ADDITION to the columnheader. This made pronunciations very confusing as with headers, the grid becomes 10x10. You get things like:. "c, column 4 of 10" and "5, row 6 of 10".
• I therefore chose NOT to use headers, but instead use labels for each individual cell.
• aria-label doesn't work for empty cells.
• i18n for so many variations is hard.

Change 720717 merged by jenkins-bot:

[mediawiki/extensions/ChessBrowser@master] Add aria live captioning for moves

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