search

openui / open-ui

Maintain an open standard for UI and promote its adherence and adoption.
https://open-ui.org
Other
3.48k stars 186 forks source link

[selectmenu] Restricting interactive content in <selectmenu> listbox #540

Closed dandclark closed 1 year ago

dandclark commented 2 years ago

A goal of <selectmenu> is that it is accessible by default.

The way this will be achieved is that when an author provides their own instances of the <selectmenu>'s predefined parts (button, listbox, and options), the platform will ensure that they have the correct a11y semantics by applying appropriate ARIA roles and specifying relationships like aria-haspopup="listbox".

Ensuring that the <selectmenu> is fully accessible becomes more difficult when the author adds arbitrary interactive content via the <selectmenu>’s named slots, particularly inside the listbox part. Adding, for example, extra buttons inside the listbox is problematic because ARIA and accessibility tech doesn’t expect to find interactive content in a listbox aside from the options themselves. See the content restrictions of the listbox role.

Through extensions to ARIA, accessibility tech, and <selectmenu> controller code, it may eventually be possible to make some or all of these scenarios accessible by default. In particular, see the aria-actions may eventually provide a mechanism for supporting interactive content inside of listbox options.

In the meantime, to guide developers away from creating inaccessible scenarios, I'm proposing that <selectmenu> emit a console warning when an author slots any interactive content into the <selectmenu> (aside from the elements designated as button, listbox, and option parts). “Interactive content” for this purpose is defined as any of:

We could also consider more restrictive enforcement of this, such as making the <selectmenu> inoperable if interactive content is present. This is likely overkill though. There are some scenarios where interactive content can exist without breaking the control for AT users, for example the Scroll Indicators demo here. If we completely prevent devs from using <selectmenu> for these types of scenarios, they will build these scenarios with <div>s (as is the case today) without any a11y support and without console messages to warn them about potential a11y issues.

This was previously discussed in the context of <listbox> at https://github.com/openui/open-ui/issues/458, but I want to scope the discussion here to specifically interactive content. We're exploring other potential ways for handling accessibility of noninteractive content like optgroup headers -- more to come on that later.

smhigley commented 2 years ago

I like the idea of sending a console warning for unsupported content! I'd also like to throw a few other possibilities out too -- my one misgiving with only the console warning is whether it sets up the idea that interactive content is not allowed while also allowing it in practice. I'm worried that sort of equivocation from the browser will end up being confusing to authors, and risks being simply ignored -- at least without clear guidance on what to do about it.

I'd love other people's thoughts on these additional options:

Regarding that last point, I was wondering if anyone had more examples of interactive content within a <selectmenu> that can be made accessible by an author. The linked Scroll Indicators demo doesn't actually look like it has interactive content to me, so I think that one wouldn't be blocked no matter what approach is taken.

I think more concrete examples of potentially OK interactive content would help a lot, since I can't think of any right now that could be made accessible by an author without fully changing the semantics of the listbox, or the keyboard behavior, or both. I know I work with a pretty biased range of UI though, so I know I'm not thinking of all possible use cases :).

I did write up a list of the types of content I could think of authors attempting to put within a <selectmenu> and the semantics and keyboard functionality that would need to be implemented to have be accessible: https://gist.github.com/smhigley/5eb3ee829f1ee963c01397ba4db2da1a. It's not comprehensive, but I thought I'd link it here in case anyone finds it helpful.

css-meeting-bot commented 2 years ago

The Open UI Community Group just discussed [selectmenu] Restricting interactive content in <selectmenu> listbox #540.

The full IRC log of that discussion <hdv> Topic: [selectmenu] Restricting interactive content in <selectmenu> listbox #540
<hdv> github: https://github.com/openui/open-ui/issues/540
<JonathanNeal> dandclark: right now in a select menu, authors can put whatever they want. very early in the process we talked about what kinds of restrictions this would have, and we didn’t add any. more customizability seemed good. now there seems to be a good reason to restrict this content; accessibility. the accessibility model does not expect to see anything in there but basic options; they don’t expect to find any other kinds of content like
<JonathanNeal> widgets. such non-option things would break stuff. what do we do about this? we don’t want to encourage patterns that will not be accessible.
<flackr> q+
<Travis> auto-inert for such typically interactive elements?
<JonathanNeal> dandclark: in the issue, i recommend the restrictions trigger a console, and I learned recently we could use another pane in the developer tools.
<JonathanNeal> dandclark: the restrictions would include things like form controls, summary/details, media elements, or things that could receive tabindex; just interactive content.
<masonf> q?
<dandclark> Proposed resolution: When interactive content is inside a selectmenu's listbox, the selectmenu will continue functioning but the UA should should warn the developer that this is not accessible. Interactive content in this context means form controls, other element that users are expected to interact with, e.g. <a href>, <summary>/<details>, <video>, others..., <iframe>, and any element given focusability via tabindex.
<sarah_higley> q+
<AlexanderFutekov_> q+
<hdv> ack flackr
<JonathanNeal> flackr: I feel like this is really limiting the use-cases. like “choose the day” with something inside like “choose the time slot”. is there not a way to expose these that the accessibility tool would be ready to handle these more complex cases?
<masonf> q+
<JonathanNeal> sarah_higley: I probably have to see an example of what you mean. Do you mean something like “select a day” and then the entire select menu changes?
<JonathanNeal> flackr: this would be more common in the case with select menus that do not auto-dismiss. I'm trying to think thru some of the richer content authors might use.
<dandclark> q+ to mention that if there are compelling scenarios involving interactive content, ARIA and ATs could be enhanced to make these scenarios accessible, and <selectmenu> could be made more permissive to allow them.
<bkardell_> q+
<JonathanNeal> sarah_higley: I did make a gist that has some examples of more advanced content. What you are describing seems more like a dialog popup. It would have to not dismiss any click. It would have to trap arrow keys, tabs. I’m guessing it would have a dialog role at the top and non-list semantics inside. That would mean restructuring all of the semantics for many things, which seems like something that wouldn’t be easy for authors to do
<JonathanNeal> with the select menu.
<JonathanNeal> flackr: another example off the top of my head would be summary/details.
<masonf> q?
<JonathanNeal> sarah_higley: I've seen people try to make that. I feel like the way to do that is, if you want to keep this in a select-menu, is to do something different like a grid menu, or make one of the options be clickable to expand something else.
<hdv> ack sarah_higley
<JonathanNeal> sarah_higley: I am very open to being wrong about this, but I suspect there is not a way to make extra-interactive content accessible. I suspect if people want to play with the default interactivity, their best bet is to just use the options. Those have their own pitfalls, but they would be better than throwing in buttons, links, or whatever. Perhaps beyond a console warning, the browser should just remove those elements entirely.
<JonathanNeal> sarah_higley: my worry with a console warning is that it is just a warning, like “we do not think you should do this, but we will let you do this”.
<Travis> I don't think we have an option of removing elements that were explicitly placed there (e.g., selectMenu.append shouldn't fail)
<JonathanNeal> sarah_higley: if the answer is “you can never do this” then I think it should just remove it, and a warning is not sufficient.
<Travis> q+
<JonathanNeal> sarah_higley: another warning would be letting authors know it could be removed in the future, but not yet.
<JonathanNeal> flackr: that makes sense; if we think it could never be accessible, we would just remove it.
<JonathanNeal> flackr: I am mostly concerned with allowing things that could not be made accessible.
<masonf> q?
<sarah_higley> ack me
<JonathanNeal> hdv: perhaps we shouldn’t allow it until this is fixed, otherwise it would create inaccessible experiences.
<hdv> ack alex
<Travis> HTML parser issues get dumped to dev tools console in some UAs
<JonathanNeal> AlexanderFutekov_: I have a concern about the console message. I don’t think we have that for any element in HTML. Do any other elements do this, like marquee?
<Travis> (does not cover dynamic changes via DOM tree APIs).
<JonathanNeal> masonf: there are other examples — not many — but examples of things in the parser that trigger warnings about invalid values, so it can be done.
<hdv> ack masonf
<sarah_higley> q+
<JonathanNeal> masonf: I am strongly in favor of not breaking the control and allowing these use cases, with perhaps a warning. There is a secondary actions proposal that may change things in the future. If we allow all things, but warn on things we think cannot be done, we will funnel the use cases by developers. If we break it, then developers will just use divs. That’s what they do today. And then we’d not even have a way to warn developers.
<Travis> q-
<hdv> ack sarah_higley
<Travis> Mason covered my feedback
<JonathanNeal> sarah_higley: I don’t disagree. There is a balance. Where I might disagree is that I do not thing select menu would never be the right thing for some of these things; things where this should be a dialog.
<JonathanNeal> sarah_higley: in those cases, I think it’s better that people build their own.
<JonathanNeal> sarah_higley: if we muddy the waters of what select menu is now, then it may be harder in the future to get people to use a more right element for the usage they went for.
<JonathanNeal> masonf: there are 3 categories of things that are ‘funny’. Interactive content (beside?) options, interactive content in options, and non-interactive content in non-options.
<JonathanNeal> sarah_higley: when I think of good interactive content in options being secondary options.
<JonathanNeal> s/being/I think of being
<Travis> s/secondary options/secondary actions/
<JonathanNeal> thank you, Travis ❤️
<masonf> q?
<hdv> ack dan
<Zakim> dandclark, you wanted to mention that if there are compelling scenarios involving interactive content, ARIA and ATs could be enhanced to make these scenarios accessible, and
<Zakim> ... <selectmenu> could be made more permissive to allow them.
<JonathanNeal> dandclark: I still have worry about it being overkill. Like a scroll experience inside a listbox. That scroll experience would not prevent a user of accessible tech from using the control. I would not want to push the author making that to divs.
<JonathanNeal> sarah_higley: I did take a look at that. In my opinion, those (scrolling?) arrows would just be divs. To me, those should be implemented as generic elements with hover handlers.
<JonathanNeal> masonf: I could see those being built with buttons
<JonathanNeal> sarah_higley: I think that is a problem if those are built with buttons.
<Travis> are scroller (anything with overflow) elements considered "interactive"?
<JonathanNeal> sarah_higley: if the arrows are a mouse affordance, then I see not reason to put those into the accessibility tree or to be able to get focus
<masonf> q?
<Travis> Can something be mouse focusable but not keyboard focusable? I didn't think so...
<JonathanNeal> flackr: I'm still on the side of not restricting these options. I’m thinking the issue is more that we haven’t found the right accessibility semantics to express that.
<bkardell_> Travis: tabindex -1 could be?
<JonathanNeal> sarah_higley: If select menu can handle that kind of content, switching keyboard behaviors and semantics, then I could understand allowing that kind of content. But if the intent is for select menu to always be a list box, then I think that sort of content is never going to fit in that.
<hdv> ack bkardell_
<masonf> q+
<Travis> bkardell_: ah, right.
<JonathanNeal> bkardell_: my complicated thought is — it depends. I would like to see us collect a large sample of things people could do (and I realize there are an infinite number of things people could do).
<JonathanNeal> bkardell_: in many cases, there are a ‘gradient’ of things, where ‘Thing A’ seems like ‘Thing B’.
<JonathanNeal> bkardell_: but they might have different implications and different limitations.
<dandclark> q+
<JonathanNeal> bkardell_: and then there are all these ‘gotchas’, like the affordances that sarah_higley brought up.
<JonathanNeal> bkardell_: where something might be button-like in there, like for the scrollbars, and allowing them to be scrolled with a keyboard.
<JonathanNeal> bkardell_: I think we should probably collect a sample of things before we make a decision.
<hdv> ack masonf
<JonathanNeal> bkardell_: If we do go the route of trying to prevent things — like by removing content — then we should think about the level of complexity we are adding (like how removing content changes based on whether it comes from static HTML or dynamic DOM)
<JonathanNeal> masonf: its still on the table for the select menu to modify the behaviors of other things like popup and ‘do the right thing’. I think it would be okay for the controller code to ‘do the right thing’ if it sees interactive content there and change the role to dialog.
<hdv> ack dandclark
<hdv> q?
<JonathanNeal> masonf: if we make it so that putting something invalid gets removed, then we would not be able to add it back in later, because some sight would rely on it being removed.
<JonathanNeal> dandclark: I think there is a subset of things here we can agree on. For interactive content that is inside of options, adding a warning.
<dandclark> Proposed resolution: When interactive content is inside a selectmenu's listbox's options, the selectmenu will continue functioning but the UA should warn the developer that this is not accessible. Interactive content in this context means form controls, other element that users are expected to interact with, e.g. <a href>, <summary>/<details>, <video>, others..., <iframe>, and any element given focusability via tabindex. Behavior for
<dandclark> content inside listbox but outside of options is to be determined.
<Travis> 💖controller code figures out how to make particular patterns accessible.
<masonf> +1
<JonathanNeal> +1 to the warning
<sarah_higley> +1
<JonathanNeal> JonathanNeal: I would expect it to match current behavior for other console warnings, but agree with masonf that it is an implementation detail.
<masonf> https://microsoftedge.github.io/Demos/selectmenu/
<JonathanNeal> bkardell_: it would be really great to see a few examples to discuss what exactly we mean.
<JonathanNeal> masonf: there aren’t many or any demos in that link that fall into the category we are discussing.
<JonathanNeal> bkardell_: if we are going to resolve on something, then I think we should have an example.
<JonathanNeal> masonf: the thing we are resolving today would be like where a list of options has an ‘X’ that would remove the option.
<JonathanNeal> s/that would remove/beside each option that would remove
<JonathanNeal> bkardell_: an explanation of the use case, or a reference to something in a design system somewhere, or a website that is doing it.
<JonathanNeal> flackr: I don’t know why we want to make this limitation in a select menu, when I could see things in there that would be interactive.
<JonathanNeal> bkardell_: do we make it possible to make a menu with a select box?
<sarah_higley> https://github.com/w3c/aria/issues/1440
<JonathanNeal> narrator: folks began looking at the examples. not everyone had their flags enabled. it was good, confusing fun.
<JonathanNeal> masonf: the action item is to find/make more demos?
<JonathanNeal> bkardell_: I would feel more comfortable if we laid out a bunch of possibilities and discussed them.
<JonathanNeal> sarah_higley: I think it would be good to discuss the intent of select menu in its final form.
<hdv> q?
<JonathanNeal> hdv: we will leave this on the agenda for next week
<hdv> Zakim, end meeting
<Zakim> As of this point the attendees have been JonathanNeal, miriam, Travis, bkardell_, flackr, dandclark, masonf, hdv, sarah_higley, dbaron, tantek
<Zakim> RRSAgent, please draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2022/06/09-openui-minutes.html Zakim
<Zakim> I am happy to have been of service, hdv; please remember to excuse RRSAgent. Goodbye
dandclark commented 2 years ago

In the previous discussion on this there was a request for examples of how we expect that interactive content would actually be used in a <selectmenu>'s listbox once a11y tech made it possible.

For interactive content inside <option>s, some scenarios are:

Interactive content in the listbox but outside any <option>s tends to fall more into dialog rather than listbox semantic territory. But it's worth thinking through what kinds of things developers might try to build, if only to decide how best to prevent them from doing so with <selectmenu> due to a11y issues.

All of the above is pretty speculative, so if there are any existing examples that folks have found in the wild of interactive content in custom select-like control listboxes, please share!

mfreed7 commented 2 years ago

You alluded to it in your first list, but one use case that deserves its own bullet point is a nested menu. I.e. a <selectmenu> contained within an <option>.

Interestingly, to me at least, both of your example use cases for interactive content outside the <option>s would be better achieved (and accessible, I think) by putting those controls in the button element, rather than in the listbox.

css-meeting-bot commented 2 years ago

The Open UI Community Group just discussed Restricting interactive content in <selectmenu> listbox.

The full IRC log of that discussion <gregwhitworth> Topic: Restricting interactive content in <selectmenu> listbox
<hdv> github: https://github.com/openui/open-ui/issues/540
<masonf> ok
<hdv> dandclark: the goal for selectmenu that we set out at the beginning is that selectmenu should be accessible by default. Currently developers can put whatever they want into selectmenus and items
<masonf> Just to point it out, the notes from https://github.com/openui/open-ui/issues/548#issuecomment-1171536146 don't call out the resolution
<hdv> dandclark: but, the way accessibility APIs work is that interactive content inside listboxes is not expected and would lead to problems. Only groupings and options are expected
<hdv> dandclark: so today, it would be pretty easy for developers to make something that is not accessible, and developers wouldn't necessarily even realise that what they're building is not accessible
<hdv> dandclark: so we thought about adding a warning
<hdv> dandclark: what we diverged to last time was some kind of console warning and maybe squiggly lines under the element, to warn the developer that what they're building would cause problems
<una> q+
<hdv> dandclark: down the line, there is work in motion around aria-action, if those things would be supported we could change what we recommend here
<hdv> dandclark: my thinking, based on what sarah_higley wrote about this, you may want something like 'recently searched for' in a search engine, or in a listbox you may have a button or link for people to get more information or a button with a popup that flies out… there are various things where users might want to get more detail about an option
<hdv> dandclark: or a form might have plus/minus buttons where the quantity could be changed. These are all things developers may want to buikld today and we want to warn them that if they do, it would be inaccessible today
<sarah_higley> q+
<hdv> dandclark: in the future we may be able to add the right semantics automatically
<gregwhitworth> ack una
<hdv> una: I want to talk to the warning thing first… to me, this sounds like a dev tools thing. Are you aware of anything else warning inline to compare it to?
<hdv> dandclark: I mean it like a dev tools thing, yes, not something on the page that users would see if the dev tools are closed
<gregwhitworth> q+
<hdv> dandclark: in the issues tab in dev tools today, you can see some warnings about accessibility today. And it also causes a red squiggle in the DOM in the dev tools
<hdv> una: that makes sense to me. As someone working closely with dev tools: great idea, totally doable.
<masonf> The spec just needs to say "the UA will warn the developer in an appropriate way".
<hdv> una: it does seem to be sort of a different issue… we may see this as two things: a specification issue vs a tooling issue. I don't know if there are changes to the spec we should be making?
<hdv> una: what would be the resolution we would want on this?
<hdv> dandclark: alternatives that are more impactful would require a spec change, for instance if we break the control if developers try to do this
<hdv> dandclark: in the last meeting, we also talked about interactive content that is inside the listbox but outside of options… we could automatically remove it from the DOM, not sure if we would want to but we could
<hdv> dandclark: so the question is if we want to do something more than just warning
<masonf> I think we could normatively require the UA to warn, right?
<hdv> dandclark: in the spec something like this would exist as a comment/warning, but not in the normative text. The resolution for Open UI would be something like 'don't break the control when devs do this, but we should add a warning'
<hdv> masonf: we could maybe normatively require this?
<hdv> una: do we have a precedent for this where a spec text prescribes how a UA should warn?
<hdv> dandclark: not sure if we do, I'm all for it?
<hdv> gregwhitworth: we could also be a precedent, by the way
<hdv> una: this is where I think the difference between web platform and tooling for a user agent matters?
<gregwhitworth> ack sarah_higley
<hdv> gregwhitworth: this would depend on what we put in 'should' in the spec?
<scotto> q+
<hdv> sarah_higley: I just wanted to confirm that this is specifically for interactive content within an option, not outside of options
<hdv> sarah_higley: the warning makes sense for things where selectmenu would be able to do it in the future, but for things where we know it could never be supported, we would probably want more than just a warning
<sarah_higley> ack me
<hdv> gregwhitworth: one thing I'm curious about when talking about just a warning vs breaking the control. Has anyone tried to build one of these in the current world?
<hdv> gregwhitworth: we talked about removing these warnings in the future… let's say we ship this in the following year… how much friction would I hit, as an author, to make this accessible in the future, when aria actions would be supporte?
<hdv> s/supporte/supported
<hdv> sarah_higley: I could explain what it would look like
<hdv> gregwhitworth: I mean the world where selectmenu would ship today
<sarah_higley> here's my testing page for what it is like today: https://a11y-screenreader-demos.netlify.app/studies/secondary-actions/
<vicgutt_> q+
<hdv> gregwhitworth: could we add an example of how we add interactive content to an option and it is fully accessible? would that be doable?
<hdv> sarah_higley: I have done a fair amount of testing with things like putting buttons inside of listboxes, both inside of options and adjacant to options
<masonf> ...and a follow-on question to Greg's question: is there a way for the UA to *detect* that such content has been made accessible, so we don't need to show the warning?
<gregwhitworth> ^ good question masonf
<gregwhitworth> ack gregwhitworth
<hdv> sarah_higley: the failures are not terrible… one of the most common things is when you send focus to the button, Windows will pop out of application mode and give you a virtual cursor, accessible name could have problems
<hdv> sarah_higley: it generally doesn't blow up the basic functionality of the listbox
<hdv> sarah_higley: there are also things you or browsers could do to mitigate that
<gregwhitworth> ack scotto
<dandclark> Proposed resolution: When interactive content is inside a <selectmenu>'s listbox's options, the selectmenu will continue functioning but the UA should warn the developer that this is not accessible. Interactive content in this context means form controls, other element that users are expected to interact with, e.g. <a href>, <summary>/<details>, <video>, others..., <iframe>, and any element given focusability via tabindex. Behavior for
<dandclark> content inside listbox but outside of options is to be determined. We still need to decide what to do for interactive content that's in the listbox but outside of the options.
<hdv> scotto: with regards to what Sarah said… I did some recent testing and found things kind of work on Windows… on macOS and iOS things fall down pretty hard, particularly with things like buttons inside of listboxes, likem you can't get to things at all. I don't know if this has changed recently
<dandclark> Proposed resolution (edited): When interactive content is inside a <selectmenu>'s listbox's options, the selectmenu will continue functioning but the UA should warn the developer that this is not accessible. Interactive content in this context means form controls, other element that users are expected to interact with, e.g. <a href>, <summary>/<details>, <video>, others..., <iframe>, and any element given focusability via tabindex. We
<dandclark> still need to decide what to do for interactive content that's in the listbox but outside of the options.
<sarah_higley> yeah, VoiceOver was the sole SR that didn't access the nested buttons at all for me. The listbox continued to work, but not the nested buttons :/
<hdv> scotto: I did add myself to the queue for the convo on warnings… there is some precedent in the HTML spec, there is some info on warnings with alt text for images and there are other parts in the spec about warnings, that are also consumed by things like the HTML validator
<gregwhitworth> ack vicgutt_
<hdv> scotto: that would help people find issues right in the browser, without having to go to another app for validation
<hdv> vicgutt_: let's say in the scenario a developer would put interactive element inside the option, like, add a link… there's a deadline, they don't care… what would happen, would it behave like a link, but it would just not be accessible?
<andrico1234> q+
<hdv> vicgutt_: I don't know if a warning would discourage people enough?
<masonf> Very good point about a <div> with a click handler. That seems worse.
<gregwhitworth> ack andrico1234
<gregwhitworth> ack andrico
<hdv> andrico1234: my question would be… what would the dev tools look like when the user was using a website builder like Squarespace, would it give a lot of errors in the dev tools?
<masonf> You'd see the warnings still, likely.
<hdv> dandclark: as we're discussing it here, we give flexiblity to the user agent
<hdv> dandclark: my expectation would be when you open the Dev Tools, you would see it in the Console
<hdv> andrico1234: i guess that would incentivise larger companies like that to get their accessibility in check
<masonf> +1 to the resolution.
<una> SGTM
<scotto> +1
<JonathanNeal> +1
<sarah_higley> +1
<hdv> +1
<andrico1234> +!
<vicgutt_> +1
<andrico1234> +1
<dandclark> Resolved: When interactive content is inside a <selectmenu>'s listbox's options, the selectmenu will continue functioning but the UA should warn the developer that this is not accessible. Interactive content in this context means form controls, other element that users are expected to interact with, e.g. <a href>, <summary>/<details>, <video>, others..., <iframe>, and any element given focusability via tabindex. We still need to decide
<dandclark> what to do for interactive content that's in the listbox but outside of the options.
<masonf> (You do need all caps RESOLVED for the resolution to get called out in the notes.)
gregwhitworth commented 2 years ago

The resolution is:

RESOLVED: When interactive content is inside a 's listbox's options, the selectmenu will continue functioning but the UA should warn the developer that this is not accessible. Interactive content in this context means form controls, other element that users are expected to interact with, e.g. ,

/
,