-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Button and link a11y docs #924
Conversation
- Added "keypress" language to overview - Added accessibility section for current features
|
||
## Accessibility | ||
|
||
<!-- content-for: android --> |
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.
iOS and Android content for the button page, since there are separate tabs. We don't currently have native-specific guidance so I've linked to the platform best practices.
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.
Although it's a bit awkward from the "Web" perspective to begin the section with external resources that don't apply to web, my understanding is that this will eventually change, when we have native-specific guidance.
To make it more clear what content applies to the reader:
-
We could add an intro sentence under the Accessibility heading that lets readers know that the accessibility guidelines for the button component differ for Web, Android, and iOS. This sets the reader up to expect to look for the content that applies to them.
-
Perhaps rearrange the leading sentences to start with "For Android, see Material Design ... " and "For iOS, see Apple's ..."
-
Perhaps add Android, iOS, and Web headings
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.
@sadiesaurus The sections here display on the web, iOS, and Android tabs in the UI in the style guide, which is what the <! content-for: ...>
tags are doing in the file. The Mobile-specific example screenshot is showing what would show up for Android on that tab, while the other specific content shows up for each tab specified. That's what the first item in the 🎩 recommendations is doing, pulling from the PR that @kaelig worked on to do this formatting. Let me know if that's clear!
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.
Ohhhh, yes now I see. I didn't 🎩 it properly last time. This works well!
Please disregard my comment! 😅
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 agree that headings would help with the Markdown readability in GitHub itself. I couldn't find a solid and elegant way to make it work :/
@BPScott and I might have cycles to look into it later this year.
@kaelig, would particularly love any thoughts in relation to what you're tinkering with for formatting for this content. |
Dropped a question about the heading hierarchy in the related style guide PR: https://github.com/Shopify/polaris-styleguide/pull/2493#issuecomment-456935369
Fixed! |
Co-Authored-By: dpersing <devon.persing@shopify.com>
Co-Authored-By: dpersing <devon.persing@shopify.com>
Co-Authored-By: dpersing <devon.persing@shopify.com>
Co-Authored-By: dpersing <devon.persing@shopify.com>
@kaelig Can you take another gander? |
src/components/Button/README.md
Outdated
- Use the `ariaControls` prop to add an `aria-controls` attribute to the button. Use the attribute to point to the unique `id` of the content that the button manages. | ||
- If a button expands or collapses adjacent content, then use the `ariaExpanded` prop to add the `aria-expanded` attribute to the button. Set the value to convey the current expanded (`true`) or collapsed (`false`) state of the content. | ||
- Use the `disabled` prop to set the `disabled` state of the button. This prevents merchants from being able to interact with the button, and conveys its inactive state to assistive technologies. | ||
- Use the `ariaPressed` prop to add an `aria-pressed` attribute to the button. Use the `pressed` prop to add a pressed-style to the button as well. |
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.
Added to document use for ariaPressed
and pressed
: #984
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.
UNRELEASED.md
Outdated
- Added `Stack.Item` properties and description to [style guide](https://polaris.shopify.com)’s ([#772](https://github.com/Shopify/polaris-react/pull/772)) | ||
- Added accessibility documentation for the button and link components ([#924](https://github.com/Shopify/polaris-react/pull/924)) | ||
- Added accessibility documentation to the resource list and data table components ([#927](https://github.com/Shopify/polaris-react/pull/927)) | ||
- Added accessibility recommendations for the caption component ([#928](https://github.com/Shopify/polaris-react/pull/928/)) |
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'm a bit confused as to why some of these unrelated entries are in this PR?
* Added accessibility section for the button component * Added accessibility section for the link component * Added entry for Unreleased.md
This PR includes component-level accessibility information for the link and button components, to appear in the repo and in the style guide. Both pages are included because the button content refers to the link content.
WHY are these changes introduced?
Adds component-level documentation as part of the style guide accessibility documentation project. This content is added after the examples and props, before best practices.
WHAT is this pull request doing?
README.md
files.UNRELEASED.md
file under Documentation.How to 🎩
polaris-styleguide
to get the changes that support the accessibility section.polaris-react
and run the instructions for testing in a consuming project.polaris-styleguide
tab, rundev up && dev start
.Screenshots
Do/Don't example
Keyboard content example
Mobile-specific example