Both provide an accessible name for an element. The purpose of aria-label is the same as aria-labelledby. If there is visible text that labels an element, use aria-labelledby instead. If none of these options are available, or if the default accessible name is not appropriate, use the aria-label attribute to define the accessible name of an element.Īria-label can be used in cases where text that could label the element is not visible. Accessible names can also be created by certain attributes or associated elements.īy default, a button's accessible name is the content between the opening and closing tags, an image's accessible name is the content of its alt attribute, and a form input's accessible name is the content of the associated element. Most content has an accessible name generated from its immediate wrapping element's text content. If you add a container around the hidden button and that container has aria-live, then when the button is unhidden, it'll be announced.Īnd I changes the JS to remove the aria-live line activeButton.Note: aria-label is intended for use on interactive elements, or elements made to be interactive via other ARIA declarations, when there is no appropriate text visible in the DOM that could be referenced as a label So I think the purpose of aria-live is a little misunderstood. That is, nothing is announced when the new button is revealed, which is what I expect because you're unhiding a button and adding aria-live to it.
Your fiddle example does not work at all with NVDA on a PC. What I have found is that aria-live works fantastic when I'm not dynamically adding that attribute. Should the newly added children be announced right then or does the display/refresh cycle need to go through once before the "live-ness" takes affect? It's hard to say because browsers and operating systems combinations work a little differently. You can run into timing issues if you dynamically add an element with aria-live and then add child elements to that new live region. (See aria-relevant to control what types of changes are announced.) So when the page is loaded and the right elements have aria-live, then anytime you add text to the element (or child element) or add/remove child elements or hide/unhide child elements, those changes will be announced. The purpose of aria-live is to announce changes to the element (or child elements if aria-live is set on a container). It works best when the page is loaded and the element already has aria-live set. That is, it's not an attribute you want to add on the fly. Regarding aria-live, it's not meant to be a dynamic property. Using a is certainly a lot more work because you need tabindex and event handlers and aria-label and such, but if all that is there, it doesn't matter to assistive technology which one you use. Whether you use a real or doesn't matter. This however won't even get picked up by theĪdditional JSFiddle, with a simplified example (you can use Apple screenreader and click into the window to hear the content read):Īll the comments are decent so far but are avoiding the problem. Not using aria-live="polite" to reveal but the oppositeĪria-hidden="false".
no aria-hidden="true" it reads as "This is a label, Button" However, if the content is read from the get-go without being hidden, i.e. Which makes the screen-reader then read "This is a label" I use JS to remove the attribute aria-hidden and add aria-live="polite" when this button needs to be read on the page We have dynamic content that sits on a single page (doesn't reload) and changes on the screen.įor the screen-reader to keep up with this, I've added some JS logic where the attribute aria-hidden="true" or aria-live= "polite" is added to hide and reveal the targeted elements.Īlthough the element's aria-label is read out, I run into an issue where the role attribute is left out. I have a site that needs to be made fully accessible.
0 kommentar(er)
