Re: [csswg-drafts] [css-pseudo-4] Enabling carousel design patterns in CSS (#9745)

Another chunk of conversation logs from the end of the session:

<details>
```

15:26 <@TabAtkins> wendyreid: I noticed in a lot of examples - and i've also struggled with this for devs - I haven't seen a lot where each item in the carousel contains a bunch of other content
15:26 <@TabAtkins> wendyreid: Like say each has an image, text, and a call to action button
15:26 <@TabAtkins> wendyreid: but you also want item-by-item interaction as well as interaction in each
15:26 <CurtBellew> present+
15:26 <@TabAtkins> wendyreid: so in this example (image with label) what if there's a button inside of each, too
15:27 <bkardell_> q+
15:27 — Zakim sees wendyreid, bkardell_ on the speaker queue
15:27 <@TabAtkins> flackr: this is just content inside a scrollable element, we're not treading new ground
15:27 — @dbaron ack wendyreid 
15:27 — Zakim sees bkardell_ on the speaker queue
15:27 <flackr> polyfilled demo: https://flackr.github.io/carousel/examples/carousel/image/
15:27 <@dbaron> s/syns:/cyns:/g
15:28 <@TabAtkins> TabAtkins: the only particularly new thing here is the auto-inerting. only the visible stuff in the scroller show up in the tab order, until you scroll pages
15:28 <@TabAtkins> wendyreid: in this example I might have expected focus to move to the next button at the end, rather than past
15:28 <cyns> q+
15:28 — Zakim sees bkardell_, cyns on the speaker queue
15:28 <@TabAtkins> flackr: we've seen both. the APG example has the buttons together in tab order, but they're visually together there.
15:28 <Patrick_H_Lauke> Agree with Wendy here ... APG pattern may not be the be all/end all
15:28 <@TabAtkins> wendyreid: Yes, it depends on the visual placement
15:29 — bkardell_ where is Patrick_H_Lauke ?
15:29 <@TabAtkins> flackr: I haven't mentioned this yet, thinking of having invokercommand to let you make your own buttons that scroll; you can put them anywhere
15:29 <@TabAtkins> flackr: maybe for generated content, we could use reading order to change where they are
15:30 <@TabAtkins> TabAtkins: except those are abspos usually, so they "wont' participate" in reading order. but we could build on the machinery.
15:30 <cyns> ack me
15:30 — Zakim sees bkardell_ on the speaker queue
15:30 <@TabAtkins> cyns: we were talkinga bout that in aria, having to go thru the entire slide to get to the next button can be annoying
15:30 <@TabAtkins> bkardell_: I have now twice tried to tackle tabs
15:31 <@TabAtkins> bkardell_: panels and panelsets
15:31 <bkardell_> https://github.com/openui/open-ui/issues/559
15:31 <@TabAtkins> bkardell_: most recently in openui
15:31 <flackr> demo showing scroll-marker based tabs: https://flackr.github.io/carousel/examples/scroll-marker/tabs/
15:31 <@TabAtkins> bkardell_: got far, then got feedback that a bunch of the cases, Sarah higgley and I discovered that sometimes things that look like tabs shoudlnt' be ARIA tabs, but what should they be instead? 
15:31 <@TabAtkins> bkardell_: this might be the answer
15:32 <@TabAtkins> bkardell_: these look a lot like tabs, but they're actually panels in a document, a kind of scroll
15:32 <@dbaron> s/Higgley/Higley/
15:32 <@TabAtkins> bkardell_: I like that
15:32 <@dbaron> s/higgley/Higley/
15:32 <@TabAtkins> bkardell_: especially since with a MQ you could change how it's displayed, maybe on your phone it's just a long scroll of content
15:32 <@TabAtkins> bkardell_: it's kinda a design affordances sometimes, different from browser tabs. those aren't design, they're a doc manager
15:33 <@TabAtkins> bkardell_: I'd love to hear from more a11y people if you think this might be a decent pattern for attacking this kind of tabs
15:33 <smfr> q+
15:33 — Zakim sees bkardell_, smfr on the speaker queue
15:33 <@TabAtkins> flackr: that's also one of the benefits that semantically it's just a list of content. you can just change the way it's presented based on form factor
15:33 <@TabAtkins> ack bkardell_ 
15:33 — Zakim sees smfr on the speaker queue
15:33 <@TabAtkins> cyns: would you change the a11y mapping based on that?
15:33 <@TabAtkins> bkardell_: that's the question
15:34 <@TabAtkins> bkardell_: maybe we already have things sorta like that, like collapse the menu up
15:34 <@TabAtkins> bkardell_: but it seems more known-quality and subtle
15:34 <@TabAtkins> cyns: the browser can do it in this case
15:34 <@TabAtkins> bkardell_: yeah, and this is like scrollbars. we don't say "this is a scroll area" like in Java, you just get a scroller if you need it
15:35 <@TabAtkins> bkardell_: here we can see "if you have the real estate, show them in panels" but if it's small make it just scrollable
15:35 <@TabAtkins> cyns: I like how simple the code is, especially compared to other carousels
15:35 <@TabAtkins> hdv: so this example wouldn't be ARIA tabs?
15:35 <@TabAtkins> bkardell_: I think so, I think just having it be a scroller would be a better solution
15:36 <@TabAtkins> bkardell_: ARIA tabs are cases where they're app-style tabs, more like browser tabs. those should be tabs.
15:36 <@TabAtkins> bkardell_: but they're also not likely to change, they're not a style choice
15:36 <smfr> q-
15:36 — Zakim sees no one on the speaker queue
15:36 <@TabAtkins> dbaron: I spent an hour talking to Brian and Sarah Higley a year or so ago. I'm rereading my comments, from the long issue Brian linked.
15:37 <@TabAtkins> dbaron: One thing - do you want find in page to find things in the other tab? do you want all tabs to show in a printout or all?
15:37 <@TabAtkins> dbaron: I think suggestion was if find-in-page shouldn't switch the tab, and user only wants one tab in the printout, it's probably aria tabs. if it's the other way around, probably the panel-set tabs
15:37 <@TabAtkins> dbaron: I haven't internalized it enough to be sure I believe it
15:37 <@TabAtkins> dbaron: especially that those two things correlate well
15:38 <@TabAtkins> bkardell_: i'm not sure *I* believe it. but enough people I respect have articulated it in a way that makes me think we need to take it seriously
15:38 <@TabAtkins> bkardell_: if we find something that lets us make that distinction, we should do it
15:38 <@TabAtkins> bkardell_: but yeah, I don't think everybody has the same feelings
15:38 <@TabAtkins> bkardell_: not everyone agrees on the breakdown, or even that there should be a breakdown
15:39 <@TabAtkins> bkardell_: but I think we've articulated differences that do make sense
15:39 <@TabAtkins> hdv: user research about whether they prefer panel-sets vs aria tabs, doesn't seem to be a clear preference
15:39 <@TabAtkins> bkardell_: does seem to likely be a user preference, people can prefer either
15:40 <@TabAtkins> hdv: we saw people who liked either, makes it hard to choose
15:40 <@TabAtkins> wendyreid: also it's not always semantically easy to express "going to different place on this page" vs "going to different page"
15:40 <@TabAtkins> wendyreid: sometimes "tab navigation" is doing either
15:40 <@TabAtkins> wendyreid: not clear to the user
15:40 <@TabAtkins> wendyreid: and not really a semantic way to indicate that
15:41 <@TabAtkins> ydaniv: wild idea, if I put overflow:clip (and rest is inert) it would be tabs?
15:41 <Patrick_H_Lauke> overflow:hidde (hdv)
15:42 <@TabAtkins> flackr: one idea that came up in ARIA, could have a role on the scrolling element that determines the generated content role
15:42 — bkardell_ is real curious what smfr wanted to say and if Patrick_H_Lauke has thoughts
15:42 <@dbaron> (https://github.com/openui/open-ui/issues/559#issuecomment-1585043874 was the summary of the discussion that I mentioned above)
15:42 <@TabAtkins> smfr: I had questions about the real ARIA tabs, presented today was high-level functionality
15:43 <Patrick_H_Lauke> bkardell I'm neutral on this. users often...don't care, as long as it works correctly and makes semantic sense
15:43 <@TabAtkins> smfr: for scrolling carousels, wonder if we should do it for tabs too
15:43 <Patrick_H_Lauke> q+
15:43 — Zakim sees Patrick_H_Lauke on the speaker queue
15:43 <@TabAtkins> smfr: you can do tabs today with radio buttons and :checked
15:43 <@TabAtkins> smfr: do we want this to work better in this interface?
15:43 <@TabAtkins> smfr: id' probably want non-visible tabs to be display:none for perf reasons, for example
15:43 <@TabAtkins> flackr: so something similar to scroll markers, but display:nones the non-active content
15:44 <@TabAtkins> there's definitely something good in there
15:44 <@TabAtkins> smfr: also, you said the scroll buttons are siblings of the scroller, how does that work for the root scroller?
15:44 <@TabAtkins> flackr: they're children  in that case, you'd use fixpos to position them
15:45 — @dbaron ack Patrick_H_Lauke 
15:45 — Zakim sees no one on the speaker queue
15:45 <@TabAtkins> Patrick_H_Lauke: heard about some devs doing this with radio buttons/etc
15:45 <@TabAtkins> Patrick_H_Lauke: that's obvs semantically very dubious
15:45 <@TabAtkins> Patrick_H_Lauke: much more positive with what i'm seeing here
15:45 <@TabAtkins> Patrick_H_Lauke: more bespoke, rather than a perversion of CSS
15:46 <@TabAtkins> Patrick_H_Lauke: explaining to a screen reader that, yes, there are radio buttons but they actually switch visual tabs, it's bad
15:46 <@TabAtkins> Patrick_H_Lauke: so this is a good step forward
15:46 <@TabAtkins> flackr: We're at time, wrapping up
15:46 <Patrick_H_Lauke> (in answer to brian's earlier question, i hid in my hotel room for the session)
15:47 <Patrick_H_Lauke> great stuff, thanks all
```
</details>

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9745#issuecomment-2375405493 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 25 September 2024 22:48:47 UTC