Popover accessibility

[patrickhlauke]

Current implementation of popover http://v4-alpha.getbootstrap.com/components/popovers/ / http://getbootstrap.com/javascript/#popovers has a series of accessibility issues:

• once a popover is toggled, no indication/announcement is made to AT users that anything actually happened
• the popover is at the end of the document in source order, meaning that once a popover is triggered anywhere within the document, its content is not readily available/near the trigger, meaning that AT users won't be able to get to it easily/meaningfully
• side effect of the previous issue: if the popover has some focusable elements/controls (see for instance example https://jsfiddle.net/y3q1e4wm/7/ ) these elements will of course also be at the end of the document, meaning that even for non-AT keyboard user they'll not be logically following the expected focus order (and require extra work like manually setting focus to them at least, though returning back to the trigger then becomes the problem)

A fix for these is non-obvious, as it may depend on the nature of the popup itself (whether it only contains text/info, or also interactive controls). If it were just short content, an approach similar to tooltip (using aria-describedby) could be used, but if the content is structured/long, this won't be ideal. Tending to think that initially, once the popover is triggered, focus should be moved to the popover and kept inside it (effectively making it a modal), though then it needs a way of escaping back to the main document (ESC key to close it and return focus back to the trigger, though lack of a visible/focusable/actionable close control may be a problem). Failing that some focus juggling that means the popover is somehow injected directly after its trigger, though this would clearly cause display / z-index / stacking order issues.

[cvrebert]

• once a popover is toggled, no indication/announcement is made to AT users that anything actually happened

Does this apply to Tooltips too? Or why not?

the popover is somehow injected directly after its trigger, though this would clearly cause display / z-index / stacking order issues.

Yeah, I'd very much suggest avoiding that. Breaking the next-sibling CSS combinator is a bad scene.
http://getbootstrap.com/javascript/#callout-tooltip-groups has been a PITA.

[patrickhlauke]

Does this apply to Tooltips too? Or why not?

no, as tooltips use aria-describedby which is dynamically added once the tooltip is triggered (though i want to test this a bit more thoroughly with actual AT soon)

this won't help in this case, as aria-describedby will not work (as in, it won't be a good experience) for any content longer than a short sentence, and won't help at all with structured content (headings, lists, etc) and interactive content

[cvrebert]

Well, technically folks can put arbitrary HTML into a tooltip too. Admittedly, it's less common than with popovers.

[patrickhlauke]

This is still an issue. Would like to revisit this ideally for v4.0, failing that for v4.1

[tmorehouse]

Maybe, in the cases of popovers with longer content or interactive content, adding to the trigger element an aria-haspopup, and aria-expanded, and an aria-controls (when opened, since when closed, the popover isn't in DOM)), and possibly a different role than tooltip (maybe role dialog) on the popover markup.

Making the popover container have a tabindex of "-1" and focusing it on open might be in order, (but that also depends on the trigger types... focus would cause the popover to close immediately when it is focused - unless that is trapped within the listeners. This could be achieved by checking the related target on the focusout event to see if the focus went to (or inside) the popover. The same listener would be fine with the tooltip (although you probably wouldn't want the tooltip to be focused).

Tabbing out of (i.e. focus ring) the popover should go to the trigger element, and while popover is open, tabbing would jump back into the popover. This would be similar to modal's contain focus, but allowing focus to move back and forth between the popover and the trigger element (trigger element would of course need to be focusable). This would not work with the focus out hiding of popover. So maybe inserting popover into the tab sequence after the trigger button (somehow... it is not easy to determine an elements actual tab order) But maybe for this use case, if trigger is only click, then this tab containment would be desirable.

Just thinking... once option of controlling the tab order for keyboard users would be if a blur happens on the trigger element, focus could be moved to the popover container.and if tab leaves the popover container, it is trapped and the trigger element is them focused, and then blurred (or simulate a tab key press event on the element), causing the next element in the document order (after the trigger element) to be focused. OR a jquery selector (for focusable items that are not inside of something with tabindex of -1) which is then sorted by element tabindex (if people have added tab indexes, which they shouldn't), and then use a find in that array to find the trigger element, and then focus the next). Not ideal, but very possible to do.

For tooltips, I have seen many instances where they are given a role of alert with aria-live and aria-atomic="true" which makes them more readily announced on screen readers (i.e. alternative means of relaying invalid states of inputs, etc).

Maybe the role maybe should be configurable 9and default differently for popover vs tooltip).

The shown/hidden events could be used by authors to move focus into or out of the popovers, rather than trying to automate that into the tooltip/popover class code.

[tmorehouse]

I've been working on Bootstrap-Vue's tooltip and popover implementation (to use Popper.js), and have been considering adding in a configurable role property, and adding additional dynamic aria-described by to the popover content linking to the popover title (if present), using the auto-generated ID of the popover as a base for the ID applied to the popover title, as well as adding aria-owns (or aria-flowto) on the trigger element (when the popover is open) as an alternative to the aria-desribedby attribute.

This involves abstracting a few of the aria-* stuff into two methods in the tooltip class that can be overridden in the popover class. One method adds aria-* and role, while the other removes them

Another option we're considering adding in is containFocus option, to make popover act like a mini-modal.

[souporserious]

I've been messing around with a solution for popover tab management in React here. It's not specific to Bootstrap, but If it seems like a viable solution I'd love to make a small utility that this library as well as others could use. It follows some of what @patrickhlauke discussed above, excluding any of the aria attributes. I wasn't sure exactly the best way to handle it, but hopefully it's a good start that can be iterated on 🤷‍♂️.

[mdo]

Should we close this as stale?

[tmorehouse]

I'm guessing that it might be best to leave "interactive" popover accessibility as an exercise to the coder/user. Regular popovers (with no interactive content), are handed by the aria-describedby attribute on the trigger element (note that aria-describedby typically ignores the visibility state of the element identified in the attribute, and screen readers will read the content even if the popover/tooltip is in a hidden state).

[sambigelow]

@patrickhlauke what is an AT user?

[tmorehouse]

AT is Assistive Technology

[sambigelow]

@tmorehouse Thank you, I figured it would be something like that, but it was awfully hard to google.

I do not believe this issue is stale

[patrickhlauke]

going to try to more properly tackle some aspects of the "popovers with interactive content" over here #28446 for my 3rd original point. points 1 and 2 were addressed originally by also adding aria-describedby="..." for popovers, but the 3rd one would really require a rethink.