aria-busy attribute, when set to
true is supposed to provide a hint to screen readers that the content within the subtree of the element it is on is being updated and should not be announced.
Indicates an element is being modified and that assistive technologies MAY want to wait until the modifications are complete before exposing them to the user.
source: ARIA 1.1 – aria-busy
It appears that currently only JAWS uses this information to hide busy content from the user (with Chrome and Firefox, not IE), other screen readers such as NVDA and VoiceOver ignore the busy state and the content can still be accessed.
Try it for yourself: aria-busy test
See the Pen aria-busy test by steve faulkner (@stevef) on CodePen.
aria-hidden to achieve the same outcome
If you need/want to hide content from users for a set period of time, while content is updating, you can instead use
aria-hidden. Its use results in the same outcome, but is much more robustly supported across browser and screen reader combinations.
Try it for yourself: aria-hidden test
See the Pen aria-hidden test by steve faulkner (@stevef) on CodePen.
Could these two attributes be used in tandem, then? Is there a benefit or any potential drawbacks to using both, so that you’re still getting the benefits of aria-busy in those browsers that support it?
It’s redundant, but would it be worth doing
aria-busy="true"as a way of creating a backwards compatible pattern? Or do you think this would be too confusing to future developers? I’m thinking of how we duplicate
to make sure there is common support.