a11y issues preventing usage by people with disabilities

[otacke]

I am not an accessibility expert, but there are some things I noticed in version 2.2.8:

• When the crossword receives focus, e.g. by tabbing into it, users cannot tab out of it. They are trapped inside (cmp. https://www.digitala11y.com/understanding-sc-2-1-2-no-keyboard-trap/).
• When a cell where a clue starts gets focus, the clue is not announced in any way and a visually impaired user would not know what to fill into the cells.
• When a cell gets focus, there's no hint given to explain where in the crossword the user is.

I think these are relevant issues, because they prevent people with visual impairment or motor skill limitations to use the crossword.

Suggestions:

• Find the source of trapping focus and remove it.
• Use the aria grid role (cmp. https://www.digitala11y.com/grid-role/) with proper aria labels to tell visually impaired people what they are expected to enter.

[JaredReisinger]

Thanks for the feedback, @otacke!

The tab-trapping should be an easy fix: in short, the crossword as a whole has one <input> field that manages all keyboard input. Right now, it's capturing Tab and using that as a "switch from across to down (or vice versa)" command. I've seen both Tab and Space used for this in other crossword implementations. I've also seen Tab used to advance to the "next" clue. Before I make any changes, do you have a strong feeling, opinion, or preference about what key sequences would be ideal? I think if I changed Tab to "next clue", I could also detect tabbing from the last clue, and let the default browser keyboard navigation kick in.

A corollary to having just one <input> field is that there's not really a focus change as you move from cell to cell, or clue to clue. Instead, the <input> is repositioned to float over the "current" cell. This was a design decision to avoid needing an <input> for every single cell... but might be the wrong choice from an accessibility standpoint. I'll do a little searching to see if it's possible to kick the browser's accessibility APIs upon changes. If not, I'll look at the feasibility of per-cell <input> controls.

I'll also take a look at the aria grid-role info; thanks for the reference!

[otacke]

@JaredReisinger As far as I understand the WACG, in general a Tab should always take the user to the next element that he/she can interact with (input fields, links, ...). If it's a complex element, e.g. a menu that could be expanded or a group of elements, then there are particular (standardized) keys to 'enter' that complex element. There are lists of all keyboard interactions that an element with a particular role should have: For a grid that's https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/Grid_Role

If you need a working example, try https://h5p.org/multichoice and turn on a readspeaker like ChromeVox. The multiple choice options are a group (announced as such including the number of items it it, the current position), and once entered, the user can use the arrow keys to select the item - and Tab to leave the group.

Again, unfortunately I am not an expert on that topic, but also try to find my way through it when I need to. I think good a11y could be achieved with just one moving <input> field as well by changing the aria labels to give context (that's just something using the proper elements and roles do for you otherwise). I guess the most complicated bit of work is to think of a smart way to give that context.