Replies: 1 comment 2 replies
-
@laurenmrice Other considerations around Progress Bar from the review are captured as comments in the Progress bar usage and style pdfs. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
The Progress bar component is a maturing component. There are several considerations which could be emphasized by Carbon to improve the user experience, falling into 2 categories:
Is it worth exposing the Complete and Error icons programmatically?
The component progresses to a resolution of either success or error. However, due to the component and poor cross-platform support, we cannot have faith that such information is exposed to the user agent or assistive technology. Is it worth giving the Success and Error icons an accessibility supported name and exposing them (they are currently aria-hidden)
The advantages of this are:
The disadvantage of this:
aria-valuenow
)it could potentially cause some redundant output. However, it does not appear that any of the supported aria attributes would do so. Some testing could confirm.Is it worth making the progress bar's results persistent?
Currently, the usage guidance allows teams the discretion to remove the entire progress bar and its results after it successfully completes. The main problem with this is that it's possible that someone does not see the success. If there is no persistent information about success, someone may assume it never ran.
This should only be a problem with success results; there is a requirement that items in error persist. I'd like Carbon to consider if at least the success icon could persist to show that an action has completed. It would take up minimal space. Especially if combined with the first idea (to expose the icon to the accessibility tree), it could be beneficial to a number of user groups.
Beta Was this translation helpful? Give feedback.
All reactions