Proposal for Exclusive Accordions

[dbaron]

I've started writing an explainer for Exclusive Accordions.

I'm interested in feedback on this proposal, either here or in separate issues.

[scottaohara]

i'd submit the issue i filed here is related as a parallel or partially alternate way to do this - #700

[bkardell]

@scottaohara #700 (comment) :)

[scottaohara]

Ayup

[css-meeting-bot]

The Open UI Community Group just discussed Proposal for Exclusive Accordions.

The full IRC log of that discussion

<gregwhitworth> Topic: Proposal for Exclusive Accordions
<gregwhitworth> github: https://github.com//issues/725
<jarhar> dbaron: i dont know how much ive talked here about the work iw as doing with css toggles
<jarhar> dbaron: i was doing a prototype of css toggles in chromium
<jarhar> dbaron: i was workingn on ax heuristics
<jarhar> dbaron: it felt like there were a set of obstacles to actually making toggles viable
<jarhar> dbaron: across a few different dimensions
<jarhar> dbaron: what the dx should look like
<jarhar> dbaron: whether the ax heuristics would work out and a few other pieces
<jarhar> dbaron: what ive been doing altely is putting that aside and trying to see if theres a way to address those use cases in other simpler ways
<jarhar> dbaron: this is one of those, and i think one of the simpler ones really because i wanted to start with a simpler one
<jarhar> dbaron: this is a piece that is hopefully, and you can always be wrong about these things, but hopefully relatively simple
<jarhar> dbaron: which is being able to make an exclusive accordion in html
<jarhar> dbaron: right now html has the details element which you can basically make an accordion by putting a bunch of details elements next to each other
<jarhar> dbaron: some accordions let you open them independently of each other, others ensure that you only have one open at a time
<jarhar> dbaron: both pretty common patterns
<jarhar> dbaron: one thing i wanted to see was can we make the details element work for making exclusive accordions, thats what this explainer is
<jarhar> dbaron: im working on another one about improving the stylability of the details element
<gregwhitworth> q+
<jarhar> dbaron: pretty closely related if we really want people to use these things
<una> q+
<jarhar> dbaron: this is a reasonably short explainer
<jarhar> dbaron: we have an attribute on the details element that gives it a name, all the details with that name it forms an exclusive group, if you open one then it closes the others
<jarhar> dbaron: i have four open design questions in the explainer id like feedback on
<jarhar> dbaron: and im open to other feedback people have
<jarhar> dbaron: i dont know if its worth going through those questions now
<jarhar> una: looking at this it looks like this is really scoped to making accordion behave one at a time, i know you looked at other behaviors for accordion. is this only scoped that funcitonality?
<gregwhitworth> ack una
<jarhar> dbaron: do we want to separate the features of link these details into an accordion and make it exclusive? is there value to linking them together even when its not exclusive
<jarhar> dbaron: but it is designed to be a simple and smal feature
<jarhar> una: we want print styles to open all
<jarhar> una: to customize these through css, which is sort of the opposite of this
<jarhar> una: i wonder if thats something youre still thinking about
<jarhar> dbaron: i think youre right that the appropriate print style is to have them al open
<jarhar> dbaron: i dont know how to address taht with this approach, but we should fix it
<masonf> q?
<masonf> q+
<scotto> q+
<jarhar> una: there might be more work on accordion, but this proposal is just for one at a time
<jarhar> dbaron: yeah
<jarhar> gregw: one of the things that im struggling with is that we kind of put, ryan and numerous others put a bunch of tab stuff on pause for toggles
<una> q+
<jarhar> gregw: we havent gotten much insignt, toggles is having a bunch of work in csswg, and it was a good primitive
<jarhar> gregw: when they were doing all the research for tabs, in this scenario you want the accordion to work, and in this scenario you want them all open
<flackr> q+
<jarhar> gregw: i think thats why they were interested in css toggles
<jarhar> gregw: im not opposed to what youre putting forward, i just want some code examples
<jarhar> gregw: im all for us not trying to boil the ocean
<jarhar> gregw: this is a good step
<jarhar> gregw: i guess my concrete question is: is css toggles being abandoned?
<gregwhitworth> ack gregwhitworth
<jarhar> dbaron: i think thats still a complicated question. i think one piece is the approach we were trying to take with ax isnt going to work
<jarhar> dbaron: i am skeptical that we want to make css toggles the recommended interface to doing this for most things
<jarhar> dbaron: but i think it may still be entirely possible that we want to build a bunch of higher level thing that use something like css toggles underneath
<gregwhitworth> ack masonf
<jarhar> masonf: just to add a little to that, it might be worth spending time about the conclusion of toggles because it is a good point that there were people waiting for things
<jarhar> masonf: on accordion, non exclusive accordions already exist as a bunch of details elements, but keyboard behavior
<jarhar> masonf: the desired behavior is to tab through all of them, but if it is to use the arrow keys, then it might be worthwhile to build a way to build exclusive and non exclusive accordions
<masonf> q?
<jarhar> dbaron: yeah those are some of the questions i asked - is there a use case for non-exclusive accordions. i would love it if someone has good answers from an ax perspective
<gregwhitworth> ack scotto
<jarhar> scotto: that was a lead in if there ever was one
<jarhar> scotto: i think that this is generally a decent idea to move forward with
<jarhar> scotto: i did link over to my proposal for making buttons a toggle button that would allow for something similar to this, a bunch of exclusive accordions one could make by having a button with whatever attribute needs to be that works similar to the popover attribute but doesnt put it in the top layer that could be strung together with a name or grouping elements for the idea of how to make details summary elements show that they acdtually are gr[CUT]
<jarhar> scotto: for radios we use fieldsets
<jarhar> scotto: to show how they are all grouped together this is one way to do it
<jarhar> scotto: that then kind of goes into the idea of how should the keyboard behavior should be
<jarhar> scotto: theres pros and cons to adding arrow key behavior
<jarhar> scotto: potential removal for tab stops
<jarhar> scotto: but responsive design, zoomed in viewports where the shown content is longer than the viewport, so one tries to use the arrow key to scroll, but now that its being taken over by the accordion, moving you to the different accordion triggers
<jarhar> scotto: well if you have a small viewport size, you press the down arrow and now you dont get to read that content because it opens the next accordion
<jarhar> scotto: its a weird ux problem that doesnt often happen on larger viewports, but impacts people who need to zoom in
<jarhar> scotto: best practice is to not apply keyboard behavior
<jarhar> scotto: maybe if there was a modifier key like ctrl + arrows
<gregwhitworth> q?
<jarhar> scotto: thats a worry i have for the focsgroup proposal
<jarhar> scotto: screwing around with how people expect the tab key to work, magically changing the way that works without visually indicating that its different now
<jarhar> scotto: how is a visual user to know that on each website this is how the arrow keys work
<bkardell_> q?
<gregwhitworth> ack una
<jarhar> una: to answer davids question about non exclusive accordions, there are definitely use cases for these
<jarhar> una: i get annoyed when exclusive accordions close, i want to see two faq answers at the same time
<jarhar> una: but then also, as were talking about this exclusive behavior, theres a lot foc ommonalities between accordions, tabs, carousels, one thing is open at a time when one thing is a trigger seaprate from the view that youre showing
<jarhar> una: i know that with seelctmenu we broke stuff out into more common use cases
<jarhar> una: more exclusive nature of the view reminds me of tabs and carousel where youre opening one view and closing other ones
<jarhar> una: maybe in implementatio ntheres some commonalities
<jarhar> dbaron: toggles thinks about it that way, there are pros and cons
<scotto> q+
<bkardell_> some of the work with panelset was also thinking about htose things
<jarhar> gregw: is it possible to next week give 10 minutes on where that is in the csswg, pros and cons
<jarhar> gregw: we should do it for these reasons but not others
<jarhar> dbaron: sure next week
<gregwhitworth> +1 to consistency
<jarhar> una: to add to that, the way we decide to solve this, whether its a group or attribute, we should be consistent in the way we solve this for the dx
<gregwhitworth> ack flackr
<jarhar> flackr: in terms of the relation to toggles, you could imagine that these higher level elements are just defining a set of toggles and toggles is th eexplanation for how it works, but the elements define it correctly, and i think thats a good way of thinking about it
<jarhar> flackr: the different elements make more sense for defining roles and keyboard behaviors
<jarhar> flackr: i was testinging details, and it doesnt print open when you print
<bkardell_> q+
<jarhar> flackr: some pages are going to break if you try to open all of the exclusive accordion
<jarhar> flackr: i want to speak to keyboard behavior: i think theres a set of expectations that users have when they have the trigger for these things open that you can rrow between them
<gregwhitworth> to una's point, a few of us have looked at radio and checkbox groups so I'd expect a containing element in those scenarios following most design system paradigms
<jarhar> flackr: this exists for tabs and radio buttons
<jarhar> flackr: needing to allow arrow for scroll behavior means that you need a way to move focus off the trigger and into the content so you can distinguish
<jarhar> flackr: it is valuable to keep that existing keyboard behavior because it is expected by components
<gregwhitworth> ack scotto
<jarhar> scotto: youre absolutely right, theres something that could be done here, its debatable that this arrow key functionality is expected for an accordin, theres some people that expect it
<jarhar> scotto: being that accordions are built as button elements that just show and hide content, theres no expectation that arrow keys should navigate between buttons, that is completely just extra functionality
<jarhar> scotto: i do agree, theres something we could do, but its not true to say that its an expected functionaliy, it depends who you are
<jarhar> flackr: yeah some places where its expected and some where its now
<jarhar> scotto: would this be an opportunity to fix some of the ax gaps with details and summary? thats my primary concern with this proposal, details is currently messy
<jarhar> scotto: they allow so many things in their content model, people are confused that they can put headings inside the details summary, but theyre inconsistent about being exposed
<bkardell_> present_
<jarhar> scotto: some platforms map it as a button, others do other things, its not consistently conveyed
<jarhar> scotto: with tabs and panels there was a understanding that accordions need headings inside them, but that wont work with details unless we fix those issues
<jarhar> scotto: we could do this, its a good idea, but theres other underlying issues that need to be fixed to make it viable for this use case
<jarhar> dbaron: i shoudl probaly find or look over those issues
<jarhar> dbaron: it sounds like some of the concern is - is it for the content model?
<jarhar> scotto: anything is allowed inside the details, but the summary element itself
<jarhar> scotto: you can put a text input inside the summary
<jarhar> scotto: you can tab into that, if you press the enter key it toggles the details - interactive element inside an interactive element
<bkardell_> that is an easter egg
<jarhar> scotto: thats just one of the things
<gregwhitworth> ack bkardell_
<jarhar> bkardell: i missed the beginning of this
<jarhar> bkardell: it would be great to colle t in the issue for this all the open issues that currently related to sumary detail kind of things
<jarhar> bkardell: it looks like the proposal is that they would work anywhere in the same tree
<jarhar> dbaron: we havent talked about it here, but yes that is the proposal
<jarhar> dbaron: i put that in the explainer in the possibly resoled questions section
<jarhar> dbaron: im sort of hesitant to require a commmon parent, i can imagine use cases where people want it to be a common grandparent
<jarhar> bkardell: people could put them all over the place, i go back and forth about this, how far should you go out of your way to prevent people from doing things that arent a great idea
<jarhar> bkardell: if its the same tree, you could have one sort of panel in the heading and another one all the way down in the body somewhere, and then one in the footer, and theyre seen as one control
<jarhar> bkardell: i dont think that theres anything like that, a control with pieces that are all over the place
<jarhar> dbaron: im not sure if thats a good practice but i dont think we should forbid it
<jarhar> masonf: thats how radio buttons work right?
<jarhar> scotto: i think that theres pros and cons to both doing a container and allowing this
<jarhar> bkardell: radio buttons can be scoped to a form, but otherwise theyre everwhere
<jarhar> bkardell: you wouldnt want to say this details thing is scoped to a form
<gregwhitworth> q?
<jarhar> bkardell: maybe theres an argument that we need a way to scope it, but maybe not
<jarhar> bkardell: it feels like this is super related to the panel sets proposal, panel sets would let you do this do, and they do solve for printing
<jarhar> bkardell: maybe we should go back to that
<jarhar> gregw: david, was there anything to resolve on?
<bkardell_> ah sorry one more q
<jarhar> dbaron: i dont have a desired outcome, other than id like for people to look and give some feedback
<brecht_DR> q+
<jarhar> bkardell: you shared two examples where it would help, and they look very ammenable to this is just a display affordance
<jarhar> bkardell: the content should be good content in the pixel example that you shared
<jarhar> bkardell: i wonder if tabs panel set stuff, there are actually two different paradigms, very different that are about tabs, one is display affordance, and the other is browser tabs like application tabs
<jarhar> bkardell: there was a thought, no data behind it, but a good guess that it would be actively unhelpful if those things had if you made it super easy to do the design affordance thing, because people would use that when they should lbe using the other one
<jarhar> bkardell: im not aware of there being a similar thing for accordions
<jarhar> bkardell: it was helpful when we shared a list of 100, we could see this being a place where this would be used
<jarhar> bkardell: there was an example where this woul be bad for that, we could collect mroe and do a similar review
<jarhar> dbaron: i do want to collect some more, i need to notice them as i browse the web or get other ways to find them
<jarhar> bkardell: i have some accordions in our docs
<gregwhitworth> ack brecht_DR
<jarhar> brecht: there was talking about combining the idea for tabs and accordions
<jarhar> brecht : we should be careful with that
<jarhar> brecht: i liked scotts idea of builtin aria
<jarhar> brecht: sums up the entire idea of accordion. with tabs, theres a lot more aria attributes you have to add
<scotto> q+
<jarhar> brecht: accordions are - collapses are more common than a tab structure, which is why im wondering - a simple button with simple collapsability can already go a long way
<gregwhitworth> ack scotto
<jarhar> scotto: i want to reiterate that, i do like they idea of keeping this simple and not conflating too many ideas
<jarhar> scotto: for all my comments so far, i do think that this is a good way to reuse existing elements
<jarhar> scotto: compeltely in support of making current html more robust
<jarhar> scotto: why i had that other proposal of take the wor, that was done for popover and provide the functionality for the button element and not promote that to the top layer
<jarhar> scotto: we have the same opportunity here, provides more choices in how people use this kind of stuff
<jarhar> scotto: making sure details is exposed to the ax tree - put the heading on the outside and the button on the inside
<jarhar> scotto: you dont have to have the content next to the triggering element, you could have additional divs for styling purposes
<jarhar> scotto: details summary is more guardrailed in how you can do stuff, for both better and worse
<gregwhitworth> q?
<jarhar> scotto: i like my alternate proposal of adding this to button elements so they dont have to use details summary

[gregwhitworth]

@dbaron does this need to stay open given the explainer has landed generally?

[dbaron]

I was hoping to use this issue for continued general discussion about the explainer -- and I was hoping to have another round of that discussion.

In particular, while there are two separate threads of discussion (details styling, and improvements to a11y of summary), I was hoping to share a status update (have a prototype in Chromium), quickly present some demos (hoping to share those tomorrow), and discuss next steps. (I think I've addressed the feedback from the previous round, though I want to go through a few lists of things again to check.)

[css-meeting-bot]

The Open UI Community Group just discussed Proposal for Exclusive Accordions.

The full IRC log of that discussion

<gregwhitworth> dbaron: I notice there aren't many people on the call today
<gregwhitworth> dbaron: one of the ideas behind this proposal; try and do some small things that we can do faster
<gregwhitworth> dbaron: and part of trying to do that; how fast is faster essentially
<gregwhitworth> dbaron: given the number of people I don't want to constrain this too much today
<gregwhitworth> dbaron: how much discussion should we have this in Open UI before we open an HTML PR
<gregwhitworth> dbaron: it's not going to get merged tomorrow
<gregwhitworth> dbaron: we should open it up to the wider group, probably next week when there are more before we do that
<gregwhitworth> q+
<gregwhitworth> bkardell_: asking preliminarily?
<gregwhitworth> dbaron: yes, relevant folks are here but will wait for next week
<gregwhitworth> chrishtr: in particular there were two areas to verify
<gregwhitworth> chrishtr: 1 - details and summary can be used as the basis of this?
<gregwhitworth> chrishtr: I want to ensure that we can and know of any blockers
<gregwhitworth> chrishtr: a11y and styling dimensions to that
<gregwhitworth> chrishtr: other than that - I think things are straight forward and has legs
<gregwhitworth> dbaron: I have been trying to make parallel progress on those other topics
<gregwhitworth> scotto: in regards to going quickly; I've brought up a number of things where it's footgun but with this specific effort
<gregwhitworth> scotto: doing something this useful and not addressing the underlying issues will be more widely used
<gregwhitworth> scotto: the a11y concerns will be there either way; they don't block your work
<gregwhitworth> scotto: there are some things we can talk about a bit more
<gregwhitworth> scotto: they already have an expand and collapse state that can open and close but what happens when you're in this grouping that can close something that is no longer functional
<gregwhitworth> scotto: do we need to add in a disabled state that currently isn't present
<gregwhitworth> scotto: is it inset and mappings that can be updated of X number things that are toggle buttons
<gregwhitworth> scotto: I'm on the first of 1 of N and it's expanded so I know the others are not
<gregwhitworth> scotto: and that can be done relatively quickly and defer to Aaron on speed of mappings to get into the platform
<gregwhitworth> scotto: the a11y content model issues with details and summary will always remain; I don't know how much we can fix these things
<gregwhitworth> chrishtr: are there some that are not fixable with any design, or legacy?
<gregwhitworth> scotto: a little bit of both
<gregwhitworth> scotto: I've seen accordions where there is a primary trigger and then a paragraph that comes after that with "more...." that can be expanded/collapsed
<gregwhitworth> scotto: if I have a "heading" and follow that up with a paragraph and a table all of that becomes the a11y name for this control and people can and do this
<gregwhitworth> scotto: significantly change how this is constructed because "ALL" of it is the trigger
<gregwhitworth> chrishtr: sounds like you want some additional text that is visible to improve the a11y name
<gregwhitworth> scotto: that doesn't need to get in the way to make details summary into an accordion
<gregwhitworth> chrishtr: I think that could be addressed with a child of details
<dbaron> chrishtr: summary-subheading or whatever
<gregwhitworth> scotto: yes, there are things that need to happen now, no but how do we push this forward?
<dbaron> Scribe+ dbaron
<gregwhitworth> bkardell_: I was just going to mention to put the toggle button on the agenda today?
<gregwhitworth> chrishtr: we've discussed that one
<gregwhitworth> chrishtr: dbaron do you want to discuss why you think this is better
<gregwhitworth> dbaron: some of the toggle button stuff runs into the issues we faced with CSS Toggles
<gregwhitworth> dbaron: one thing that does some showing/hiding of content but you don't know what kind of thing it is so you can use it for multiple widgets and maybe those things should be distinguished?
<gregwhitworth> scotto: the issue that I take with that is that the same thing could be said of details/summary
<gregwhitworth> scotto: they can be strung together to make a tree component
<gregwhitworth> scotto: the only thing that it can't be done is a typical tab solution
<gregwhitworth> scotto: it is limiting in some of the layouts that you can do because you HAVE to have a summary inside of your details
<gregwhitworth> scotto: the toggle button was done with popover but it would not be about promoting something to the top layer and rendering it to the DOM
<gregwhitworth> scotto: the open/close hamburger thing it doesn't need to be top layer
<gregwhitworth> scotto: a lot of problems with details/summary and their current mappings are completely bypassed because you can have a button inside of a heading but with a summary it can be screwy depending on if it is in a summary
<gregwhitworth> scotto: I wasn't saying that that toggle has to be involved in details/summary but it was a primitive to build with
<gregwhitworth> bkardell_: but if in history we did a toggle button, we would be in a different place
<gregwhitworth> scotto: it's a basic piece that could be used as a building block to build a lot of other components
<gregwhitworth> scotto: with the whole popover thing is that no one could explain what it was because it could be so many different things when we created it first as an element
<gregwhitworth> scotto: the button already has is to have HTML & ARIA and it's been over a decade of this and it hasn't come to pass
<gregwhitworth> scotto: it seems to have a button to be able to toggle content but haven't added it to the platform
<bkardell_> q+
<gregwhitworth> ack gregwhitworth
<gregwhitworth> chrishtr: the other core question we had, are there things that are not fixable about details & summary with work; and we don't think they're un-fixable
<gregwhitworth> scotto: yeah, I think that's largely true
<gregwhitworth> scotto: I mean, unpopular opinion, HTML being very permissive has cause many a11y issues whereas if they were more strict so there is no way that we can stop people from putting things inside the summary element, so that's always going to be there
<gregwhitworth> scotto: it was more important to render something than break
<gregwhitworth> chrishtr: right, even a new element would have that issue
<gregwhitworth> chrishtr: let's put them on the roadmap and get them filed and the Chrome team will prioritize those to get them fixed
<gregwhitworth> chrishtr: please enumerate them
<gregwhitworth> chrishtr: I dropped them into the doc that you shared; if you want me to sync up and clean up the doc
<gregwhitworth> dbaron: it's useful but I did some other things yesterday afternoon
<gregwhitworth> bkardell_: just wanted to say that um, I get why we want to go really fast and a relatively easy one; it's pretty light on a lot right now
<gregwhitworth> bkardell_: I will see if there are any issues that I feel like opening or not
<gregwhitworth> bkardell_: do you have a fork of HTML that you've been working on with these ideas
<gregwhitworth> dbaron: no
<gregwhitworth> bkardell_: so what you're asking is "should you start the HTML PR fork?"
<gregwhitworth> dbaron: yes
<gregwhitworth> bkardell_: I think yes, because when authoring them you end up finding issues
<gregwhitworth> q?
<gregwhitworth> ack bkardell_
<gregwhitworth> chrishtr: this isn't about speed but being incremental
<gregwhitworth> dbaron: I should add, the doc I shared with Scott is for it to turn into explainerish and we should leverage it to fix all of the a11y issues and solutions to them
<gregwhitworth> chrishtr: bkardell_ and scotto you both have by far provided the most feedback on this so I want to ensure you're in alignment
<gregwhitworth> scotto: yes, they do it already it just makes easier and it's not something they won't experience today
<gregwhitworth> Zakim, end meeting

[css-meeting-bot]

The Open UI Community Group just discussed Exclusive Accordion.

The full IRC log of that discussion

<gregwhitworth> Topic: Exclusive Accordion
<gregwhitworth> github: https://github.com//issues/725
<gregwhitworth> q?
<jarhar> dbaron: we had a call with 5 people last week and im trying to remember the overlap with the 10 we have today
<jarhar> dbaron: last week i said that the idea behind exlucisve accordion was to try to do something that is smaller and simpler and at the same time to be able to move faster
<jarhar> dbaron: and thus sort of in the spirit of moving faster i was thinking about when is this ready to go and try to make a pr against html
<jarhar> dbaron: i think that maybe one of the things that came out of last weeks discussion was maybe try to put up a pr even if i dont think its ready to be merged in a week or two
<jarhar> dbaron: it might be worth writing the pr because doing so will uncover some additional issues
<jarhar> dbaron: some of what i wanted to ask is what do the folks here think
<jarhar> q+
<jarhar> dbaron: what do you think needs to happen
<masonf> q+
<jarhar> greg: scott and i were on the call, chris and brian were on the call, everyone else were not here
<gregwhitworth> ack jarhar
<scotto> q+
<gregwhitworth> jarhar: my thoughts are, on one hand you'll get feedback; no question
<gregwhitworth> jarhar: it will be helpful but if they don't know enough about it already they may not look at it for a while
<gregwhitworth> jarhar: I just opened a PR and I only got one comment about comments and issues from popover to go down before reviewing the PR for anchor
<masonf> q?
<gregwhitworth> ack masonf
<jarhar> masonf: im sympathetic to what joey just said
<jarhar> masonf: the next step i think is an html pr
<jarhar> masonf: it has to happen eventually, it will get zero attention until it has a pr
<jarhar> masonf: i think yeah lets put up a spec pr
<gregwhitworth> ack scotto
<jarhar> scotto: i agree with the spec pr and per what was just mentioned, that would probably get reviewed since its not popover
<jarhar> scotto: they cant say well fix popover first
<jarhar> scotto: repeating points from last week
<gregwhitworth> minutes from last week that has Christ H. and Brian's comments: https://www.w3.org/2023/05/25-openui-minutes.html
<jarhar> scotto: only concerns that i mentioned last week were related to some lingering issues with details summary in general
<jarhar> scotto: those should not necessarily be blockers for moving ahead with this
<jarhar> scotto: my concern was that new features added to details summary would increase their usage and thus further
<jarhar> scotto: promote or add potential issues for details summary
<jarhar> scotto: if someone is like i can use details summary now for this, but didnt know about the issues with this elkement, but they are separate concerns
<jarhar> scotto: i see that david is already working on fixing those
<jarhar> scotto: if we could work on them separately that would be great
<jarhar> greg: chris and brian echod what everyone has said so far today
<jarhar> greg: brian recommends opening a PR because when authoring the spec you find issues
<jarhar> greg: im hearing yes, please go open a PR
<jarhar> greg: or at least write the spec
<jarhar> greg: do you need a concrete resolution?
<jarhar> dbaron: i dont think so
<jarhar> dbaron: a sense of the room is sufficient
<jarhar> greg: is there anything else you wanted to get?
<jarhar> dbaron: this is good
<gregwhitworth> Zakim, end meeting

[ZoeBijl]

What’s the user need for these exclusive accordions?

[dbaron]

I attempted to describe the user needs in the explainer.

[scottaohara]

i think the explainer might need to more overtly call out that the HTML PR to make exclusive accordions doesn't address the existing issues that are mentioned in the explainer.

That should probably be repeated in the user needs section, since bullets one (i think) and two (absolutely) are not addressed by the existing HTML pr

[ZoeBijl]

I attempted to describe the user needs in the explainer.

To be honest all I see there are developer needs.

keyboard shortcuts and focus handling,

With the complexities around keyboard support for tabs I kinda doubt people will pick up keyboard support for accordions any better.

exposure via ARIA to assistive technology, and

Can you explain how this would result in better communication of relevant information than either an <article> with a bunch of <sections>/<details><summary> inside?

integration with browser features such as find-in-page.

I don’t know enough about this to comment anything other than “that sounds good”.

On a separate note, the explainer mentions open questions for panelset:

The panelset proposal has enough open questions that it’s a bit hard to assess.

Given the similarities between the issues that panelset and this proposal are trying to solve—can you explain how this proposal answers/solves those questions?

Further questions:

• Why would the parsing of the open-attribute be any different from checked in radiobuttons?
• Has there been any user research into the usefulness of this pattern?

I’m not against adding name as an attribute for <details> though I wonder what, outside for exclusive accordions, the added benefit is to say wrapping them in a named <article> or <section>.

---

As an aside / personal opinion: exclusive accordions should die in a hellish fire; they deserve nothing more after all the frustration they’ve caused me and countless others—please let me see content when and how I want it…

[mikemai2awesome]

Regarding this section:

Accordions with exactly one item open

Some accordions (such as the one on the Pixel product page above) always have exactly one item open, and do not allow zero items to be open. (This could be called an exact-exclusive accordion.) This is a somewhat more complicated widget, because the open/close control disappears from the item that is open or becomes disabled. It’s not clear how such widgets could be modeled with this design, other than by ensuring that developer Javascript to handle this.

This is the only true accordion example from the research. Everything else is just grouped disclosures (each item can expand or collapse), meaning multiple summary/details inside a section or group already describes it precisely, nothing new needs to be created.

If we were to create something new, then it should be this thing that "has exactly one item open, and do not allow zero items to be open", and the screen reader announcement for such a thing should be using the "selected" language rather than the "expanded | collapsed" language, because you cannot collapse the current item.

[accessible name], selected, 1 of 3

Screen reader users are already exposed to this "selected" language with Tabs and Radio Inputs, where similarly you can only select 1 at a time and you cannot collapse it.

[yatil]

This seems to be shipping in Chromium and Safari TP. Without the affordances for users to overwrite this behavior, which is actively introducing an accessibility barrier to the web. Users with memory issues will have a harder time, screen reader users don’t have (optionally) access to all headings on a page. Currently, they can opt to open all details elements at once. Removing this feature for users on the author’s behalf makes the web less accessible.

Please make sure that none of this ships until there has been a proper feature set that allows for accessibility for all users of the web. It’s extremely disappointing to see the web community actively building barriers into the platform. The rollout of exclusive accordions must be stopped now.

[lukewarlow]

@yatil the roll out of this feature is down to the specific browser vendors so raise bugs in the appropriate venues if you consider this a show stopping issue.

[lukewarlow]

I'm going to go ahead and close this issue out as the OpenUI aspect of this is done. We have an explainer and implementations. If people want to discuss with OpenUI specific issues or extras with the proposal feel free to file specific issues.

[yatil]

@lukewarlow So, just so I understand what OpenUI does: It lets individual vendors create explainers without any accessibility oversight or discussion or even specifying user needs in the user needs sections and when those vendors go ahead and implement those untested, non-discussed features, then it’s just the way it is? Good to know, I guess.

[lukewarlow]

@yatil No that's not at all what OpenUI does but we don't have control over when vendors decide to ship functionality. So commenting here to stop the rollout isn't effective.

As said above please raise an issue to discuss your specific concerns if there's something you think OpenUI can help you with, we can discuss accessibility affordances. @scottaohara may be able to provide more context around that as I wasn't involved in the exclusive accordions effort.

It's worth noting that this isn't just implemented by the specific vendor that proposed it either.

[MattWilcox]

Can I suggest that you make accessibility your problem? This is unacceptable. If there is a clear problem in the blueprint being provided for others to implement, it is not then the implementors problem when they implement your blueprints.

This is a bad blueprint with not enough thought behind it. It is harmful. Please consider how this happened and how to avoid this again. This proposal does no one any favours. No one.

[yatil]

Considering that OP is a vendor employee, and I’m just a mere freelance person with no power at all, this seemed to be the correct avenue to comment. And yes, I expect from anyone contributing to the web to do their accessibility homework.

[dbaron]

I'm trying to follow up on the a11y issues in other (smaller, more focused) issues. I don't currently consider the work on the whole feature done, although @lukewarlow is probably right that remaining work doesn't belong in the Open UI CG (which exists to incubate ideas, not standardize all the details), but rather in some combination of WHATWG HTML issues and discussions on appropriate a11y specs (e.g., HTML-AAM or ARIA).

I'd also note that one aspect of the design here is that maintenance of HTML tends to be one of the most conservative web specifications regarding design of new features. This is at least partly by design, since lots of people want to add things to HTML. But in general, if you want to add a new thing to HTML (say, exclusive accordions) that has a decent resemblence to an existing thing in HTML (say, radio buttons), it's going to be a very uphill fight to make the new thing different from the existing thing unless there's a well known and well documented set of problems with the existing thing that the new approach fixes.

[lukewarlow]

To clarify I simply meant the proposal this issue is for has been accepted into openUI and an explained landed and implemented so this (aka bringing a proposal forward) is done.

As for follow up work I think open UI can play a role but as you say WHATWG etc might be better.

[cookiecrook]

@MattWilcox wrote:

Can I suggest that you make accessibility your problem? This is unacceptable. […] This proposal does no one any favours. No one.

and @yatil wrote:

And yes, I expect from anyone contributing to the web to do their accessibility homework.

Before responding on the technical merits of various arguments, and hopefully without seeming dismissive of commenters concerns, I'd like to request the conversation remain as objective and respectful as possible.

We're all very passionate about the Web Platform (I personally about its accessibility), but I'm reading emotion into a few responses, that even when warranted, doesn't usually lead to a productive solution. There have been multiple, documented, cases of specific members of W3C accessibility groups (thankfully neither of you) who have bullied other W3C contributors far beyond what I hope was their intention. (Behavior now mentioned in the W3C Code of Conduct linked below.) People get especially passionate about accessibility, since it is often interlinked with a personal connection to disability, so tempers flare (righteous anger perhaps) more than in other groups. We all need to be actively conscious to keep the discussion civil and respectful, without challenging each other's competencies or motivations. Thanks for considering.

I couldn't easily find an OpenUI-specific Code of Conduct, so I'll reference the W3C document instead:
https://www.w3.org/Consortium/cepc/#expected-behavior

Responses/Question to the technical concerns coming in a follow-up comment.

[cookiecrook]

Regarding some of the technical arguments @yatil raised:

Without the affordances for users to overwrite this behavior, which is actively introducing an accessibility barrier to the web. Users with memory issues will have a harder time, screen reader users don’t have (optionally) access to all headings on a page.

In response to the last point about SR heading navigation, I recall there is another existing issue for search (including accessibility search) within hidden contents of collapsed summary elements. So that issue (auto-expanding details) may be resolved in future updates using the native summary element. Note that the same problem cannot be solved with the myriad of custom accordions and disclosures that have been shipping for decades using headings hidden with display:none.

In response to the main issue, the primary value of OpenUI (and ARIA for that matter) as I see it is an acknowledgement that web developers have jumped through hoops for decades to create controls that are complex, and many times inaccessible. Even when the controls are possible to be made accessible (as with an ARIA retrofit), many web developers don't do it correctly. The OpenUI project (literally started with accessibility as one of its primary goals) seeks to make it easier for web developers to build these controls so that the browser engines can make them accessible without any extra work needed from the (sometimes ignorant, or sometimes unwilling) web developer.

Similarly, custom dialogs (mostly inaccessible) shipped for decades before the HTML Dialog API was available... Now it's easier for developers to use, and most accessibility bugs can be addressed by the rendering engine rather than putting the onus on the web developer to jump through hoops. (Aside: Truly accessible focus management of dialogs was exceedingly difficult; even the ARIA Authoring Practices doesn't get it right. It was just too difficult before inert shipped, requiring the capture phase of focus and blur event handling.)

The accordion pattern is in a similar state. Web developers have been using them for decades. Many times without any thought to accessibility... The ARIA Practices acknowledges this as a valid control type, and published an Authoring Practices guide for Accordions which from a usability perspective, is functionally equivalent to Tabs.

@yatil wrote:

Users with memory issues will have a harder time [using an accordion pattern]

I acknowledge that may be true, and guidance should be given wrt when they should not be used. For example, this User Experience Stack Exchange thread lists many mainstream considerations.

But ultimately it's going to be up to the web developer to decide what common UI pattern they choose, and this OpenUI feature takes an existing pattern and makes it more accessible than before for assistive technology users. As specific problems arise and are discovered, they can be made more accessible in the engine, rather than requiring the web developer or framework developer to update.

@yatil @MattWilcox If you still feel this pattern is an anti-pattern, do you also recommend ARIA APG remove the progressive disclosure patterns like Accordions and Tabs? If not, why not? Or what's the benefit you see in those that isn't even more beneficial in this OpenUI pattern for the same UI?

[yatil]

(I will not comment on the tone comment.)

If you still feel this pattern is an anti-pattern, do you also recommend ARIA APG remove the progressive disclosure patterns like Accordions and Tabs? If not, why not? Or what's the benefit you see in those that isn't even more beneficial in this OpenUI pattern for the same UI?

I think patterns that are beneficial should be put in HTML. The issue is not with having or not having exclusive accordions.

The question is about having exclusive accordions that are now much easier to implement because they are a native part of the web, but without any fixes for people with accessibility needs.

Browsers must provide those overrides to allow affected users to bypass them, if it gets into the native web platform.

It makes a huge difference if a pattern is native to the web. We still have terrible inaccessible date and time picker when it was done last time.

And yes, I think if tabs go native, browsers should give users options to see all tabs linearized, for example.

That this stuff is hard, of course it is. We have the responsibility of doing the hard things. And the hard things mean having a proper wide accessibility review. Sure, it is convenient to have a new HTML feature hammered out in 9 months, but this ”move fast, break things” mentality is not the correct way for the web. We cannot afford to break things, because things stay broken (see date/time inputs).

Yes, exclusive accordions are a bad pattern when implemented using JavaScript and when implemented using native features. But when we implement them natively, we should also agree to empower users to soften the worst impacts of this. That there is apparently no consensus on this and “we provide developer information” is the best the group could come up with is sad.

Edit: Anyway, I blogged my view earlier, and I’m now at peace with whatever happens. I personally don’t need any discussion around this.

[cookiecrook]

Okay. Glad to know we agree on several of the sticking points, and that the details are being worked out in other open issues like #925 and w3c/html-aam#509.