-
Notifications
You must be signed in to change notification settings - Fork 364
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 docs for new banner #748
Conversation
Keep the message concise and direct. Don't use headings or multiple type sizes in banners, rely on the default paragraph size and use the title when appropiate. | ||
|
||
Don't show more than one banner at a time. For more information, see this article on [alert fatigue](https://www.nngroup.com/videos/alert-fatigue-user-interfaces/). | ||
|
||
## Accessibility |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you confirm that none of the proposed Banner updates affect our existing a11y guidance?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I'd love to get this info form @ichelsea
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding this to my list of things to look at this week!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, this entire a11y section was written up form the work that @lindseywild and @khiga8 did, so it's valid! There are a couple of things that we want to adjust based on feedback from engineering office hours earlier this week that has also been on my to-do list to get to.
We can create a separate PR for that if you want to get this one merged, or I can add to it before this one is merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add it to this PR. We will keep it open until the react components are implemented and shipped, so it will be open for a bit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good start!
content/components/banner.mdx
Outdated
/> | ||
<Box as="p" mt="0"> | ||
<h4>Title</h4> | ||
Use a title to consisly present the topic of the banner when the message of the banner is complex and too long to scan. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add something about title being required but may be visually hidden?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@joshblack is this how we implement it, or is there a separate a11y title which will just use the title the user defines if they do?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lukasoppermann I think this is how it's implemented now where the title is required but may be visually hidden 👍 At the moment, this would mean they wrap the title in VisuallyHidden
but we could also simplify this with a dedicated prop if that would be helpful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure if this is the right place for a discussion, but I am a bit afraid that if the title is not hidden by default, we will get a lot of duplicates with title and body being the same text.
My only thought to improve this would be to have two props like aria-title
and title
where aria-title
is set to title
if present. So, using typescript we could require on of the two to be set.
But I am no react dev and this may be an uncommon or anti-pattern.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Just left a comment/question.
Co-authored-by: Katie Langerman <18661030+langermank@users.noreply.github.com> Co-authored-by: Josh Black <joshblack@github.com>
61f7885
to
a3181fc
Compare
2b654c3
to
f5cdb97
Compare
Looks good to me. I'd "approve" but waiting until this is out of "draft". Just ping me when you're officially ready for a review 🙂 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for getting this documentation going, @lukasoppermann!
I have a couple fundamental thoughts around our suggestions vs our inline messaging that's coming. Should we write like we don't yet have that component or write like we will have that component soon?
|
||
#### Critical | ||
|
||
Use critical banners to signal critical errors, system failures, or necessary destructive actions. Examples: form validation error summary, repo deletion confirmations. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I'm following the repo deletion confirmation example. Right now if you delete a repository, you get a blue banner at the top confirming deletion. I wouldn't use the critical banner because even though it was destructive, it was a successful action. We should only be using them to bring attention to failed actions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not talking about the once it is deleted, but rather before you delete.
However, I think this was somewhat recently removed. Is there another good example?
Keep the message concise and direct. Don't use headings or multiple type sizes in banners, rely on the default paragraph size and use the title when appropiate. | ||
|
||
Don't show more than one banner at a time. For more information, see this article on [alert fatigue](https://www.nngroup.com/videos/alert-fatigue-user-interfaces/). | ||
|
||
## Accessibility |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, this entire a11y section was written up form the work that @lindseywild and @khiga8 did, so it's valid! There are a couple of things that we want to adjust based on feedback from engineering office hours earlier this week that has also been on my to-do list to get to.
We can create a separate PR for that if you want to get this one merged, or I can add to it before this one is merged.
Co-authored-by: Chelsea Adelman <40274682+ichelsea@users.noreply.github.com>
@ichelsea I merged now as the banner already shipped, please add your improvements via a separate PR. 🙏 |
Only merge when the react component is implemented