Design System Staging Review - Accessibility Feedback - Converted components: Alert and Additional info

[briandeconinck]

VFS actions

• [ ] Assign this ticket to the team member(s) responsible for addressing feedback provided by Platform.
• [ ] Comment on this ticket:
  • [ ] If the Platform reviewer has any Thoughts/Questions that require responses.
  • [ ] When Must feedback has been incorporated. As appropriate, link to any other GitHub issues or PRs related to this feedback.
  • [ ] When Should/Consider feedback has been incorporated, or if any feedback will not be addressed. As appropriate, link to any other GitHub issues or PRs related to this feedback.
• [ ] Close the ticket when all feedback has been addressed.

Thoughts/questions

-

Feedback

Practice areas will document their feedback on the VFS-provided artifacts following the Must, Should, and Consider Framework. Platform reviewers may also provide additional notes that don’t comment on the artifacts themselves but are important for implementation (eg. engineering/coding notes).

Alert

• Must: Sounds like this is already in progress, but I'll include it here for completeness. Currently, background-only alerts can be configured to have no icon. That means the only indicator that it's anything other than regular text is a background color that's not especially high contrast against the rest of the page. Icons should always be displayed.

• Should: Since icons don't have any alternative text, the semantics of the alert type aren't communicated to screen reader users unless it's an error alert---and even then, it's not communicated as an error, but rather it gets priority for how the screen reader announces it and users can infer that it's more important.

  And I think that's okay! I don't feel like adding alt text to the icons would accomplish much in terms of clarifying to users what's happening. But I do think it would be worth updating the guidance that alert copy needs to clearly convey the severity/urgency of the alert. The heading of the alert and the body of the alert should indicate if user action is required immediately, or if there's some potential negative consequence, or if a user action has succeeded.

  • In the meeting, Matt's question about ARIA roles besides alert has me thinking it might be possible to explore defining custom roles for each alert type using aria-roledescription. But that's not a pattern I've seen used elsewhere and we would want to test the heck out of it to make sure we're actually doing something useful for screen reader users.
• Consider: Just noting here that when an alert is dismissible there's no visible text to go with the close button, ie. the tertiary icon button style. But implementing that would have to be reconciled with the close-btn-aria-label property somehow, since a hardcoded "CLOSE" might come into conflict with whatever is used for that property.

Additional Info

• Consider: Right now, the additional info trigger is coded as an a role="button". It's fine and it works with every assistive technology I've tested with, so no change is needed. But in terms of material honesty and keeping code clean, I'd love to change that to just be a button some day.

[caw310]

Hey team! Please add your planning poker estimate with Zenhub @Andrew565 @ataker @harshil1793 @it-harrison @jamigibbs @micahchiang @nickjg231 @powellkerry @rmessina1010