Hello everyone, this is Luke with Online ADA. In this video, I’m going to cover progress bars and very simple steps you can take to ensure you’re making them fully accessible.
Now, the purpose of a progress bar is to provide a visual representation of a computer operation. Most notably, when you are trying to display the user when something is downloading or uploading, or you’re just guiding them through a multi-step form.
As you can see, in this example, there are two different progress bars. The first one is constructed using semantic HTML. The second one is a custom component, constructed with some extra labeling that can be very helpful to many different users. Both these examples are accessible, but different a couple of ways which I will explain.
The purpose of this video is to help you understand why these progress bars are accessible and to provide you with the knowledge and ability to go make your progress bars accessible, because in my opinion, progress bars are very useful and handy element to use while developing any kind of application web page. I use them all the time.
Now, the things we need to look out for when constructing the progress bar are, A, identifying how many steps and which steps a user currently is on. And, B, identifying when context is changed when moving from step to step.
There’s only really one real WCAG rule that applies directly to progress bars. That is rule 1.3.1, Info and Relationships. This is a Level A WCAG guideline and it is stated as follows. Information structure and relationships conveyed through presentation can be programmatically determined or are available in text. Pretty straight forward.
Now, according to this WCAG rule, we need to ensure that information that is being displayed, via these progress bars here, is preserved when the content is being read aloud by a screen reader. This can be achieved in a couple of ways. One, using semantic HTML, which is always a good idea, which will have proper ARIA labeling and well definitions baked in. And two, using proper ARIA construction with custom HTML.
The proper ARIA labels that are needed when constructing this yourself are going to be value min, value max, value now and the role of progress bar on the element you’re gonna be using as a progress bar.
Take a look again at this example, number one. We can see, as I click through these steps buttons, the bar progresses and regresses, representing how close I am, or far I am from completion. This is great visual representation, but what if a blind user is navigating this page? How are we going to convey the information in that case?
Well, this is where the proper use of ARIA comes into play. If we look here, I’m using this progress semantic HTML element. It will have the role of progress bar assigned by default, so I won’t have to manually add it, like I have here in the second example. See, role progress bar. The role progress bar will actually activate an audible tone on change of the progress bar value. So as you get closer to completion, the tone will be at a higher pitch, and as you regress, the tone will be at a lower pitch. This coupled with the value attribute here, will satisfy the WCAG rule 1.3.1 by allowing the current progress to be programmatically determined by a screen reader, as well as the changing context being audibly alerted.
So, if we were to load this page with a screen reader activated, you would notice, as you click through these buttons, you would hear a tone. You would also be able to click on the progress bar itself and be read allowed the current value of the bar. This is achieved by adding a tab index to the bar and making it tabbable and clickable.
Now, moving on to the second example. This example is not so different from the first, just that I have constructed it without using semantic HTML. Styled it a bit and added some additional labeling, to make things even more clear to the user. The functionality is still the same. As I progress and regress the bar, there will be a tone that alerts to change and you can still click on the bar and be read allowed the current value. One major difference on this front in here, is that as I click the buttons, the screen reader will not only play a tone, but the current bar value will also be read allowed as I click. I have achieved this using some very simple ARIA labeling, which I will show you.
Now as you see here, in the second example, you’re not going to see the progress element. Instead, I have used a div with the role of progress bar. Because I’m not using semantic here, I have to specify a couple of ARIA labels in order to have this behave the same. We have ARIA labels value min, value max and value now. Value now allows the current value of the bar to be determined and is the attribute you will lead to dynamically update, along with any other textual representation of the progression you are trying to display. Just like here on the element itself I had the attribute value. This is what I was updating dynamically in that example. So, value max and value min allow the minimum and maximum values of the bar to be programatically determined by the screen reader.
Also I have here, above the bar itself, a label displaying the current bar value. Since I have the ARIA label live set to assertive, the value will be read aloud as the bar changes. Describing here as I’m changing this, it’s going to play at tone, right. And also read aloud the current label I have set. Now in this case you could also use the ARIA label, value text, to set a textual value for the bar that will be read aloud on click, instead of the value now attribute. So that’s pretty simple, you’re just gonna put, not in caps, ARIA value text. And you can set it to where you want. Step one of three or four, say, right. Now, unclick the bar. It will read this value instead of the actual number value you have set here.
This can be used in the case where you have values like small, medium and large, maybe, which correspond to values, number values, like one, two and three. So you wouldn’t want the screen reader to read aloud two. You want to read aloud medium. So, that’s when you will use that. So again, if you were to look here at this example two with a screen reader, you’ll be read aloud tone, right. You would be read aloud the label and it is very visually clear what step you’re on. So, as you can see, it is extremely simple to make your progress bars accessible.
All you have to do is make sure you’re following the WCAG guideline, 1.3.1 and making sure that the information, as visually provided by the progress bar, can also be programmatically determined by a screen reader.
Well, I hope this video helped and till next time, happy coding.