Issue/accessibility

[cayb0rg]

Fixes accessibility issues in the player.

• Problem: The 'Start' button is reachable in the tab order even after a play has started
  • Fix: Used aria-hidden and inert to hide the splash screen elements depending on game state
• Problem: Content outside of lightbox is navigable
  • Fix: Used aria-hidden and inert to hide the game board when lightbox is open. Also added aria live alerts for when a lightbox opens and closes.
• Problem: Clicking "Start" and "Next" and exiting lightbox seems to make the application lose focus.
  • Fix: Removing ng-disabled and using a focus directive to redirect focus fixed this (plain ol' element.focus() doesn't appear to work). After choosing this or that, it should direct focus to the Next button. After clicking Next, an invisible, tabbable div will redirect focus to the start of the application.
• Problem: Game status updates are not being read out
  • Fix: Moved aria-live region outside of its current section
• Problem: Entire game board shifts upward when VoiceOver is used
  • Fix: To-Do. Something to do with the arrow keys? Edit: This appears to be an issue on older versions of Firefox only.
• Problem: I'm unsure whether to make the choices' contents (especially those with video or audio) inert after the user has selected their answer. Currently, all choices are unselectable after choosing an answer, but videos and audio are remain playable.

Additional changes

• Added keyboard controls. The instructions for these are in an aria-label on the Start button.
  • "A" and "D" keys for selecting "this" or "that", respectively.
  • "Q" key for repeating the question.
  • "Escape" key for opening/closing instructions.

Notes

Tab navigation will not work with Firefox versions < 112 (released April 11, 2023) because of the use of the inert attribute.

To-Do

• Jest test coverage

[clpetersonucf]

Some high-level design considerations:

1. The keyboard controls should be provided in a dedicated dialog accessed via a visible button on the player, instead of being dictated when the start button is focused again. I'd only know to what hotkey to press to re-read the instructions if I happen read through them the first time, and the controls are not conveyed to sighted users at all.
2. We discussed this for other widgets in other contexts, but focusing the question text when a question is first displayed is probably suitable here. It serves as an easy way to convey critical game info (the current question) as well as a suitable programmatic focus target when we advance to the next question. Pressing "Q" could focus this element or simply read its contents. There should be a visible style associated with focusing the question, but not one that could be confused with an actual selectable input.
3. Selecting an answer choice should provide an assertive aria-live region update to dictate the results of the selection (correct or incorrect) as well as reading back the feedback, if present. Answer choices should remain focusable after an answer is formally selected, and provide game state ("question answered, correct or incorrect"), and read feedback, if present, when focused.
4. Selecting the next question button should probably indicate how many questions remain.

[cayb0rg]

New changes:

• Added questions remaining button to top right
• Added instructions button to start menu and top left of game
• Made choices focusable after selection, with aria-labels set to their feedback
• I wasn't able to replicate the issue with aria-live not reading out updates. For me, pressing "Q" will read out the question's contents and question results are read out after selecting an answer

[clpetersonucf]

• 👍 keyboard controls button and modal is good
• I would use a more readable sans-serif text for the body of the keyboard instructions modal, the font used for buttons and headings is fine for large text but really difficult to read in paragraphs.
• I like the animation associated with the question number UI element but I think it's overly complicated for what it needs. Ideally, the question itself is focusable and the question number is either appended or prepended to the text when read aloud. As a potential alternative, the question number could be conveyed via live region when you transition to the next question. You could then have a static, non-interactive text version of the "X of Y" question number visually displayed somewhere (if you want more feedback or ideas about this, just lemme know.)
• esc is a default navigation keybinding, so I would avoid using it for toggling the keyboard instructions dialog. "H" is probably a better option and is used in other widgets.
• The "Next" button appears to be encapsulated in another element that's also tabbable, so the first element identified by the screenreader is the generic "group" element followed by tabbing into the button itself. That should be condensed down to just the button.
• There appears to be a tab trap where the user cannot paginate forward out of the answer pairs to the rest of the page. Instead of looping users back around, maybe assign left and right arrow keys to focus the This and That options. Users should always be able to tab out of the widget in both directions.

[cayb0rg]

Good catches! I've changed the question number to have a status role and changed its aria-label to say " questions remaining. On question of : [question title]". Player can press "Q" to read out the question again with its number. They can also use standard navigation to navigate to the question title, which is only a couple presses away. When the player hits Next, the aria-live region reads out "Question <> of <>: [question title]".

[clpetersonucf]

I'd also try and resolve the tests not passing, if possible.

[cayb0rg]

You got it 👍🏻 Also, I pushed a few more changes, which inevitably broke some things on Chrome (such as the aria-live update not playing on the first question, and the "1 questions remaining" playing after all questions are finished). I'll look into getting these fixed asap.

Edit: Aria-live region updates can now be heard in both browsers. However, returning focus to the last selected element after exiting keyboard controls is broken in Chrome.

[clpetersonucf]

No show-stoppers remaining. Well done.