Intent to Ship: CSS @counter-style descriptor 'speak-as'

[Xiaocheng Hu]

(Though the I2P thread already has 3 LGTMs, there are some updates. Hence requesting another review)

Contact emails

xiaoc...@chromium.org

Explainer

https://drafts.csswg.org/css-counter-styles/#example-cce4b0db

Specification

https://www.w3.org/TR/css-counter-styles-3/#counter-style-speak-as

Design docs

https://bit.ly/3kEHluz

Summary

A custom counter style can be constructed with a meaning that is obvious visually, but impossible to meaningfully represent via a speech synthesizer or other non-visual means, or possible but nonsensical when naively read out loud. The 'speak-as' descriptor describes how to synthesize the spoken form of a counter formatted with the given counter style.

Update since I2P: The 'spell-out' value is not implemented because it is currently unimplementable (crbug.com/1247764). As the spec requires alphabetic counter styles with 'speak-as: auto' to use the 'spell-out' value, we use 'words' instead. This aligns with what Firefox currently does.

Blink component

Blink>CSS

Search tags

css, counter, counter-style, speak, speak-as

TAG review

N/A; Firefox already shipped it years ago.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Interoperability risks are very low, as we are implementing a CR feature that Firefox already shipped years ago, and Safari is positive on. Update since I2P: There is a low compatibility risk. Accessible names of a lot of predefined counter styles are changed from the counter text to the counter number. For example, if we have a list marker "IV. " using 'upper-roman' counter style, its accessible name is changed from "IV. " to "4. ". This change matches the spec and aligns with Firefox, but may shave backward compatibility risks.

Gecko: Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=966166) Firefox didn't implement the 'spell-out' value, and uses the 'words' value instead.

WebKit: Positive (https://lists.webkit.org/pipermail/webkit-dev/2021-February/031719.html) Safari is positive on the @counter-style rule as a whole, including this descriptor.

Web developers: Strongly positive (https://bugs.chromium.org/p/chromium/issues/detail?id=687225) Developers are positive on the @counter-style rule as a whole, including this descriptor.

Debuggability

N/A; it's an extension to an already shipped feature, @counter-style. Note that we don't have DevTools support for @counter-style yet, as the requirement was imposed after @counter-style was shipped.

Is this feature fully tested by web-platform-tests?

Yes

Flag name

--enable-blink-features=CSSAtRuleCounterStyleSpeakAsDescriptor

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1166766

Estimated milestones

96

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5687059677184000

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/9e9q5WAepGk/m/uw_XP5zuFAAJ

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

Hi Xiaocheng,

On Friday, September 17, 2021 at 4:16:26 PM UTC-4 Xiaocheng Hu wrote:

Summary

A custom counter style can be constructed with a meaning that is obvious visually, but impossible to meaningfully represent via a speech synthesizer or other non-visual means, or possible but nonsensical when naively read out loud. The 'speak-as' descriptor describes how to synthesize the spoken form of a counter formatted with the given counter style.

Update since I2P: The 'spell-out' value is not implemented because it is currently unimplementable (crbug.com/1247764). As the spec requires alphabetic counter styles with 'speak-as: auto' to use the 'spell-out' value, we use 'words' instead. This aligns with what Firefox currently does.

With 2 engines shipping (as soon as this ships, anyways) speak-as: auto => speak-as: words, have you passed that feedback to the spec editors, as the de-facto interoperable (and implementable) behavior? 

thanks,
Mike 

[Tab Atkins Jr.]

This feedback was provided in
<https://github.com/w3c/csswg-drafts/issues/6040#issuecomment-799868468>,
but I answered it in
<https://github.com/w3c/csswg-drafts/issues/6040#issuecomment-840874164>
with what should be an acceptable interim solution. There wasn't a
further reply from Xiaocheng, so I figured my suggestion was
acceptable; I guess that wasn't the case?

"words" will give a *broken* behavior to alphabetic lists; it would
mean that the 27th list item in an alphabetic list (with counter "aa")
would be pronounced as a single long a sound (as you can hear in
`speechSynthesis.speak(new SpeechSynthesisUtterance("aa"))`; the 28th
would be the word "ab", etc. I don't think this is acceptable for
screen-reader users. The interim solution I gave would read them out
correctly, as you can hear in `speechSynthesis.speak(new
SpeechSynthesisUtterance("a a"))`.

~TJ

[Xiaocheng Hu]

On Fri, Sep 17, 2021 at 2:31 PM Tab Atkins Jr. <jacka...@gmail.com> wrote:

On Fri, Sep 17, 2021 at 1:36 PM Mike Taylor <mike...@chromium.org> wrote:
> On Friday, September 17, 2021 at 4:16:26 PM UTC-4 Xiaocheng Hu wrote:
>> Update since I2P: The 'spell-out' value is not implemented because it is currently unimplementable (crbug.com/1247764). As the spec requires alphabetic counter styles with 'speak-as: auto' to use the 'spell-out' value, we use 'words' instead. This aligns with what Firefox currently does.
>
> With 2 engines shipping (as soon as this ships, anyways) speak-as: auto => speak-as: words, have you passed that feedback to the spec editors, as the de-facto interoperable (and implementable) behavior?

This feedback was provided in
<https://github.com/w3c/csswg-drafts/issues/6040#issuecomment-799868468>,
but I answered it in
<https://github.com/w3c/csswg-drafts/issues/6040#issuecomment-840874164>
with what should be an acceptable interim solution. There wasn't a
further reply from Xiaocheng, so I figured my suggestion was
acceptable; I guess that wasn't the case?

I somehow missed that... Let me discuss with our accessibility team to see how it works.

[Yoav Weiss]

Hey Xiaocheng! Should we consider this intent on hold until Tab's points are addressed?

[Xiaocheng Hu]

Hi everyone,

I'm withdrawing this intent.

With a discussion with the accessibility team, we found this approach (based on alternative text) problematic.

We'll try a different approach via CSS AAM. This will allow us to pass the original marker text + accessibility attributes (to be specified) to the platform AT and let them decide how to interpret it.