doc: Multiple progress bars – accessibility?

[rugk]

Firefox 85, Linux

I do guess there is a problem with the doc example of a progress bar with multiple bars in one line.

In the stable v4 version and even v5 (linked above), it says something like:

<div class="progress">
  <div class="progress-bar" role="progressbar" style="width: 15%" aria-valuenow="15" aria-valuemin="0" aria-valuemax="100"></div>
  <div class="progress-bar bg-success" role="progressbar" style="width: 30%" aria-valuenow="30" aria-valuemin="0" aria-valuemax="100"></div>
  <div class="progress-bar bg-info" role="progressbar" style="width: 20%" aria-valuenow="20" aria-valuemin="0" aria-valuemax="100"></div>
</div>

This shows one progress bar with three colors (blue, green, turquoise) with the respective widths. Comparison image here:

Now I wonder whether the aria labeling is correct. Actually, what the aria-labels say seems to be that there are three progress bars, does not it?
I would interpret that as following:

• one progress bar from 0 to 100, currently at 15 (percent)
• another progress bar from 0 to 100, currently at 30 (percent)
• another progress bar from 0 to 100, currently at 20 (percent)

Al in all, the aria says these are 300% in total.

I guess this is not what it says visually, respectively should say in aria-terms, is not it?
Would not it have to be calculated, so that all of the bars together represent one progress bar from 0 to 100?

(use case:) Say this shows e.g. what amount of money has already been pledged, what has been transferred and what has been written into accounting or whatever (e.g. "what amount has been spent"). So the previous progress bar always includes the next one.
(This is actually similar to a real-world issue that made me open this problem. See downstream issue: okfde/froide#414)

As such, an HTML for this should rather be like this, should not it?

<div class="progress">
  <div class="progress-bar" role="progressbar" style="width: 15%" aria-valuenow="15" aria-valuemin="0" aria-valuemax="100"></div>
  <div class="progress-bar bg-success" role="progressbar" style="width: 30%" aria-valuenow="45" aria-valuemin="0" aria-valuemax="100"></div>
  <div class="progress-bar bg-info" role="progressbar" style="width: 20%" aria-valuenow="65" aria-valuemin="0" aria-valuemax="100"></div>
</div>

Which says (cf. the image above):

• 15% of the money is already in the blue category, say it has been put into accounting
• 45% of the money is in the green category, i.e. has been transferred, this includes the 15% of all money that has been put into accounting
• 65% of the money is in the turquoise category, i.e. has been pledged, this includes the 45% of all money that has been transferred, which itself includes the 15% of all money that has been put into accounting
• and to complete our use case, let's say 100% would be a funding goal, e.g. in crowdfunding.

You show a multi-staged progress after all…
Is not that what such a progress bar is supposed to be shown.

So does not the doc encourage a wrong use of the aria attributes in this case?

Alternative use case

When writing this I know what you might say/mean: It does show one progress and the colors are just for a percentage of what that current progress constitutes.

Due to the lack of a real use-case for this, I make one up: Let's count ducks and their gender… 🦆
Again, we have an aim of 100 ducks/100%. We make a multi-staged progress bar. (the same as above)

• 15% of the ducks do not have a gender categorized or an unknown gender or so (do non-binary ducks exist?), i.e. blue category
• 30% of the ducks are female, i.e. green category
• 20% of the ducks are male, i.e. the turquoise category
• and to complete our use case, let's say 100% would be a the goal. So 100%-65%=35% of the ducks still need to be counted/catched to get to our goal

IMHO this is less of a progress than the first use case, but it may be considered such one, if this is a (scientific) challenge. Also this yields the question whether a real pie chart for that use case would not be more useful.
But given this is a progress and e.g. the first “blue“ category of ducks may get less and less (but may also get larger) a aria markup with individual percentages would be okay.

The question would be whether people do (mis)use the progress bar more as a pie chart, if the categories are mutually exclusive.

The “real” pie chart way?

That said, would not nesting be the proper semantic (and aria) way in this case? Because one value is not mutually exclusive: The 65% of all tested ducks.

As such, this may be more accurate:

<div class="progress">
  <div class="progress" style="width: 65%" aria-valuenow="65" aria-valuemin="0" aria-valuemax="100">
    <div class="progress-bar" role="progressbar" style="width: 23.08%" aria-valuenow="15" aria-valuemin="0" aria-valuemax="65"></div>
    <div class="progress-bar bg-success" role="progressbar" style="width: 46.15%" aria-valuenow="30" aria-valuemin="0" aria-valuemax="65"></div>
    <div class="progress-bar bg-info" role="progressbar" style="width: 30.77%" aria-valuenow="20" aria-valuemin="0" aria-valuemax="65"></div>
  </div>
</div>

Also made a JSFiddle with all of that: https://jsfiddle.net/echdf0yg/20/

In any case, would not this be an advanced example… you likely won't show this in the doc.

Questions

So what matters seems to be whether the progress bars are mutually exclusive. In my first crowdfunding example they are not, and show different progresses in one bar. Thus the aria-tags in the example would be wrong IMHO.
In my second example (ducks) they were mutually exclusive (the colored ones at least), but is this what people really use the progress bar for?

I'd guess the first money example is more of a real-use example and demonstrates a real progress that is relatable: A progress in multiple stages, respectively multiple progress'es in one progress bar – each starting from 0 (the left) up to the value they show.

Well… if you think both variants are okay, then maybe at least change the example code and add a paragraph explaining that aria issue and use-case there?
Also note this was inspired by a real use case where it has been implemented wrongly, based on your example: okfde/froide#414

Quak! Thanks for reading. I hope this may help to improve the doc.

[XhmikosR]

@patrickhlauke your area 👼

[patrickhlauke]

Now I wonder whether the aria labeling is correct. Actually, what the aria-labels say seems to be that there are three progress bars, does not it?

Yes, these are 3 bars, visually stacked together. They are, of course, interdependent, as overall they can't go over 100% total. But that is not a concept that can be conveyed with ARIA. progressbar has no provision for multi-part/multi-step progress bars or similar. So, treat these as three separate progress bars...

• 15% of people like blue
• 30% of people like green
• 20% of people like turquoise

(which, implicitly then leaves 35% of people who are undecided about what colour they like)

That's it, that's all that example shows. You as the author need to make sure the total overall doesn't exceed 100% (which, if you use actual data to fill this in, basing this always on the same overall 100%, it won't). It is, to go to your later idea, essentially a rolled-out pie chart, a stack. all of it showing different parts that make up the 100%. At least that's what our example there in the docs tries to show.

As such, an HTML for this should rather be like this, should not it?

<div class="progress">
  <div class="progress-bar" role="progressbar" style="width: 15%" aria-valuenow="15" aria-valuemin="0" aria-valuemax="100"></div>
  <div class="progress-bar bg-success" role="progressbar" style="width: 30%" aria-valuenow="45" aria-valuemin="0" aria-valuemax="100"></div>
  <div class="progress-bar bg-info" role="progressbar" style="width: 20%" aria-valuenow="65" aria-valuemin="0" aria-valuemax="100"></div>
</div>

I'll admit that that would not be immediately obvious to me as a representation even as a sighted user...but hey, it's your markup/data, if you think that is clear from the chart to your audience, then I guess that's what you'll want to convey via the aria-valuenow. It seems...hard to grok through, even for a visual user. maybe add a text explanation before it for all users to understand (both AT users and sighted users)

You show a multi-staged progress after all…

Well technically, we're not really defining what that thing is trying to show. just that you can have/overlay multiple bars into a single visual widget. how you use it/what you want to represent with it is up to you.

But given this is a progress and e.g. the first “blue“ category of ducks may get less and less (but may also get larger) a aria markup with individual percentages would be okay.

Again, progressbar has no concept of how to express interrelationships/subdivisions.

<div class="progress">
  <div class="progress" style="width: 65%" aria-valuenow="65" aria-valuemin="0" aria-valuemax="100">
    <div class="progress-bar" role="progressbar" style="width: 23.08%" aria-valuenow="15" aria-valuemin="0" aria-valuemax="65"></div>
    <div class="progress-bar bg-success" role="progressbar" style="width: 46.15%" aria-valuenow="30" aria-valuemin="0" aria-valuemax="65"></div>
    <div class="progress-bar bg-info" role="progressbar" style="width: 30.77%" aria-valuenow="20" aria-valuemin="0" aria-valuemax="65"></div>
  </div>
</div>

That invalid because you don't have a role="progressbar" on the wrapper <div>, so the aria-valuenow, aria-valuemin and aria-valuemax are invalid/won't be announced - at least they shouldn't, as they're meaningless attributes unless on an element with a role of range, scrollbar, separator, slider, spinbutton or indeed progressbar - see for instance the definition for https://www.w3.org/TR/wai-aria-1.1/#aria-valuemin

And before you add role="progressbar" to that outer <div>, note that elements with role="progressbar" can't be nested inside other progress bars (at least not to my knowledge).

So what matters seems to be whether the progress bars are mutually exclusive. In my first crowdfunding example they are not, and show different progresses in one bar. Thus the aria-tags in the example would be wrong IMHO.

If you're using this component in this way (which, as said, may not be immediately obvious to people), then yeah. But I'd say that's more of a special case/scenario here

In my second example (ducks) they were mutually exclusive (the colored ones at least), but is this what people really use the progress bar for?

They may well do that, yes.

Well… if you think both variants are okay, then maybe at least change the example code and add a paragraph explaining that aria issue and use-case there?

I guess adding a single sentence that reminds authors to consider what/how they're actually using this component (stacked parts of a single 100%, or something more complex) and to carefully consider what the aria-valuenow should be might be worth it. but because there's so many variations of what people may want to use this for (as demonstrated in this lengthy discussions already), I'd say it'd be overkill to try and make up examples and explain all the nuances.

Also note this was inspired by a real use case where it has been implemented wrongly, based on your example: okfde/froide#414

Yeah, but as I commented there, they seem to have fundamentally borked this even from a CSS point of view, and then transposed that same mistake into their aria-valuenow (width:90% plus width:24% in their CSS, before we even look at the ARIA where they replicated those values again). So this feels more like an error with their basic maths skills, and not to be blamed on our example...