w3c
[css-content] Use case for counter / counters in content alt text?
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
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.
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.
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
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".
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.
@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.
The CSS Working Group just discussed [css-content] Use case for counter / counters in content alt text?, and agreed to the following:
-
RESOLVED: mark counters in 'content' alt text as at-risk
The full IRC log of that discussion
<fantasai> emilio: This came up during implementation of alt text content feature<fantasai> emilio: it looks simple, but very complex to implement because counters work on the layout tree
<fantasai> emilio: it's fine to mark at risk, but given nobody supports it and unclear if use cases though some mentioned in the issue...
<fantasai> emilio: so wondering if we should just drop
<fantasai> fantasai: prefer to mark at-risk
<fantasai> fantasai: nobody says it's a bad idea, and there are some use cases; just a question of implementability
<fantasai> RESOLVED: mark counters in 'content' alt text as at-risk
I'm working on shipping it in Blink, as it's needed for ::scroll-marker's accessibility, so that authors can give more meaningful names to them. It goes along with https://www.w3.org/WAI/ARIA/apg/patterns/carousel/examples/carousel-2-tablist/.
As I'll go through the process of collecting standards positions from WebKit and Firefox, I guess we can discuss it there with each browser vendor separately.