[accordion] UA ability for user to over-ride exclusive accordions functionality

[gregwhitworth]

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.

Originally posted by @yatil in #725 (comment)

[gregwhitworth]

Pulling in @dbaron response from #725 here

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.

@dbaron since there are people interested in the Open UI community on having these accessibility issues solved can we have a top level issue that tracks them so that we can burn them down to completion (this may be an issue in WHATWG, here, etc)

With regards to the request in this issue, @yatil you mentioned user research in discord is any of the user research that you've done publicly available or a summary of the findings? If not, no worries I think it would be helpful to drive UA's toward a solution.

@yatil can you clarify something for me in this comment and apologies for my ignorance:

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.

Who is they in this context? I presume the end-user, and is this via a specific AT?

[aardrian]

Some of this conversation is ongoing at w3c/html-aam#509.

I agree this should have been sorted here before making it into the WHATWG HTML specification and I feel it now needs to be sorted at WHATWG HTML (not HTML-AAM) since it is already in the spec.

Anyway, maybe wrap all this up and make one issue/PR at WHATWG HTML or contribute to whatwg/html#9899?

[yatil]

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.

Who is they in this context? I presume the end-user, and is this via a specific AT?

Users. All of them can opt to go through every details element and open each one after the other to see all content.

Regarding research: We did it when we worked on the W3C/WAI redesign, and it was pretty informal. No idea if that is available somewhere.

Here are some Nielsen Norman articles that go into it (emphasis theirs):

Using accordions on a content page can hinder users’ ability to access information from different content blocks. When a user needs to access information from most or all accordions, it can become tedious to have to expand each of them. Excessive clicking interrupts people’s interaction with the page. Forcing users to interact with each panel individually to access the information can lead to a loss of context when important details are scattered across different panels. Users may have difficulty connecting related information from different sections on the page.

This problem can further escalate when an accordion automatically closes when another is opened, restricting users’ ability to combine information from multiple accordions at the same time. If you expect users to need information from several accordions at once, it is better to display all the content at once (even if it results in a longer page).

from: https://www.nngroup.com/articles/accordions-on-desktop/

See also: https://www.nngroup.com/articles/accordions-complex-content/

[YummyBacon5]

UA ability for user to over-ride exclusive accordions functionality

I don't think that this should be added. Since the result of #786 was that they should always be exclusive. This would basically reverse that change - and may break authors' pages.

If authors want their accordion to 100% always be exclusive. Then they may implement their own accordion. Which could be inaccessible.

And if this was going to be added, then a preference of users wanting to override this should be available to JS, for custom accordions.

[yatil]

If authors want their accordion to 100% always be exclusive. Then they may implement their own accordion. Which could be inaccessible.

Exclusive accordions are ALWAYS inaccessible. The exclusiveness makes it… exclusive. There is no inclusive accordion that is exclusive like there are no wheel-chair accessible stairs. It is an oxymoron.

[lukewarlow]

Since the result of #786 was that they should always be exclusive.

@YummyBacon5 the key difference here Vs what was discussed there is who's making the decision. That was around various authoring scenarios and how browsers handle them. This would be a user choice to say I don't care what the author wants, user choice coming above author choice is correct.

[aardrian]

I don't agree that exclusive accordions are always inaccessible. I agree they have their challenges and are generally handled in better ways (usually by not using accordions). NNG does a good job outlining those challenges.

Incidentally, those challenges correspond to tabs / tab panels. I would urge everyone to read those two articles and replace "accordion" with "tabs" and decide for themselves if and how they correlate. Then consider maybe what lessons we have (or haven't) learned as a result and/or can apply here.

More importantly for the scope of the web platform, accordions exist in the wild already (for decades).

We can either let them continue to be implemented inconsistently (and definitely inaccessibly) using assorted frameworks and libraries that over-burden users, or we can do our best to specify a least-bad baseline.

Part of our role as accessibility practitioners is to ensure existing patterns are at least as accessible as we can make them, while also urging clients (devs, stakeholders, people named Frank, etc.) to move to better paradigms and patterns.

All that said, I am in favor of:

1. OpenUI having a stronger commitment to accessibility in its proposed patterns (before pitching to WHATWG HTML),
2. and this conversation focusing on solutions and risks to the very real fact that devs are already building accordions whether or not WHATWG HTML specifies it.

[Edited to break that last paragraph into a numbered list because my run-on sentence confused me when I came back to read it and likely confused others as well, kinda like this one is doing right now]

[yatil]

I don't agree that exclusive accordions are always inaccessible.

There might be use cases where the impact is lessened, but I have never observed a user who was glad that they could only see one piece of information.

And yes, these accordions exist. And yes, building them on this common pattern makes sense. But to make it worthwhile for users, there should be a way to lessen their impact.

[aardrian]

There might be use cases where the impact is lessened, but I have never observed a user who was glad that they could only see one piece of information.

I have, but those were on awful overloaded pages where the accordion was thrown at it versus an IA overhaul (users with dyslexia, ADHD, anxiety benefited from them). Typically screens with financial bits.

And yes, these accordions exist. And yes, building them on this common pattern makes sense. But to make it worthwhile for users, there should be a way to lessen their impact.

My sad effort to try to flesh out some ideas here to maybe then port over to WHATWG HTML:

1. Do you believe allowing users to override displaying only one a time is the only approach?
2. Might devs just fall back to problematic tab patterns (which do not allow for overriding their exclusiveness)?
3. Is there guidance that can be folded in that says these should restricted to specific use cases (knowing authors are gonna author)?

[yatil]

I don’t know the answers to this question. One would need to research this. I don’t know if WHATWG is the right venue for this, considering it’s a User Agent feature.

Do you believe allowing users to override displaying only one a time is the only approach?

I also mentioned an expand all/collapse all functionality which should exist for non-exclusive details anyway (IMHO). But I don’t know if this is functionally different.

Might devs just fall back to problematic tab patterns (which do not allow for overriding their exclusiveness)?

We both know that developers often use bad UI. And I’m a realist when I say I want devs to have this functionality. Give it to them. But also allow users to see all content. Bury that functionality somewhere if needed to make developers (and project managers) happy. I know that this is most important. It works for autoplaying video, something similar should be available here.

(I think users should have the option to linearize tabs, too, but that is another discussion. I will raise that issue when native tabs are introduced to the web platform. Also, if the user has the option to set the behavior for these accordions, they could decide that they only ever want one open at all times. User control is a good thing here.)

Is there guidance that can be folded in that says these should restricted to specific use cases (knowing authors are gonna author)?

My general advice has been to structure the content in a way so that accordions are not needed. And I have worked for W3C/WAI, which is basically a site littered with expand/collapse texts. So I know the struggle with legacy content or with editors who insist to use a specific structure.

---

I don’t think any of my responses have been helpful, and I really apologize for that. I should probably not have brought it up and cause a stir. I’m sorry.

[jimmyfrasche]

I hate accordions (and tabs). [Most of the time—I've seen them both used well but that's the exception not the rule]

The primary benefit to me of native accordions is that it'll be easy to write a bookmarklet to break them by removing the name attribute. That will be easier than opening the same page in multiple windows or popping open dev tools to break things.

If I could, say, middle click to open a pane without the others closing that would save me from adding another bookmarklet to my fix folder.

[aardrian]

Numbered and excerpted for my benefit...

1. I don’t know the answers to this question. One would need to research this.

Fair enough. It was a loose question so I am open to others answering with ideas too.

1.b. I don’t know if WHATWG is the right venue for this, considering it’s a User Agent feature.

At the very least, WHATWG HTML may need to identify what the parsing/exposure rules are when the feature provided by using the name attribute is disabled. For example, keep enumeration, grouping, etc., but also expose all as open versus just exposing the first as opened to platform APIs.

2. We both know that developers often use bad UI. […] I think users should have the option to linearize tabs, too, but that is another discussion. […]

It might be worth pursuing both (accordion and tab linearization strategies in UAs) in tandem to help ensure UAs approach it consistently and authors are not motivated to choose the wrong pattern just to get around an affordance.

3. My general advice has been to structure the content in a way so that accordions are not needed. […]

That might indeed be the best and most straightforward advice. WHATWG HTML might need to be a almost prescriptive in other patterns / approaches to use (which, IMO, it already does so there is precedent).

I don’t think any of my responses have been helpful, and I really apologize for that. I should probably not have brought it up and cause a stir. I’m sorry.

My questions were not exactly insightful either. And there is no need to apologize. Accessibility advocacy is typically a function of many prior lost battles and wounds. These are human outcomes for which we are trying to solve, not just minor linter-level code preferences. Frustration is, unfortunately, part of that and sometimes it oozes out.

[lukewarlow]

https://jsfiddle.net/qv2b5o03/ - I had a quick attempt at misusing exclusive accordions for a (mostly) JS free tab implementation last night, requires Chrome canary to work. But the accessibility mappings all seem to work correctly (Tested on Android and macOS) and I thought it was worth bringing up here as something that would break if exclusive accordion behavior was disabled.

Not arguing whether this is a good UI pattern but it is one and if I worked it out others probably will so just something to consider for the conversation.

[aardrian]

@lukewarlow Other than a novel experiment/gag (one which others have also parodied), I am not sure yet another defailts/summary mis-use (which will absolutely happen in the wild) is a sufficient argument for or against the exclusive accordion pattern.

[lukewarlow]

It's certainly not a gag? it's me attempting to see what this pattern allows and while tbf I said misusing, if it's fully accessible (fair enough if it doesn't work with jaws or something else I can't test those) is it really misusing?

I'm also not arguing for or against I'm just saying this is possible and an override would break it. It's important to consider all use cases when coming to a decision.

[YummyBacon5]

is it really misusing?

In terms of what HTML says about what different elements mean semantically, then yes

[aardrian]

It's certainly not a gag?

Oh, my apologies. I sincerely thought you were having fun with me.

It's important to consider all use cases when coming to a decision.

1. I agree, and unfortunately it seems that did not happen when exclusive accordions were originally specified;
2. Mis-use is not a use case, but now I understand you were making a point.

Regardless, does that give you some insight into how (or if) that kind of expectation should be qualified within the spec? Or with UAs?

[lukewarlow]

In terms of speccing / guidance surrounding a UA override potentially the UA override only applies to details elements with their standard group role?

Thus handling this use case.

Again just an idea not sure if that's good or bad.

[aardrian]

In terms of speccing / guidance surrounding a UA override potentially the UA override only applies to details elements with their standard group role?

It's an idea, though the group role is likely not happening. The name attribute matching would be it. But since that would exclude exclusive accordions (heh) I don't think that hits at the meat of what Eric suggested.

Maybe just a blanket UA "expand every details/summary" command with the appropriate warning that it will break some pages (particularly those that use AJAXy requests that expect certain states/properties otherwise they fall down).

In which case it becomes a feature request of Mozilla, WebKit, and Chromium, and not a spec edit.

Or am I over-simplifying?

[lukewarlow]

Yeah this comes back to my original response that I don't know if this sort of request is within the scope of what HTML can mandate. (For the record I think specs should have more power to say hey actually do this but alas)

We'll discuss on the call later and then we'll have a more concrete understanding.

[css-meeting-bot]

The Open UI Community Group just discussed [accordion] UA ability for user to over-ride exclusive accordions functionality.

The full IRC log of that discussion

<jarhar> gregwhitworth: we had a comment by eric on discord as well as a few comments in the issue, we should discuss it, scott and i have been going back and forth
<jarhar> gregwhitworth: for context: they arent super thrilled about exclusive accordions rolling out in browsers
<jarhar> gregwhitworth: they arent seeing them done effectively from an accessibility standpoint. they requested a proper feature for accessibility - the capability to make them non-exclusive
<jarhar> gregwhitworth: i will throw out two options: if devs use exclusive accordions that they should have a toggle somewhere in the settings for the site
<jarhar> gregwhitworth: the other one is ua specific uis in settings
<bkardell_> q+
<masonf> q+
<jarhar> gregwhitworth: its not bad that we should add "shoulds" into the whatwg specification, presuming the folks on this call who have done user research or accessibility testing of exclusive accordions can stand by the negative ax implications on end users in certain scenarios
<jarhar> gregwhitworth: thats topic one, we dont have to get into the second topic which is about some key principles of our group
<jarhar> gregwhitworth: when we are adding primitives onto elements which we may already have ax issues on
<jarhar> gregwhitworth: lets just talk about one and i will spin up a separate issue for the second one
<Luke> q?
<gregwhitworth> ack bkardell_
<Luke> q+
<jarhar> bkardell_: a couple things i wanted to say about this. first is that a bunch of the issues that were mentioned were things that we already mentioned when we were doing spicy sections version of this. i think that those are still relevant and i would like us to get at them
<jarhar> bkardell_: there was a comment in here about the concerns if exclusive accordions as those with tabs
<jarhar> bkardell_: and you need the ability for users to have some degree of control with that
<jarhar> bkardell_: if you look at them in this way then you could give users a way to prefer something be exposed as a control or not
<jarhar> bkardell_: that can equate to things like printing
<jarhar> bkardell_: i agree with a lot of things in this issue
<jarhar> bkardell_: wanted to say that we were pretty clear that there are a whole list of issues we have solved before it lands
<jarhar> bkardell_: but thats an interesting point that this group doesnt contorl what lands before what
<scotto_> q+
<jarhar> bkardell_: so what do we do about that? thats tricky
<jarhar> gregwhitworth: thats what i was saying i should spin up a second issue about that
<jarhar> gregwhitworth: i just want to be crisp about the resolution im going for: do we agree that openui should be putting things in explainers, what can we do in this area. or, the resolution is that openui isnt able to resolve this space
<gregwhitworth> ack masonf
<bkardell_> I suppose we could have just blocked the proposal based on the summary/details thing
<jarhar> masonf: certainly these are good issues, important things. the tone of the issue sounds like we should roll this thing back because exclusive accordions are bad for accessibility. my counterpoint is that we are not inventing exclusive accordions. people will build those with javascript and we cant make them accessible
<jarhar> masonf: by introducing this to the web it is possible to make them accessible by adding a browser setting that says ignore the name attribute
<jarhar> masonf: browser-wise this is trivial
<jarhar> masonf: maybe thats the best resolution
<jarhar> masonf: unshipping is unproductive
<jarhar> masonf: other issues with details summary were pre-existing, we did not change them with the name attribute. we are working on them actively
<jarhar> masonf: its hard enough to land anything in whatwg, that it makes sense to break it up into small pieces
<jarhar> masonf: if you put together too many things then it wont land and we get nothing
<jarhar> Luke: i think that mason touched on an important point. this doesnt introduce a new capability for developers, they can already use javascript and we cant add a way to make them accessible. removing it doesnt serve a purpose, would just make it worse
<jarhar> Luke: with regards to user override setting, thats probably a good solution
<jarhar> Luke: ive created a demo which uses this to create tabs, and it is accessible as far as i can tell
<jarhar> Luke: so thats something that people could do, and if we give them a way to disable it that could break tabs
<gregwhitworth> q?
<gregwhitworth> ack Luke
<jarhar> Luke: having said that, the most openui can do or whatwg can do is suggest that user agents do specific things, we cant mandate them
<gregwhitworth> q+
<jarhar> Luke: its more down the line of put strong suggestions in explainers and specs and hope that browsers implement them if they deem them necessary
<jarhar> Luke: i dont think this is in scope of what openui or whatwg can mandate
<bkardell_> Can you share your tabs thing Luke ? That sounds like it wouldn't go well to me because there are things that don't align interaction-wise?
<jarhar> scotto_: big +1 to everything that mason said. keeping this in scope of openui, maybe prior to a pr being merged for something that was originated here, a stronger signal for final review could be made?
<Luke> https://jsfiddle.net/qv2b5o03/ - requires Chrome Canary with experimental flags
<jarhar> scotto_: i didnt know that this was merged until i got the html aam issue to say we merged this, now what are the mappings
<masonf> q+
<gregwhitworth> qq+ masonf
<jarhar> scotto_: only flaw i saw with this process, there was still this open question but it was merged, and i could have done a review of the content that was in there and i didnt see it until after the fact, so i just opened a new issue to update the stuff thats in there
<gregwhitworth> ack scotto_
<jarhar> scotto_: maybe thats the only thing that we could do here in openui, before this goes into the spec we should make sure that all interested parties know
<gregwhitworth> ack masonf
<Zakim> masonf, you wanted to react to Luke
<gregwhitworth> ack masonf
<bkardell_> Luke: have you tried tabbing through this?
<jarhar> masonf: thats a good point. weve discussed some things here, but its also litigated in whatwg and once we got that done we landed it
<jarhar> masonf: having said that, as we know we can still modify the spec. if there are further changes we can make, we should make them to the spec
<jarhar> masonf: luke mentioned that we cant mandate settings
<jarhar> masonf: spec should say that there can be a ua override of that feature
<jarhar> gregwhitworth: thank you for some of the solutions, especially that last one mason, what you summed up luke is correct and thats what i wanted to propose resolution, that we would update the openui specification
<jarhar> gregwhitworth: i want the pr of whatever we update our explainers with to definitely be reviewed by ax folks
<jarhar> gregwhitworth: im not discounting erics position, but i know from working on edge that doing user research has a ton of different perspectives on what is accessible and what is not
<jarhar> gregwhitworth: i dont want to rush the new thing forward
<gregwhitworth> Proposed Resolution: Update the Open UI explainer and subsequently the WHATWG specification to allow user agents to disable the functionality of exclusive accordions
<jarhar> gregwhitworth: this should be a note in openui, for these reasons. i dont have the right text to put in the resolution
<jarhar> gregwhitworth: i dont know who that would be to update the text/spec
<jarhar> gregwhitworth: that would probably be you david?
<jarhar> dbaron: sorry i missed a bunch of discussion, was in another meeting
<jarhar> gregwhitworth: eric recommendation of there being a ua setting makes complete sense, and its probably the simplest path forward
<jarhar> gregwhitworth: the other thing that was raised is that we need to be thinking about tabs as well as exclusive accordions, do they get the same setting?
<jarhar> gregwhitworth: the only thing that openui can do is update the explainer as a note or something
<jarhar> gregwhitworth: right now it is a "must" requirement in whatwg, and we need to add language that enables a user agent to say that it isnt a must
<jarhar> gregwhitworth: i dont know how you do interop testing of it working and not working
<jarhar> dbaron: i guess im not happy with that resolution
<jarhar> dbaron: i dont know what this setting looks like. if its a thing thats going to be discoverable to users who need it and/or want it, and/or going to discourage authors from using the feature
<gregwhitworth> q+
<masonf> q+
<jarhar> dbaron: to what extent does what the setting looks like discourage people from using the thing in the first place? how do you explain a setting like this that is explainable to users
<bkardell_> q+
<jarhar> dbaron: here is how to mess with the internals of one thing in html
<jarhar> gregwhitworth: browsers have ui/ux experts, they could go off and do this
<jarhar> gregwhitworth: technically a browser could do this and this gives them the freedom to do this
<jarhar> gregwhitworth: going back to the years doing research in the past, its an important subset but a small subset
<jarhar> gregwhitworth: im looking to ui and ux experts who work on the chrome of the browser to figure out how that would function
<jarhar> gregwhitworth: to a large majority of the populus, they would still get accordions and tabs
<jarhar> gregwhitworth: we are not here to try to prescribe what a good ui would mean in a given context
<jarhar> gregwhitworth: what would that look like in the vision pro or a hololens
<gregwhitworth> ack gregwhitworth
<jarhar> gregwhitworth: this just gives the flexibility that a user agent could
<jarhar> masonf: i roughly agree with what greg just said
<jarhar> q+
<bkardell_> https://github.com/tabvengers/spicy-sections/issues/37
<jarhar> masonf: they need to be discovered by the people who discover them
<jarhar> masonf: it does change the behavior of web content - forced colors and font size changes, but it does not discourage developers from using these features
<jarhar> masonf: i would hope that theres a reasonable expectation that this would change the way pages look but also make them more accessible
<bkardell_> q-
<bkardell_> +1
<gregwhitworth> ack masonf
<gregwhitworth> ack jarhar
<jarhar> masonf: i roughly agree with what greg said, we could phrase this in a way that helps users unerstand what theyre going to do
<gregwhitworth> jarhar: I'm not following this super closely
<gregwhitworth> jarhar: if we put it in the spec that the name attr won't do anything?
<gregwhitworth> jarhar: does that change what they do?
<scotto_> q+
<gregwhitworth> q+
<Luke> q+
<masonf> q+
<gregwhitworth> ack scotto_
<jarhar> scotto_: i didnt say something before that i want to mention, and i want to respond to ua settings too
<jarhar> scotto_: i think eric did acknowledge that saying that exclusive accordions is not true. it all comes down to context and how its used, and thats where the spec could be updated: this should be used for this reason, but not for this other one. author guidance
<jarhar> scotto_: but then for those that then do still want to turn off this feature, i dont think it should be really that much of an authors concern if someones going to do that
<bkardell_> q+
<gregwhitworth> ack gregwhitworth
<jarhar> scotto_: users can turn on high contrast modes, and all those colors that designers stressed about getting perfect, theyre all gone
<jarhar> scotto_: people can add their own stylesheets, there's plugins to do this
<jarhar> scotto_: stylus has a million downloads and is how people implement text spacing rules
<jarhar> scotto_: why people have media queries
<jarhar> scotto_: we have general ideas of how people interact with our websites, but people dont have to and they have browser extensions
<gregwhitworth> q+
<jarhar> scotto_: people can turn on reader mode too, so why do anything
<gregwhitworth> Zakim, close the queue
<Zakim> ok, gregwhitworth, the speaker queue is closed
<jarhar> Luke: coming back to a resolution on this, we all agree that setting could be useful, but outside our scope to mandate it
<jarhar> Luke: update spec to allow it if they want to rather than always being exclusive always
<jarhar> Luke: the one difficulty with doing ui with the setting is that you could explain it that it disabled exclusivity, but then it wont work on all the ones out there that already use javascript
<jarhar> Luke: we should just update the spec to allow it
<gregwhitworth> q?
<gregwhitworth> ack Luke
<jarhar> Luke: as scott said we should also update guidance
<jarhar> Luke: update normative text with use cases, to stay away from bad use cases
<jarhar> masonf: i want to come back on a few things. so joey asked do developers need to know that this is going to happen, and the answer is no. you cant tell right now if forced color is on or what colors are being used or what font sizes are, and the spec doesnt have any mention that the ua might do somethjing different than what is specified, its just understood that uas can do whatever they want
<gregwhitworth> ack masonf
<jarhar> masonf: im wondering if we should change the spec at all
<jarhar> masonf: it does not have to be explicit for every feature in the spec
<gregwhitworth> ack bkardell_
<dbaron> I think this one is different in a substantive way.
<jarhar> bkardell_: i got in the queue when scott was talking, but he pivoted to what i was going to say - you want to ability to respond appropriately with styles
<jarhar> bkardell_: we thought of the same kind of things, and you would do prefers in a media query
<jarhar> bkardell_: luke also said something about exclusivity, and there are two different questions there
<jarhar> bkardell_: one is whether a thing should be exclusive, and another is whether it should be interactive at all
<jarhar> bkardell_: interactive is a speed bump, some authors might not prefer. might be a nice thing for readers modes to expand those
<jarhar> bkardell_: i wouldnt think about it like dont make it exclusive, but maybe dont make it interactive at all. or maybe you need both
<jarhar> bkardell_: if you make it non-interactive, they authors wont be confused about anything
<jarhar> bkardell_: if i dont interact with these then its the same nomatter what
<jarhar> masonf: i dont understand the dont make it interactive - like just make them heading content?
<jarhar> bkardell_: yes, theres a lot of clicking and you want to say no its hard for me so just expand them
<jarhar> bkardell_: i understand that people like to collapse things
<jarhar> masonf: were talking about the setting in the browser - it should just say expand them all?
<jarhar> bkardell_: im saying that both of those might be valid, but i think that the last one is simpler and is confusing to know - its not confusing in the way that luke said, but i think that the thing that luke said is true today. you cant tell which ones are exclusive in what way
<jarhar> bkardell_: i will go back to masons point that we are not making it worse, only better
<jarhar> dbaron: its not clear to me how much whats being proposed is an allowance to open more that one at a time or to make them all open an not interactive
<jarhar> dbaron: either one of those interventions is different from reader mode or forced colors
<jarhar> dbaron: all those other things were carefully designed so that the page still works
<jarhar> dbaron: either of these interventions is not doing that
<jarhar> dbaron: its doing it in a way that is like oh were going to reader mode this part of the page and hope that it still fits in whatever layout it was
<gregwhitworth> Zakim, open the queue
<Zakim> ok, gregwhitworth, the speaker queue is open
<jarhar> dbaron: im skeptical that this is going to produce good results
<jarhar> bkardell_: existing content for details name doesnt exist, so what do you mean?
<masonf> q+
<gregwhitworth> ack gregwhitworth
<jarhar> dbaron: i think were designing forced colors mode against not only already written content that didnt consider it as well as future content
<gregwhitworth> q+
<jarhar> dbaron: people writing sites today arent thinking about reader mode. reader mode is designed to deal with developers who didnt think about it
<jarhar> dbaron: these sorts of intervention, i havent seen an intervention like this be successful that requires developers to add another set to their testing matrix
<gregwhitworth> ack masonf
<jarhar> masonf: i would disagree that font size changes cant break pages. you will definitely find some strange layout, it goes non-workable
<jarhar> masonf: thats sort of understood, it would be better if that didnt happen, and i would guess the same is true for forced colors
<jarhar> dbaron: this is the second design for how user font settings should work, and the first one was thrown out
<jarhar> gregwhitworth: i feel like were solutionizing what the ua may or may not do, whether or not the primitive should or should not enable the capability
<jarhar> gregwhitworth: to masons point we were always interoperable to the spec and supported high contrast mode forced colors
<jarhar> gregwhitworth: it took a lot of effort to get it to the point where it works, and then we brought it to the standards
<jarhar> gregwhitworth: to masons point, the user agent can always do things on behalf of the user, i think we should still make the resolution because it doesnt say how the spec text should change
<jarhar> gregwhitworth: this theoretically could work, but yeah in some contexts it may work great but not others
<jarhar> gregwhitworth: i want to avoid solutionizing what the browsers should ship
<jarhar> gregwhitworth: all we can control is that exclusive accordions are enabled this way
<keithamus> q?
<jarhar> gregwhitworth: whatever way that browsers or users control this is not something that we have control over, and id like to scope down to that
<jarhar> gregwhitworth: prior resolution was allow uas to disable exclusive accordions
<jarhar> gregwhitworth: is that still necessary? looking at mason and david. do we still feel that this needs to be stated?
<jarhar> masonf: my weak opinion is that it doesnt need to. not every spec on the web has a thing that says the ua can do something different
<Luke> +1
<jarhar> gregwhitworth: second part that i added in is worth resolving on is that add author guidance on when to use or not use exclusive accordions. thats a little more tangible
<gregwhitworth> Proposed Resolution: Add author guidance on when and when not to use exclusive accordions
<jarhar> gregwhitworth: i dont know what those are personally
<jarhar> gregwhitworth: i will put that forward as the proposed resolution
<masonf> +1 but I'm not sure who is in the best position to write that guidance.
<jarhar> gregwhitworth: not saying it needs to happen this moment, but yeah im looking to the ax experts to provide such guidance
<gregwhitworth> Resolved: Add author guidance on when and when not to use exclusive accordions

[yatil]

Thanks to the CG for the open discussion.

[cookiecrook]

I commented on the other issue and more or less stated the same thing as @aardrian said here:

I would urge everyone to read those two articles and replace "accordion" with "tabs" and decide for themselves if and how they correlate.

and expounded on what @YummyBacon5 said here:

If authors want their accordion to 100% always be exclusive. Then they may implement their own accordion. Which could be inaccessible.

The OpenUI project seeks to make it easier for web developers to build these controls so that the browser engines can make them functional and accessible without any extra work needed from the (sometimes ignorant, or sometimes unwilling) web developer.

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.

As for whether there should be a user switch to disregard the exclusivity of this pattern, I think the auto-expanding details approach would be a better path forward.

[yatil]

As for whether there should be a user switch to disregard the exclusivity of this pattern, I think the auto-expanding details approach would be a better path forward.

Unsure how automatic opening of details when searching helps for having two details open at the same time. I guess I'm just not understanding things enough.

[cookiecrook]

Unsure how automatic opening of details when searching helps…

As one specific use case, one of your justification examples for why an override feature is necessary was ~"screen reader user needs to be able to navigate by heading, even if those headings are in collapsed sections."

Instead of needing to 1a) expand all, or 1b) change a user default, and then 2) navigate by heading, the auto-expanding details proposal would allow the user to just navigate by heading as they normally would.

[yatil]

Yes, Assistive Tech can help some users. It does not support users who do not use assistive tech.

[dbaron]

I created a PR at whatwg/html#10003 to try to address the action item here. Suggestions for improving the wording are welcome, and probably best there rather than here.

[dbaron]

Closing on the basis of the above PR being merged.