-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add accessibility data to each asset #803
Comments
If this is reported through the schema and Carbon config YML files, because YML files are committed into Git repositories, even though we're saving a binary "yes/no" value, we could look up Git history to determine when the accessibility status was last changed, and by who. I don't expect that this would happen often. But, it's possible if wanting to do a manual audit of accessibility status over time. |
We discussed this epic on the Carbon Accessibility Guild call and everything was well received! 🎉 Two areas of discussion were whether a pass should be both keyboard operability AND accessibility checker - or just a clean run with the accessibility checker. My team is going to discuss that further on our Monday planning call, but we (IBMa) were all pretty much in agreement that it should be both operability and checker (as stated in the Description above). As a side note to that, there was talk about badge (icon) levels vs multiple badges/icons. For example: passed accessibility checker - one “badge”/icon, passed accessibility checker AND keyboard operability two badges/icons… OR if just one, would there be a multiple levels of that icon to show that multiple tests have been passed etc. It's an interesting idea, but for this initial implementation I still prefer to keep it as simple as possible - one binary of yes, no, or not specified. Josh said he’d be happy to provide some input around CI/CD automation. |
IBM Accessibility team met and concluded that we would like to stick with the original plan that at this initial stage accessibility will be reported on a binary basis where an asset is accessible when:
This accessible value could be recorded as: not specified, yes, or no. |
@marcjohlic thanks for following up! We have this queued up for the v1.1 release (if you have the public ZenHub extension installed you can see that in the right column.) We'll reach out when this is closer to getting in a sprint to confirm the plan. |
@mbgower here's the issue for how we could add an accessibility status to each asset. Please let us know if you have any thoughts and suggestions. |
@mattrosno here's the link to the video that @mbgower and Jess Lin created for contributors on Accessibility testing components in Storybook. Let me know if you run into any Box issues accessing/downloading the video. |
Summary
Hill 1A reads:
A crucial aspect of completeness is knowing to what degree is each asset (e.g. component) accessible. After talking with Marc Johlic, we don't have to go to lengths for each asset to specify which WCAG rules they conform to (e.g. WCAG 2.1 AA.) Instead, accessibility can be reported on a binary basis where an asset is accessible if:
This accessible value could be recorded as: not specified, yes, or no.
Per Marc, there's no need to require accessibility tests for high contrast, with screen readers, etc. at the component level. Although not required, the more we test (and communicate that the tests have happened), the better confidence we can instill for our users.
In addition to this, each asset can be documented with an accessibility tab that specifies what Carbon provides, design recommendations, and development considerations. Related open issues:
Job stories
What value will this deliver?
Acceptance criteria
What requirements must be met to complete this request?
Other considerations
The text was updated successfully, but these errors were encountered: