Consistent handling of aria-describedby #55362
Comments
jeryj
added
the
[Focus] Accessibility (a11y)
|
First, I think it'd be useful to make an isolated test case that sees what methods work well. Is rerendering even the issue here? |
|
I agree. Can we start off with something really simple?
I tested it with the below code and it works fine. <html>
<head>
<title>Test</title>
</head>
<body>
<h1>Test</h1>
<br />
<span id="some-id" style="display: none;">Description goes here</span>
<button type="button" aria-expanded="false" aria-haspopup="menu" aria-describedby="some-id">Options</button>
<br />
</body>
</html>Even with the ID appearing directly above the |
|
I also tried this version. The bug has to happen during re-render because the click function successfully changes the text and it's announced. I think a good first step might be to avoid re-rendering the entire element and only the text inside. Could probably do that with <html>
<head>
<title>Test</title>
</head>
<body>
<h1>Test</h1>
<br />
<span id="some-id" style="display: none;">Description goes here</span>
<button type="button" aria-expanded="false" aria-haspopup="menu" aria-describedby="some-id" id="some-button">Options</button>
<br />
<script type="text/javascript">
const button = document.getElementById( 'some-button' );
button.addEventListener( 'click', function() {
const description = document.getElementById( 'some-id' );
description.textContent = 'New Description';
} );
</script>
</body>
</html> |
|
I created some test cases as well. The bug, to me, appears when:
Then, I can tab off of the button, tab back to the updated button, and the description is there. Is this the same behavior you experience on my test case, @alexstine? |
|
Updated test case: Significant finding: Safari + VoiceOver will not announce updated descriptions unless the ID of the description and aria-describedBy change. I'm curious how NVDA handles this. Does updating the ID of the description and aria-describedBy allow it to access the updated description? cc @alexstine |
What problem does this address?
aria-describedby's usage is inconsistent in the codebase, and different areas use different methods. A lot use the<VisuallyHidden>component with aninstanceIDto implement it, like:The issue with
<VisuallyHidden>is that the description is announced twice. In the above example, a screen reader would announce the description once on the button, and once after it within theVisuallyHiddencontent. This is better than nothing, but only announcing it once is far preferable.aria-describedbycontent can be hidden viadisplay: noneorvisibility: hiddenas well, which allows the description to be read when the virtual cursor is focused on the item with thearia-description, but won't have access to read the element that contains the description. That's a technical and confusing way of saying: it'll only read it once, and at the right time.To make things harder, unfortunately, we can't rely on using
display: noneorvisibility: hiddenalone. While that should work, it doesn't for some reason. We think it may be due to rerenders, but we're not sure yet.What is your proposed solution?
My initial, unexplored idea, is to handle it similar to modals. Have one div wrapper at the end of the content that contains all of the aria-description elements. Something that renders like
A good question here is, "why
<span>s? Well, if we rerender thedivitself, it will remount thediv, potentially making it so the description doesn't get announced. But if we can only rerender the content inside thediv, maybe it'll work. Whatever the solution is, ideally we can make it easier to addaria-descriptionsacross Gutenberg, and also make them work in a consistent way that allows us to easily patch any necessary updates.The text was updated successfully, but these errors were encountered: