-
Notifications
You must be signed in to change notification settings - Fork 2
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
feat(DeleteModal): first version #3
base: main
Are you sure you want to change the base?
Conversation
672ce79
to
5f46c9a
Compare
} | ||
> | ||
<TextInput | ||
aria-label="Delete modal input" |
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.
Aria labels need to be configurable for internationalization purposes
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'd recommend using the text that displays above the text input as the aria-label for this text input. This text visibly functions as the text input label, and it would be better to reference the visible text, rather than require consumers to specify this text in 2 places.
You can do this by providing an id
on the div that wraps this text, and an aria-labelledby
attribute on the <TextInput>
component that references the id
value for the text.
But I do agree with @nicolethoen's comment above that this text needs to be configurable:
Type RedHatAwesome to confirm deletion:
{error && ( | ||
<Alert | ||
data-testid="delete-model-error-message-alert" | ||
title={`Error deleting ${itemToDelete}`} |
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.
same with titles
5f3639c
to
f269284
Compare
f269284
to
3de93ef
Compare
These examples look great! Something I'd like for us to consider as we build out components is to make sure we aren't inadvertently promoting microcopy patterns that we don't want. For example, for the extra destructive variant includes the following message in the original content design document:
But this content pattern isn't reflected in the example. We can and should reference our design/content patterns as part of these examples under the design guidelines tab, but I'd also like to consider how content patterns are reflected in the UI component examples. Consumers are likely to assume that UI component examples embody recommended patterns and will not refer to design guidelines to confirm otherwise. One option is to use contents that are clearly placeholder text (i.e. text that describes what type of contents are recommended). Another option is to use contents that demonstrate the pattern. Or we could do a mix of both, for example:
@nicolethoen @simrandhaliw - Do you have any preferences on this? |
Closes #2