[css-speech-1] Clarify that speak:always also affects interactivity

[fantasai]

We're clarifying the definition of visibility to say that visibility:hidden disables interaction with an element. Since speak:always essentially overrides visibility:hidden for rendering, it should also do so for interactivity. (We added a note about this in css-display-3, but it needs a normative definition in css-speech-1.)

[danburzo]

Apologies if this is a naïve question, but will speak: always make the element available to sequential focus, or is this about different forms of interaction? Does the property, in principle, aspire to cover the use-cases for the .visually-hidden CSS hack described in #560?

[LJWatson]

The speak-as property is intended to specify the way synthetic speech speacks the content - whether 1001 is announced as "one zero zero one" or "one thousand and one" for example.

A combination of speak: normal; and display: none; might offer a possible solution, but elements with display: none; are not available in the accessibility tree, so screen readers would be oblivious to its existence. It's possible that some nifty browser heuristics could solve that problem though.

[danburzo]

Thanks, @LJWatson! I'm trying to get up to speed with the discussions that have taken place over the years on the subject of "visually-hidden but accessible elements". I was curious to understand which of the accessibility effects of visibility: hidden the speak property could potentially undo, and if this speech property has any bearing on that discussion.

The note on invisible boxes in the css-display spec currently reads:

Note: If speak is always, an otherwise invisible box is rendered to speech, and may be interacted with using non-visual/spatial methods.

...and it was unclear to me if that also implies reintroducing the element in sequential navigation, or presenting it in the accessibility tree.

[LJWatson]

...and it was unclear to me if that also implies reintroducing the element in sequential navigation, or presenting it in the accessibility tree.

None of the Speech properties are intended to have a direct effect on the accessibility tree. The speak property may have an indirect effect though, because when it's set to auto, it's intended to mirror the display property. So if display: none; then the element with the speak property is handled as though speak: none; was set.

Can you describe more about what you mean by sequential navigation in this context? In and of itself, the Speech properties are about changing the way content sounds when someone listens to content using synthetic speech (not just screen readers, but web readers, custom web readers using the Web Speech API and such).

Returning to the .visually-hidden problem though, the idea I posted in #6515 (comment) feels like it's worth exploring - trouble is of course that without any implementations, we don't have much to play with.

I'm working on a prototype/polyfill for the Speech properties, but it uses the Web Speech API to simulate browser speech output - and there's no way to support screen readers at this point.

[danburzo]

I am mainly interested in the case where speak: always; overrides display: none; or visibility: hidden; to render to speech information otherwise not presented to any type of assistive technology. It sounds like presenting the information aurally would entail some sort of indirect effect on the accessibility tree to facilitate it.

I understood @fantasai's original message in this thread as a task to express what this overriding of display and visibility properties entails, more formally.

In regards to your comment, a combination of speak: always; and display: none; is exactly the combination I'm hoping could function as a sort of aria-hidden=false without the burden of existing, incorrect usage.

Can you describe more about what you mean by sequential navigation in this context?

I meant sequential focus via the Tab key. A specific use-case I had in mind, related to the .visually-hidden discussion, was "Skip to content" links that are often coded to become visible upon focus. I was hoping "visible upon focus" may be expressed more succinctly with visibility: hidden; speak: always; and still have the element available for Tab navigation, but I realize that's a thought that may be too nebulous and far removed from the issue at hand.