Accessible Rich Internet Applications Suite — WAI-ARIA — defines a way to make Web accessible to people with any type of disabilities and it’s also a good practice for skeleton loaders.
Attributes such as tabindex
, role
, and aria-*
are essential for assistive technologies such as screen readers. So that, users with any type of visual disabilities can understand that the specific state of the fragment of your page is currently loading, having that validated by using different tools, such as Lighthouse integration via Chrome Devtools, as an example.
Instructor: [0:00] Now we can add aria attributes on the HTML of our skeleton, so that users with any type of visual disabilities can understand that specific state of the fragment or a page is current loading.
[0:15] Let's add some attributes. The first one is tabindex, we add this as zero so screen readers cannot have this focused. The second attribute is role, so it can say to screen readers that's a ProgressBar. The next attribute is aria-busy and we add this value as true, so that we can make sure that screen readers understand that it's a content that will be updated.
[0:46] Since it's a ProgressBar, we need to add margin parameters. One is aria-valuemin as and aria-valuemax as 100, because it's a ProgressBar. The next attribute is aria-valuetext. This is quite important, so we can pass the text that will be read by the screen readers. The screen we're using "Please wait."
[1:13] Now we have all the attributes required for the screen readers and other assistive technologies. Let's check the effects of our changes in Lighthouse. First, we need to run our local server, by run npx serve and the local folder. With that, we have the local URL that we can check in our browser.
[1:36] After that, we can open Lighthouse, make sure that we have Accessibility icon pressed, and run the audition. As soon as Lighthouse finished the audition, a new page will be opened with all the items that were checked. The items that need to be checked manually are more than these, the items that were passed in the audition.
[2:00] All the aria levels and the aria-hidden="true", for example, and role, and all the relevant information for the screen readers will be there as green items, which means they are good to go.
Are
role=progressbar
and accompanyingaria
attributes suited for a skeleton state of a component?If you have multiple skeleton components then you'll be rendering a large amount of progress indicators to the user which may be read to the user.
You also don't provide a current value of progress to the user, so setting a max and min value doesn't make much sense?
Just my 2 cents, but I think the aria roles and attributes may negatively benefit the accessibility of the page.