Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mappings for proposed popover attribute #428

Open
scottaohara opened this issue Jul 11, 2022 · 0 comments
Open

Mappings for proposed popover attribute #428

scottaohara opened this issue Jul 11, 2022 · 0 comments

Comments

@scottaohara
Copy link
Member

scottaohara commented Jul 11, 2022

Follow on from the OpenUI issue where initial discussion for how the proposed popup attribute would be exposed by browser accessibility apis.

The popup attribute has three different values that represent variations in behavior for the popup.

  • popup="" or auto represent the default behavior, where the popup is rendered as display:none until a user invokes it by activating its associated control. e.g., a button, or combobox triggering element.
  • popup="hint" (name of this value could still change) is a popup that would behave like a tooltip, invoked on hover or focus of an element to which the popup is associated.
  • popup=manual would be for other instances of needing a popup element where there may only be a loose association with the element that invokes them, or there may be no explicit element to which the popup is associated with. For instance, a toast notification or possibly a persistent chat dialog which needs to be rendered in the browser's top layer. Unlike other popup types, there can be multiple manual popups rendered on a page at once.

The popup explainer on openui has additional details.

The general intent of the popup attribute is to keep the semantics of the element it is used upon, but there would still be a need to expose the element as a "popup". E.g., a listbox may be rendered as an form control within the normal flow of a web page, or it may be rendered as a "popup", and if keyboard focus were to leave the listbox, it would auto-dismiss.

The intent of the attribute over a popup element was that there are many types of "popups", and there is no one role that accurately represents all of them. However, with a global attribute which can be used on generic elements, there is the question of how this should be exposed to accessibility apis if authors fail to add an explicit ARIA role to such elements. There is a similar issue with contenteditable - where the attribute can make any element editable, whether that practically makes sense or not - but it is still unclear what role, if any, should be applied to generic elements that have been made editable.

Other attributes related to popup which also need mappings discussed (though these are generally more straight forward):

  • togglepopup - used on invoking element
  • showpopup - used on invoking element
  • hidepopup - used on element within a popup to close said popup
  • defaultopen - used on a popup to set it to open by default. This will not work with popup=hint.
@scottaohara scottaohara added this to the ARIA 1.3 Related milestone Jul 11, 2022
@scottaohara scottaohara changed the title Mappings for proposed popup attribute Mappings for proposed popover attribute Apr 11, 2023
@scottaohara scottaohara mentioned this issue Apr 11, 2023
20 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant