Rework progress bar markup and styles #36831
Conversation
Logically moves the various `role` and `aria-` attributes to the `.progress` element itself, leaving the `.progress-bar` to be used purely for the visual presentation. This fixes the problem #36736 that in certain browser/AT combinations, zero-value/zero-width progress bars are completely ignored and not announced. For multiple/stacked progress bars, this PR introduces a new wrapper and class `.progress-stacked`, to accommodate for the fact that with the more logical structure above, we need full `.progress` elements with child `.progress-bar` elements, and can't get away with the fudge we had before of having a single `.progress` with multiple `.progress-bar`s. Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
|
Video using NVDA/Chrome - note that, compared to the video in #36736, the zero value progress bar is now correctly announced. bootstrap-pull36831.mp4 |
|
Also added a tentative note in the migration guide for this change https://deploy-preview-36831--twbs-bootstrap.netlify.app/docs/5.2/migration/ |
patrickhlauke
force-pushed
the
patrickhlauke-issue36736
branch
4 times, most recently
from
6931884 to
0fa4c79
Compare
patrickhlauke
force-pushed
the
patrickhlauke-issue36736
branch
from
0fa4c79 to
88cd436
Compare
patrickhlauke
force-pushed
the
patrickhlauke-issue36736
branch
from
8920968 to
181584c
Compare
|
@mdo as suggested in Slack, I added two callouts showing the old structure and explaining why we changed them https://deploy-preview-36831--twbs-bootstrap.netlify.app/docs/5.2/components/progress/ |
Co-authored-by: Julien Déramond <julien.deramond@orange.com>
Turns out they're needed for correct positioning of text inside progress bar
There was a problem hiding this comment.
LGTM! @mdo I let you double check the migration guide modification.
…progress page, rewrite some content
|
Reworked the docs changes to keep the differences to the migration guide (which we'll also include in our blog post). Let me know how this reads @patrickhlauke @julien-deramond. |
|
|
||
| The problem with this structure is that progress bars with a zero value are completely ignored, and not announced, by assistive technologies. While the legacy structure will still be displayed correctly, we strongly recommend updating to the new structure. | ||
| {{< /callout >}} | ||
| ### Width |
There was a problem hiding this comment.
I understand why this is modified like that but I've found it weird when I read it to have a "Sizing > Height" section that explains how to change the height of the entire progress bar and a "Sizing > Width" section that doesn't explain how to reduce the width of the progress bar but rather its content; its value.
There was a problem hiding this comment.
I can see what you mean, but in a sense both are about sizing the width and height of the bars themselves...just that the height is set for the whole of the progress element. Maybe changing the first heading to "Bar sizing"?
There was a problem hiding this comment.
Made a tweak to the sizing section @julien-deramond @mdo to make it clearer
Logically moves the various
roleandaria-attributes to the.progresselement itself, leaving the.progress-barto be used purely for the visual presentation. This fixes the problem documented in #36736 that in certain browser/AT combinations (NVDA, VoiceOver), zero-value/zero-width progress bars are completely ignored and not announced.For multiple/stacked progress bars, this PR introduces a new wrapper and class
.progress-stacked, to accommodate for the fact that with the more logical structure above, we need full.progresselements with child.progress-barelements, and can't get away with the fudge we had before of having a single.progresswith multiple.progress-bars.Note that the old markup structures still work with this change, so this could be considered a non-breaking change - though one we definitely want to highlight as it's more accessible (as it now guarantees that zero-value/zero-width progress bars, whether on their own or as part of a multi/stacked bar, are actually announced)
Closes #36736