Misc updates: styles, accessibility #59
Conversation
… that broke tests
|
Runs great and tabbing works as expected, except for one small case that seemingly appears only when VO is on. You can tab into the top here and the VO will basically say "you've completed all the questions". This could be really misleading for non-sighted users, though I haven't found why it tabs to that specifically and why it doesn't highlight the whole banner block instead. 
Note: This happened on Google Chrome. |
There was a problem hiding this comment.
For the most part the cleanup looks to be functioning well and looking good, though there are a couple of minor things.
When closing the keyboard instructions modal, it might be worth sending focus to the keyboard instructions button rather than the frame in general. Considering the modal can be opened at any time by pressing the 'H' key it's possible that the button won't be the last place that had focus prior to the modal opening, but it's a pretty good guess. Ideally the 'last focused' element could be tracked before moving focus to the modal, and then focus can be given back to that element after the modal is closed - but that feels like it'd be a bit much for a slight convenience.
That being said, I'm not sure that having a dedicated button to open the keyboard instructions modal is valuable for sighted users. I have no mobility issues so I don't know what would or would not be useful in that scenario, but I feel like having the H key just read out the instructions rather than open the modal (and leave the H key out of the sighted instructions altogether) might less cumbersome, since unsighted users don't need to close a modal after reading the instructions and sighted users would only know about the shortcut if they've manually opened the instructions anyway.
I'm not sure if I'm a fan of the added delay in the focus-me directive. If it was meant to delay giving focus to the 'Next' button until after it was done animating, I think that problem was handled more directly by not auto-focusing the 'Next' button after selecting an option. If a delay is absolutely necessary in the case of the 'Next' button I think it would be better to add some kind of condition inside the directive to determine whether it's acting on that button specifically, rather than delaying the focus for everything. It may also be worth adding some logic in the controller to make the Next button un-focusable until it's done animating just to be safe.
…r closing kb instructions modal.
Thinking about this some more, I don't entirely disagree with your point but I'd prefer to err on the side of providing too much information instead of too little. I'd rather leave the modal intact for now instead of making additional sweeping change associated with removing it. The only nuance with the current implementation is the focus behavior after selecting an answer choice: since the answer choices are rendered inert, focus changes to the widget frame after selecting a response, and tabbing focuses the next button (with the added mention of re-entering the widget frame.) It's a small thing, but slightly annoying. I experimented with using |
There was a problem hiding this comment.
Turns out the tabbing issue I had previously was linked to my browser version. Having updated to the most recent version, the widget runs great! Only thing I'd suggest is that the media playback controls are disabled or hidden once the answer's been selected. As seen here, they're still in the tab order.
There was a problem hiding this comment.
The only nuance with the current implementation is the focus behavior after selecting an answer choice: since the answer choices are rendered inert, focus changes to the widget frame after selecting a response, and tabbing focuses the next button (with the added mention of re-entering the widget frame.) It's a small thing, but slightly annoying. I experimented with using disabled instead of inert but then we lose the ability to quickly focus the next button after making a selection. Let me know if you all have opinions either way.
Since the de-focus to widget frame doesn't disrupt the tab order, this seems like a fine substitute. Tabbing to focus the next button feels natural, at least to me.
The media-playback controls are hidden to the screen reader but it's still possible to tab to the audio container (not possible to use VO keys, however).
That said, this looks good to go! Nice work.
There was a problem hiding this comment.
Tested with Safari, Firefox, and Chrome. I was able to duplicate the discrepancy with Safari's tab-sequence being different (takes 2 extra tabs to reach 'Next' after getting question feedback). After viewing and closing instructions, the previously selected element is indeed highlighted again. Other than this, the navigation is intuitive and the layout looks good.
Some small visual + behavioral polish after the accessibility update:
focus-medirective (premature focusing during CSS transitions contributed to element "shifting")Tested in Firefox, Chrome, Safari, with and without VoiceOver. VO + Safari has several small issues - including a different tab sequence position for the Next button, and residual "shifting" when the Next button is clicked - but the issues are minor and shouldn't significantly affect non-sighted users.