Info panel behaviour with screen reader navigating

[EmmaJP]

LauraB asked questions via Slack because the info panel demo was inconsistent with her understanding of the documentation. Specifically, when navigating forward from the last content element of the info panel using the screen reader controls, rather than keyboard tab, the info panel did not close as expected.

For information, she was trying this with MacOS and iOS, VoiceOver and the Safari browser.

[micmath]

@Heydon does that seem like an unintended behaviour (sometimes pronounced "bug") to you?

[micmath]

Am I right that "navigating forward ... using the screen reader controls" does not move DOM focus in such a way that can be detected with JS? Referring to...

A Windows screen reader will intercept the left/right keystrokes and use them to move focus within the virtual buffer, instead of passing them through to the browser to interact with the set of tabs.

So in the original post, when you say "navigating... using the screen reader controls" is that reading content from the virtual buffer? As opposed to moving DOM cursor focus to a new focusable element in the visible page? If it is in the virtual buffer, then I think it is not possible to detect with JS, without forcing the entire page into "Application Mode" or some such, which is undesirable.

[EmmaJP]

When trying out VoiceOver on this Github page via Chrome browser, the screen reader control seems to move focus with it, but keyboard tabbing did not appear to take the screen reader with it, which was unexpected!

When trying out VoiceOver on this page via Safari, the screen reader control moves the tabindex focus whenever it moves to an interactive element, and keyboard tabbing also moves the screen reader cursor with it, which was as expected.

VoiceOver is known to behave irregularly with Chrome.

[micmath]

Cite: https://webaim.org/discussion/mail_thread?thread=8526

Screen reader focus (Voiceover in this case) and keyboard focus are not the same thing. If you were to use keys like tab or shift+tab that move the keyboard focus to the next or previous control in the tab order, the screen reader focus would follow it. The reverse is not typically true. The reason for this is so someone using a screen reader can navigate and read all the user interface elements--not just those that can be reached by keyboard.

and...

In High Sierra there is only the "Synchronize VoiceOver and Keyboard Focus", in older versions there are two separate check boxes

I have encouraged Blind Users to turn off both Mouse Follows VoiceOver cursor and Keyboard focus follows VoiceOver Cursor

So it seems like part of the issue is by design in that it can be fixed by the user setting their keyboard focus to follow their virtual cursor, but that for various reasons this is undesirable, so we land on a situation where we cannot detect if the screen reader cursor has left the info panel which is non-ideal but less worse than any situation where we could detect that.

I'm inclined to mark this ticket as "won't fix". Any comments?

[micmath]

And a related project experiencing this pain: https://github.com/wet-boew/wet-boew/issues/5009 (is worth a read)

[micmath]

mentions @laurabond

[Heydon]

I believe this is because the panel closes when it (the last interactive element inside it, in fact) loses focus / is blurred. This event would not be triggered by screen reader virtual cursor navigation. Might need to also close the panel on a down arrow event on that last interactive element.

[micmath]

@Heydon couldn't that be fragile, given the myriad kinds of content that could be in an info-panel? I'm thinking of scenarios where hijacking the down-arrow event wouldn't be possible or would be unexpected at least. I happened to ask @IanPouncey about this and he suggested that your existing <ESC> key behaviour should be sufficient affordance for this use case.

I'm still inclined to mark this as "won't-fix" due to the fact that the issue can be avoided in some cases by changing the user settings, and it cannot be fixed via reasonable implementation hacking (since this is "as-designed" behaviour coming from the screen reader and or browser).

The actual fix would then be to update the documentation to make it clear that the panel should close when keyboard focus leaves the element (not necessarily when a screen reader's virtual cursor leaves).

Last call for dissenting comments? :)

[EmmaJP]

I think I'm in the camp of adding a sentence or two into the documentation that explains that screen reader navigation may behave a little differently to tabbing, and why. It might also increase awareness of the different cursors and how they affect :focus, something I've had to explain several times this year.

[Heydon]

@micmath I agree. I forgot about the ESC key support. I was addressing it as if it's a bug, but actually I can't think of any implementations (for any kinds of patterns) that address this specific discrepancy between keyboard-only and screen reader behavior.

I think I'm in the camp of adding a sentence or two into the documentation that explains that screen reader navigation may behave a little differently to tabbing, and why.

+1, @EmmaJP