[css-content] Use case for counter / counters in content alt text?

[emilio]

Implementations don't support this, and supporting it creates somewhat non-trivial complexity (because counter use nodes need to be evaluated and inserted during layout tree construction).

It's not impossible to do but I wonder what's the use case for it? If there's no strong use case should it be dropped from the spec?

cc @dandclark

[dandclark]

Yeah, given the complexity to support this I think it should be dropped unless there's a strong use case and some signals that browsers are likely to actually implement it, which at the moment seems uncertain at best.

[fantasai]

If it's about whether it can be implemented easily enough rather than whether it's a reasonable feature to spec, then I think we can just mark it at-risk.

[danielsakhapov]

I'm thinking about Carousel project and specifically ::scroll-marker. When they are displayed as let's say navigation dots, I believe we want alt text to be based on counters (e.g. content: "" / image counter(dot_number))? Otherwise navigation would be useless since the content property is just empty "" for ::scroll-marker to look like a dot.

@flackr @w3c/accessibility-specialists @aleventhal

[flackr]

FWIW, I think that by default scroll-markers in an exclusive group should be given the tab role, with the scroll-marker-group having the tablist role (following the carousel guidance suggested for authors at https://www.w3.org/WAI/ARIA/apg/patterns/carousel/ ) and have a generated accessible name based on the number of items in the group (e.g. just as a radio button will tell you how many options you have). Of course allowing authors to set meaningful names based on counters would be a good improvement to allow authors to add more meaning than a generic "item" or "marker".

[aleventhal]

The accessibility tree also has concepts of "position in set" and "set size", which it computes automatically, so that screen readers can read something like "Tab 3 of 5". It does this for a number of controls, e.g. radio buttons, list items, etc. I'm not sure if screen readers universally will announce these for tab controls, so we need to test. If they do, then name would probably just need to be something generic, otherwise you will hear the item # twice.

We'll need to look into that before we decide whether to automatically populate the accessible name with the number. Even if it doesn't work, there's an argument to be made that the screen reader is what needs updating there.

[scottaohara]

@aleventhal is right, screen readers will generally announce the x of y information for markup patterns that support the position in set / set size. if at all possible, such numeration should not be appended to accessible names, since this will just add unnecessary verbosity.