♿ [amp-story] Allow screen reader users to pause auto-advancing stories

[calebcordry]

Introduces new css that makes the pause button invisible to users, but accessible to screen readers. It then removes these properties if the button is visual shown (desktop, keyboard active mode)

Introduces CSS selector that will make pause button intractable when screen readers are used.

• On both one-panel and supports-landscape the pause button is always visible
• When keyboard becomes active the pause button will show on mobile
• When the screen reader focuses on the pause button it becomes visible on iOS but not android. This is because talkback does not appear to set the :focus pseudo class as expected.

Partial #37393

[amp-owners-bot]

Hey @gmajoulet, @newmuis! These files were changed:

extensions/amp-story/1.0/amp-story-system-layer.css

[mszylkowski]

Can you add a screenshot for the keyboard state?

Also, I think we're better off using :not(:focus):not(:active) to hide it, instead of relying on the keyboard. It's possible that non-screen-readers use the keyboard to navigate, and that would make the pause button show up as if it was meant for screen readers (all the way in the corner). The pattern I've seen more often is that these buttons are hidden but focusable (and when focused, they become visible). Besides, I'm not sure if the DOM traversal for screen readers would make sense if we use the same pause button, because it would come in between the other icons of the system layer (maybe we want this button to come first). @kvchari might know what the best UX is.

[calebcordry]

The current logic visually shows the pause button when the keyboard is activated (detected through amp's .amp-mode-keyboard-active class)

Also, I think we're better off using :not(:focus):not(:active) to hide it, instead of relying on the keyboard. It's possible that non-screen-readers use the keyboard to navigate, and that would make the pause button show up as if it was meant for screen readers (all the way in the corner). The pattern I've seen more often is that these buttons are hidden but focusable (and when focused, they become visible).

Right now if we detect the keyboard use we make the button visible in the same spot as it would be in desktop mode. IIUC it would also be better to do this when screen readers make the element visible/active?

Besides, I'm not sure if the DOM traversal for screen readers would make sense if we use the same pause button, because it would come in between the other icons of the system layer (maybe we want this button to come first)

Good point, maybe we can address this in a follow up PR when we decide on the optimal UX?

[mszylkowski]

I see, I think I was assuming the button would show on the top left corner but it just shows and hides it in-place, so some of my comments are no longer relevant.

Q1: Why do we need to add the 1px styles if using the keyboard will show it anyways?
Q2: I've checked on a story that tabbing through the page doesn't activate the keyboard mode, does that happen to you too? Does talkback activate the keyboard mode automatically? (this is why I was saying that if we used the styles for not(:focus)... we could show the icon)

[calebcordry]

Sorry I think maybe I didn't do a great job describing this initially.

Q1: Why do we need to add the 1px styles if using the keyboard will show it anyways?

The problem is that screen readers do not activate amp's keyboard mode, so the button is invisible both to the eye, and the screen reader. This change sets the SR only css as default, but then removes it if keyboard mode || desktop.

Q2: I've checked on a story that tabbing through the page doesn't activate the keyboard mode, does that happen to you too? Does talkback activate the keyboard mode automatically? (this is why I was saying that if we used the styles for not(:focus)... we could show the icon

I am able to repro on desktop. If I switch to mobile I see the keyboard active class set as expected. I wonder if this is supposed to be a mobile only thing? Either way I'm not sure it matters for this case as the button is always visible on desktop anyway.

[mszylkowski]

LGTM

[calebcordry]

Updated description to reflect the latest logic.