Clarifying The Relationship Between Popovers And Dialogs
[ad_1]
The difference between Popovers (i.e. the popover attribute) and Dialogues (i.e. both the element and that dialog accessible role) is incredibly confusing – so much so that many articles (like The, TheAnd The) have tried to shed some light on the matter.
If you are still confused, I hope this article clears that confusion once and for all.
Distinguish popovers from dialogues
Let’s dive into the technical implementations and look at the bigger picture, which makes more sense and puts everything in perspective.
The reason for this categorization lies in a few notable points.
First, we know that a popover is content that “pops up” when a user clicks (or hovers over or focuses on) a button. In the ARIA World there is a useful attribute called aria-haspopup which divides such pop-ups into five different categories roleS:
menulistboxtreegriddialog
Strictly speaking, there is a sixth value, truethat results menu. I didn’t list it above because it’s practically simple menu.
Because of dialog are on this list, we already know that dialog is a kind of popover. But there is even more evidence for this.
The three types of dialogues
We’re already talking about it dialog Role, let’s expand this further into its subcategories:
Dialogues can be divided into three main types:
- Modal: A dialog with an overlay and focus trapping
- Not modal: A dialog with no overlay or focus trapping
- Alarm dialog: A dialog box that notifies screen readers when it is displayed. It can be either modal or non-modal.
This brings us to another reason why A dialogue is considered a popover.
Some people might say that popovers are strictly non-modal, but that seems to be a big misconception – because popovers are ::backdrop Top-level pseudo-element. The presence of ::backdrop indicates that popovers are modal. Quoting the CSS Tricks Almanac:
The
::backdropThe CSS pseudo-element creates a background that covers the entire viewport and is rendered directly underneath onean element with thepopupAttribute or any element that switches to full screen mode using the full screen API.
However, I don’t recommend using the Popover API for the modality as it doesn’t have one showModal() method (that ), which creates inertia, focus trapping and other necessary functions to make it a true modal. If you only use the Popover API, you will have to build these functions from scratch.
So this means that popovers can be modal A dialog is simply a type of popover.
A popover needs an accessible role
Popovers need a role to be accessible. Hidde has one great article When choosing the right role, I will also address a few points in this article.
To start, you can use one of these aria-haspopup The above roles:
menulistboxtreegriddialog
You can also use one of the more complex roles, such as:
There are two additional roles that are a bit more controversial but could definitely work.
To understand why tooltip And status could be valid popover We have to take a detour into the world of tooltips.
A note about tooltips
From a visual perspective, a tooltip is a popover because it contains a small window that appears when the tooltip is displayed.
I included tooltip in the mental model because it makes sense to implement tooltip with the Popover API.
...The tooltip role doesn’t do much in screen readers these days So you have to use aria-describedby to create accessible tooltips. But it’s still important because it’s possible Expand accessibility support for some software.
However, from an accessibility perspective, tooltips are not popovers. In the world of accessibility, tooltips cannot contain interactive content. If they contain interactive content, don’t watch it tooltipbut a dialog.
You think about dialogues. Use dialogue.
Heydon Pickering, “Your tooltips are wrong”
That’s also the reason aria-haspopup does not include tooltip —aria-haspopup is meant to mean interactive content, but a tooltip may not contain any interactive content.
We’ll continue with that status This is an interesting role that requires some explanation.
Why status?
Tooltips have one quite complex story There is therefore a lot of discussion and dispute about this in the world of accessible interfaces.
To keep it short, there is an issue with tooltip accessibility as tooltips should only appear when hovering over them. This means that screen readers and mobile phone users cannot see these tooltips (since they cannot hover over the interface).
Steve Faulkner created an alternative – Toggle tips – to close the gap. He explained that Toggletip content needs to be announced by screen readers across live regions.
On first viewing, the content will be announced by (most) screen readers that support it
aria-live
Heydon Pickering added this later status can be used in his article about Toggle tips.
We can provide an empty live area and fill it with the toggletip “bubble” when invoked. This will both visually display the bubble and have the live region announce the tooltip information.
This clarifies whatever needs clarifying
For this reason status may be a possible role for a popoverbut you must exercise discretion when creating it.
However, I decided not to include that status Role in the mental popover model because status is a live region role and therefore different from the rest.
In summary
Here is a quick summary of the mental model:
- Popovers is an umbrella term for any type of on-demand popup.
- dialog is a type of popover – a type that creates a new window (or card) with content.
If you internalize this, it’s not hard to see why the Popover API can be used with the dialog Element.
...
When choosing one role You can certainly use one of these rolls for your popover.
menulistboxtreegridtreegriddialogalertdialog
The added benefit is that most of these roles work together aria-haspopup what won decent support in screen readers in the last year.
Of course, there are a few more you can use status And tooltipbut you cannot use them together with aria-haspopup.
Further reading
[ad_2]
Source link