If there is an error in loading of new sections, aria-busy="true" will still be set, leaving the entire feed inaccessible.
Although this example doesn't fetch new content, a real-world example probably would, which makes it more likely for an error to happen (e.g., the user temporarily loses network access).
The code should be resilient to any error, maybe show an error message when an error does happen, and remove the aria-busy attribute.
The design pattern should also discuss this, I think.
I noticed this while writing a new section for aria-busy in https://github.com/w3c/aria-practices/pull/1027.
_Originally posted by @zcorpan in https://github.com/w3c/aria-practices/issues/565#issuecomment-562136547_
@zcorpan are you proposing a change in the actual code for the example? I agree with the principle, but right now there's nothing there that allows for the existence of an error condition, since it's all faked with setTimeout.
One thing we could do (and this makes the most sense to me) is update the example to actually fetch data from a JSON file, and have real error handling. Then we could add both aria-busy="false", and an error message in a live region.
Yes, I think the setTimeout is a bit silly. Using fetch would be better.
If there are no objections, I'll make a PR changing the feed example to use fetch
@smhigley might need a polyfill to use fetch unless IE11 support has dropped
I really want to drop support for IE11 馃槄. But yeah, will use this for now: https://github.com/github/fetch
Most helpful comment
@zcorpan are you proposing a change in the actual code for the example? I agree with the principle, but right now there's nothing there that allows for the existence of an error condition, since it's all faked with
setTimeout.One thing we could do (and this makes the most sense to me) is update the example to actually
fetchdata from a JSON file, and have real error handling. Then we could add botharia-busy="false", and an error message in a live region.