Need solution for screen reader to read popover content without forcing ownFocus

[aphelionz]

Steps to reproduce (assumes ChromeVox or similar))

1. Open https://elastic.github.io/eui/#/layout/popover in a new tab.
2. Tab to the first "Show popover" button
3. Press enter
4. Note the popover appears but is not read
5. Tab to the next "Show popover" button under the "Trap focus" section
6. Press enter

This reacts more like I would expect, however I see the need to have the ability to explicitly set ownFocus. The popovers still need to be read, though... I'm wondering if there's some sort of aria-describedby trick we can use here.

Category: #728: Elastic UI Popover Accessibility
Relevant WCAG Criteria: 3.3.2 Input Assistance: Labels or Instructions

[cjcenizal]

@bhavyarm pointed out to me that the aXe accessibility validator complains about the aria-controls attribute that's added to the button which triggers the popover. This attribute connects the button to the popover it opens, but because it's applied even when the popover doesn't exist in the DOM, it's invalid. I think the solution is to remove this attribute while the popover is closed.

[snide]

@cjcenizal I'm in this one now, so I'll see what I can do. Also, I couldn't see any reason we wouldn't want to simply apply aria-live="assertive" to these. I can't think of any time you'd want to "click" them and not have the content read.

[cjcenizal]

Per convo in Slack, my hunch is that there are 2 scenarios to account for:

• Where the popover content is interactive (and ownFocus is set)
• Where the content is read-only (and we want to use aria-live to read it out)