Recode popovers as (conceptual) modal dialogs

[patrickhlauke]

Currently, popovers https://getbootstrap.com/docs/4.3/components/popovers/ provide a baseline accessible implementation where the content of the popover, when shown, is tied to the trigger via aria-describedby="...". This works well when popovers are used for their intended purpose - to provide a short notification/tooltip type popover message. However, looking at some of the recent issues here in github all relating to authors complaining about links, forms, etc getting stripped out of their popovers, it's clear that authors are using these beyond their intended purpose, and instead as a way to have a form of disclosure widget that opens a floating menu/dropdown type area with interactive content.

For these sorts of "povovers", the current approach is completely unsuitable. aria-describedby="..." will announce the entire content of the popover in one go, as a single long "blob" of content. Keyboard focus is not moved to the popover, and as the popovers are generally at the end of the document, this means that a keyboard user can trigger one of these, but then has to navigate through the rest of the document before they reach the interactive controls that the author crammed into the popover - and if they chose to make it a dismissable popup, it likely would disappear again as soon as they move focus themselves off the trigger.

Originally, I thought about simply putting a small notice on the popover documentation page to advise authors not to use these for anything interactive, but obviously this wouldn't stop authors actually doing it, and our recent addition of sanitize code sends the signal that in the end, we're ok with them doing it / making it easy for them.

So, while it would require a complete (breaking) refactor, if we want to keep popovers and allow them to be (mis)used this way, we should recode these to conceptually act like a modal dialog (but without the semi-transparent overlay):

• user activates the popover, focus is moved to the "popover"
• popover container has a role="dialog")
• focus is retained /cycled inside the popover
• the underlying page is hidden from assistive technologies using aria-hidden
• provide an "x" close control, and also react to "ESC" - focus is then moved back to the trigger element

For authors that do want to retain the current way popovers work for short, tooltip-like, non-inteactive notices only, maybe https://getbootstrap.com/docs/4.3/components/popovers/ can be extended to provide this as an additional option/style. And popovers can be treated as a visually different type of modal (kind of an "in-between" somewhere halfway between a tooltip and a full modal).

xref https://github.com/twbs/bootstrap/issues/18618 / https://github.com/twbs/bootstrap/issues/28411/ https://github.com/twbs/bootstrap/issues/24640 / https://github.com/twbs/bootstrap/issues/24290

[tmorehouse]

Having an option for popovers that put them in dialog mode might be handy... basically borrowing from modal's enforce focus routines, allowing ESC and an optional × button for closing in the title/header would be nice.

[herbalite]

@tmorehouse Interesting. Just yesterday I searched for a replacement for a confirmation dialog and stumbled upon this library

http://bootstrap-confirmation.js.org/

[patrickhlauke]

additionally, i'd drop the ability to have only hover as the trigger, as that immediately makes popovers not work for keyboard/assistive tech users. popovers should just show on click only (as even just doing it on focus hover would cause accessibility issues for keyboard users, as they'd then be dragged into the modal popover every time they just cycle through the page)

[tmorehouse]

Maybe, depending on the type of trigger used, the role could change? hover or focus would make it a jumbo-tooltip, and click would turn it into a mini-modal?

Unless maybe tooltips were slightly revamped to optionally show a title, and maybe have an additional flag to style them popover like. and then popover becomes the "positioned" min-modal.

The other option is to create a third component: tooltip, popover, popover-dialog, each inheriting from the previous.

[patrickhlauke]

having it show up on hover also brings this issue with it https://github.com/twbs/bootstrap/issues/28411 ... so i'm tending to lean towards simply not allowing it to just show on hover altogether (this is not unprecedented...our dropdowns for instance also don't show on hover, despite many requests; we don't even have live examples of popovers that trigger on hover in our docs; and i'm too lazy to test now, but my guess is popovers that just show on hover also don't work/work badly on touch/mobile devices).

and yes, tooltips would also be affected by https://github.com/twbs/bootstrap/issues/28411 but because they're aimed at only showing very short snappy content by design, it's less of a concern (though of course still an actual failure that we should probably address at some point)

[patrickhlauke]

@mdo would love your take on this general discussion btw

[loksun]

To move the focus to the popover once it's activated, I added a data-container="#id_of_popover_button" in my button and it seems to work well.

However, if I have links inside my data-content and I focus on them using , NVDA and JAWS will read the entire popover.

[kerryj89]

having it show up on hover also brings this issue with it #28411 ... so i'm tending to lean towards simply not allowing it to just show on hover altogether (this is not unprecedented...our dropdowns for instance also don't show on hover, despite many requests; we don't even have live examples of popovers that trigger on hover in our docs; and i'm too lazy to test now, but my guess is popovers that just show on hover also don't work/work badly on touch/mobile devices).

and yes, tooltips would also be affected by #28411 but because they're aimed at only showing very short snappy content by design, it's less of a concern (though of course still an actual failure that we should probably address at some point)

Does setting a delay value on tooltips only delay it visually or does it hide it from screen readers, too? I would still like to keep hover-ability like Wikipedia.

https://en.wikipedia.org/wiki/Template:Hover_title

[tmorehouse]

I was thinking of making a "popdown" component, based on dropdown, which would be triggered on an element (ie. input, button, etc) on focus, click, etc. it would be a wrapper component around the element, but would make the "popdown" content next in the tab sequence. (and the popdown could pop up, left, right, like dropdowns).

It would have similar issues as dropdowns, but I think it would be manageable.

[pglejzer]

do you have any plan to implement this with version 5? @mdo