Web #accessibility folks, especially ones who get involved with specs, what do you think about CSS Overflow Module Level 5? It's "adding the ability to generate and associate various scrolling controls (markers to indicate scroll progress, buttons to trigger scrolling)…"
Chrome 135 (next month?) is shipping with support for pseudo-elements that:
* have semantic roles.
* are in the focus order.
* are named by the `content` property.
* user-agent defined behaviors (moving the associated scroll area).
`scroll-marker-group` creates a whole ARIA tabs pattern, minus the tabpanels! Well, "whole" except the tabs aren't named.
@cwilcox808 @acarson I think that the blog post I read about it claimed, and I quote, "incredible accessibility", but I couldn't make head nor tail of the linked demos with a screen reader. So consider me unconvinced and extremely concerned.
@jscholes
I only looked at this carousel example in Chrome Canary. Two pseudo-elements make buttons named Next and Previous. The scroll-marker-group element creates a tablist containing tabs, one for each item in the scroll area.
Trying VoiceOver, the tabs are not named but are numbered. Arrow key navigation works on them. I could not name them using their `content` properties. The tabs do not have corresponding tabpanels.
@cwilcox808 Thanks for the minimal demo. Is the content of the slides supposed to go inside the `<li>` elements that are currently empty? If I fill them in, with NVDA on Windows I get:
* Two buttons with accessible names of "Scroll Left" and "Scroll Right";
* a list of 10 items containing the text of all slides upfront; and
* a collection of unlabelled tabs in an unlabelled tab list.
So for me as a screen reader user, I'm unclear what utility this has. I can just read all of the slides at all times anyway, making the buttons and tabs useless noise. Meanwhile:
1. There is no accessible feedback when I press the scroll buttons.
2. The tab list doesn't support Home and End keys.
3. I'm not convinced all carousels can or should be represented with tabs.
4. If I place a focusable element (a link) in slide 10 and then focus it with Tab, the carousel scrolls to show slide 10 but the selected state stays on the first tab.
@jscholes
Yes, each <li> would be a slide.
I agree with all that.
When Adam Argyle posted about this, he was talking about the buttons primarily as a pointer affordance. But I think having visible controls like these not be represented in the accessibility tree would at minimum be surprising to those that use both. I haven't tried but I expect they're meant to work with Voice Control.
@jscholes
I think part of what drives the search for solutions like this is the decline of OS scrollbars, especially in Apple operating systems and in mobile interface generally. Once upon a time, some scrollbars had their own forward and back buttons, sometimes at either end, sometimes grouped together.
Scrollbars are already a visual and pointer affordance (even for non-pointer users, they can indicate the size of a scrollable area and one's position in it). If browsers made their own scrollbars, they could add back buttons like that, let users make them larger so they're larger targets, and add visuals for each snap point when they're set. I'm not saying that's what should be done but it would be an alternative to what Overflow Level 5 is doing and not be stepping into what has never been CSS's realm.