Skip to content

HTML Popover Attribute A11y Proposal (manual and auto)

Jump to bottom
Scott O'Hara edited this page Nov 28, 2022 · 2 revisions

Popover A11y Proposal (manual and auto)

Table of Contents

Summary

This document describes accessibility solutions for the proposed popover API (popover attribute).

Please read the popup Popover API Explainer before reading or commenting on this document.

Additional links: Chromestatus
Demo
More demos from Scott O'Hara
A11y issues in GH

Important considerations

  • The popover API is currently incomplete:
    • The attributes to trigger popups automatically from user input (popovertoggletarget or popovershowtarget) are currently only supported on button elements, but this support is expected to expand in later versions, e.g., to text inputs. When it does, we will need to make adjustments to keyboard behaviors such as ensuring that triggering elements are in the tab order.
    • Hint popovers and popoverhovertarget have been deferred in the interests of shipping something useful sooner. However, once they are added, they will bring their own a11y considerations.
  • This discussion requires adding the concept of a minimum role to HTML-AAM. A minimum role assures that an element won't be exposed as a "generic", which blends in with the page. This concept is important for other discussions on how to expose generic elements when they’ve been given properties important to accessibility. E.g., tabindex, contenteditable, and possibly in regards to naming.

Heuristics over explicit semantics

There are currently 2 types of popovers: manual and auto. These values are not semantic, but produce behaviors that look and behave like common patterns. Therefore, the approach taken here is to use heuristics to build accessibility around the most likely pattern and allow the author to modify from there.

Semantic HTML elements may be specified in the future that encapsulate various popup behaviors, e.g., <tooltip> or <notification>. The proposed <selectmenu> is also being implemented using popup behaviors.

Triggers, anchoring and reading order

A popover can be associated with a triggering button via the popovertoggletarget or popovershowtarget attribute (pointing from the trigger to the popup).

Supporting aria-expanded

  • A triggering element that can open the popover should automatically support the equivalent of the aria-expanded property. The value should be true if an associated popover is open.
  • Note that the aria-haspopup equivalent property is not exposed, because it would be redundant, and provides less useful information than aria-expanded. See also: https://github.com/w3c/aria/issues/1024

Manual popups

Different types of manual popups

Manual popovers are elements that show up in the top layer and are controlled by the page. The main use cases we know of are a toast / notification, and persistently visible content such as modeless dialogs that need to overlay other content.

A11y semantics and behavior

  • Minimum role of group, to prevent the contents from blending into the rest of the page. TBD: develop alternate platform mechanisms in each platform API for exposing the fact that an element is a manual popover, e.g., object attribute ispopover:true. This would be helpful in cases where the popover already has its own strong role.
  • Announcements for new popovers:
    • When focus goes inside the popover, there is no need for an additional announcement of the popover, as moving focus there is enough.
    • Else, when triggered by page load, default to not announcing the popover, or include in initial page load summary (e.g., this page has 5 headings, 4 landmarks and 3 popovers).
    • Else, announce the popover with at minimum the title of the popover. If the verbosity indicates instructions to be read, the AT should inform the user that, for instance, F6 will navigate to the popover (Ctrl+F6 on Mac).
      • NOTE: author guidance would be necessary to indicate what popover=manual should be used on. For example, a popover=manual may be used on a <dialog> element, a role=region/article, or possibly even a generic <div> (thus ideally being exposed as a role=group).

Keyboard navigation

  • F6 (Ctrl+F6 on Mac) cycles to these, with the most recent popover first.
  • Escape does not automatically close, just as light dismiss is not automatically supported (use popover=auto for this behavior).

Auto popovers

Auto popovers can exist only 1 at a time. They are automatically dismissed if another auto popover is shown, or if the user navigates away.

A11y semantics and behavior

  • Similar to manual popovers, use a minimum role of group, to prevent the contents from blending into the rest of the page.
  • Would commonly be expected to be used on elements with roles that are current token values for aria-haspopup. Can be used with other roles as well, such as range slider popover invoked by a volume button.

Keyboard navigation

  • Tab order repair: all of the tab stops inside of the popover should be inserted after the triggering element, and before what the original tab stop after the trigger.
  • Escape key dismisses, even if the auto popup does not currently have focus.
Clone this wiki locally