Issue/52 player accessibility overhaul

[clpetersonucf]

This is a rework of the Crossword player's accessibility implementation to be more in line with WCAG 2.0 requirements. It includes:

• Replaced generic DOM elements with semantic versions when appropriate
• Removed rigid overwrite of tab index values, ensured only relevant interact elements are part of the tab tree
• Added numerous hover and focus styles to interactive elements
• Reworked keyboard navigation for the game board. tab and shift+tab now cycle through character inputs in a word before leaving the board focus. left and right arrow keys will cycle through each word and its associated clue. down arrow will select the hint and clue buttons for the clue associated with the highlighted word. up arrow will perform this behavior in reverse, returning focus back to the selected letter. Tabbing through inputs in the clue list is also cross-compatible with up/down arrow key navigation.
• Added screenreader- and keyboard-compatible shortcuts for the special characters drawer, via using the up arrow when the board is focused and a character is selected. Like the shortcuts associated with down arrow, up and down are used to paginate through special characters and return to the board.
• Replaced numerous accessible labels, descriptions, and live regions to communicate game state and board state when contextually appropriate.
• Improved accessibility of the dialog modals for important alerts.
• Added keyboard instructions dialog.
• Added tutorial dialog with quick access to keyboard instructions.
• Added a dialog to prompt the user to submit their answers the first time all character cells are populated.

[cayb0rg]

Really like this implementation. Keyboard navigation feels good. I think the down key for word options feels especially intuitive. The aria labels, descriptions, and live regions are also great. Some things I found:

• Intersections and black cells might benefit from having labels describing them as such
• Hints are not read out after being selected
• I’m still able to navigate between cells using the VO modifier + Arrow keys while using VoiceOver; I think this should be fine as long as it’s clear to the user that doing so will not actually move the input focus
• It might be helpful to list which questions still need to be completed in the Submit dialog
• Free word button doesn’t return focus to the word

[clpetersonucf]

Additional updates:

• Lots of bug fixes and edge case handling related to character input focusing, hint button selection, and free word button selection.
• Hint button selection updated slightly: confirming the warning dialog now re-focuses the hint button, which makes dictation of the hint more consistent. Hint buttons remain focusable after selection, but cannot actually activate again.
• Free word selection now focuses the word after selection, and free words now have additional labels indicating the character inputs are locked.
• Non-interactive cells (whitespace or special characters like hyphens) remain ignored in the tab tree, but using VO+arrow keys to select them will convey their contents.
• The special character list now has a label warning that the items are not usable in the current context, and the up arrow should be used instead when a character is selected.

"Let it ride" issues or could not resolve:

• Dictation is still wonky after keying a letter in a character cell. I tried a bunch of different options and couldn't find a satisfactory resolution.
• I was not able to reproduce being able to focus the completion confirmation dialog by tabbing through inputs before leaving the widget
• As far as I can tell, there's no way to address VO+arrow key navigation programmatically, so I can't really handle users using VO key to navigate character cells. When the VO+arrow key focus is released, focus returns to the actual focused character, and at least that focus is dictated by the screenreader.

Final todos:

• I plan to add a tutorial screen to better initialize keyboard flow, instead of forcing focus to the first letter in the game board (and skipping instructions tied to the board element in the process)

[clpetersonucf]

Final (?) tweaks:

• Added intro/tutorial dialog with a quick access option to keyboard instructions
• Tweaked screenreader dictation associated with keyboard and intro dialogs
• Added alert dialog when the student completes the widget. The prompt will display the first time, but if dismissed, the prompt will not display again when the completion state is re-entered.

[FrenjaminBanklin]

Agree with Cay's points. I also think it might be a good idea to tweak the spacing of the intro/tutorial text and left-align the paragraphs just so everything looks a bit more uniform.

You already made a note about some of these, but for the sake of completion I'll mention them again anyway. The few remaining things I noticed that are kinda weird/confusing/inconvenient but are ultimately still pretty minor:

• When typing a letter into a blank cell, the screen reader will say what the new position of the cursor is before it reads out the value just typed.
• Going back to a cell that has a letter in it already and typing a new letter does not read out the new letter provided to that cell.
• If the cell ahead of a blank cell has a letter in it and a letter is then typed into the blank cell, the letter just typed is not read - instead the letter that was already present in the next cell is read.
• The special character tray does not scroll to show letters outside of the default visible range when they are selected.

Not sure how much control we really have over what order the screen reader reads things in, and the problems are generally pretty minor but I could still see unsighted users getting a little confused. Since we're already updating the aria-live region to read out the location of the cursor when it moves, maybe we could also figure out a way to bypass the usual 'read the letter' behavior and just add the last typed letter to the aria-live readout?

It might also be nice to indicate when a cell is part of another word since it will already have a value when users tab into it, but I could also see that being extraneous/confusing information for a person who can't see the layout anyway.

[clpetersonucf]

Updated the intro dialog layout slightly, added aria-hidden to the <aside /> containing the tutorial image, and added a toolbar button to display the intro dialog.

The remaining items may fall under the "let it ride" category. I experimented with reading out the just-typed letter through the live region, but the screenreader opts to concatenate previously typed letters together, so it attempts to read out the word or phrase at it exists so far. I found the behavior moderately confusing, so I'm not entirely convinced it's better than the current behavior.

[FrenjaminBanklin]

The screen reader tripping a bit over what order it reads things in when typing a letter into a slot is probably fine for now, if not ideal. The intro dialog looks better - the keyboard instructions dialog is fine but might also look a bit more put-together if it gets the same treatment as the intro window.

I'm also just now noticing that the player gets a little weird when the user tabs into a cell that is shared by two words.

In the demo, for example, tabbing through the letters of the 'Stonehenge' question will quickly land on a cell that is shared with the 'The White House' question - but instead of reading out 'Character position 2 of 10' followed by the text for the 'Stonehenge' question it reads out 'Character position 8 of 15' followed by the text for the 'The White House' question. I don't think this is a huge deal necessarily, but it could be confusing if a non-sighted user all of a sudden winds up in a different spot of a different question that they weren't expecting because they can't see the overlap.

[clpetersonucf]

Good catch. The aria-describedby attribute in intersection character spaces will now update depending on the currently selected word/direction.