- From: Mason Freed <notifications@github.com>
- Date: Thu, 14 Oct 2021 12:25:55 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/680/943658117@github.com>
> > A `<popup>` is something that has these qualities: > > That doesn't really help. Those are behaviors, not semantics or types of controls. (I.e. the things that feed into roles.) > > Below you propose that the role should be dialog. That implies that instead of being a new element, this should be some sort of mode of the dialog element, since the dialog element already occupies the semantic space of dialogs. (E.g., `<dialog type="light-dismiss">` or `dialogEl.showWithLightDismiss()`.) > > > In general, the `<dialog>` element is already in a somewhat similar boat, no? I.e. a `<dialog>` can be used for a number of UI purposes, such as dialogs, tooltips, toasts, etc. But the platform uses role=dialog and it's up to the developer to specialize further with ARIA attributes if it is being used for a more-specific purpose such as a tooltip. > > No, this isn't correct. The dialog element can only be used for dialogs. Tooltips or toasts should be done using `<div>`s or similar. (Or perhaps a new element, if someone were bold enough to propose one... I seem to recall something of that sort for toasts.) If you use `<dialog>` but then override its exposure to accessibility tech using `role=something else`, the element is being misused. So we both understand that `<dialog>` can be, and is, used for things other than dialogs. It is the (currently only) platform feature that gives developers access to the top layer. Using a `<div>` requires gymnastics like re-parenting the `<div>` to the last child of `<body>`, and giving it `z-index:9999999999`. It is also sub-par from an accessibility POV for many reasons, including the aforementioned re-parenting, plus the fact that `<div>`/`<span>` soup doesn't get announced at all by AT, right? At least if you build a toast using `<dialog>`, it'll be announced as a dialog, which isn't terribly far from a toast. Or at least it's closer than a `<div>`. Having said that, I'm not disagreeing with the idea that we should make this semantically as clear and accessible as possible. I'm open to concrete proposals about how to do that. > > We need to figure out what the similar semantic space, and corresponding role, is for popup. The explainer example seems to give several types of controls: menus, form element suggestions, content pickers, and teaching UI. What is the ARIA role for each of these? Perhaps each should have a separate element, not `<popup>`, which implements the appropriate semantics (and behaviors?? I can't imagine a teaching UI needs the exact same behaviors as a menu). Or perhaps some of those are better suited for `<dialog>` instead of `<popup>`. > > I apologize that this is rather fundamental criticism, but I do feel like I've raised it repeatedly since the beginning of this endeavor, without much response. I appreciate getting some concrete engagement at this point. No problem on the criticism - I'd like to get to a good solution here. I apologize that I don't think I realized this was "fundamental" - it sounds like you'd object to a general purpose `<popup>` element that fills many roles. So are you saying you'd prefer to see a proposal for many new elements, all with the same basic behavior (the three qualities I mentioned in my last comment), but different accessibility roles and semantic meaning? E.g. `<tooltip>`, `<listbox>` (would be useful in `<selectmenu>`), `<menu>` (oops), etc.? I filed https://github.com/openui/open-ui/issues/410 to discuss this issue further. Also happy to continue the discussion here. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/680#issuecomment-943658117
Received on Thursday, 14 October 2021 19:26:08 UTC