-
Notifications
You must be signed in to change notification settings - Fork 231
docs(tags): update a11y docs #5676
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
base: main
Are you sure you want to change the base?
Conversation
|
📚 Branch Preview🔍 Visual Regression Test ResultsWhen a visual regression test fails (or has previously failed while working on this branch), its results can be found in the following URLs:
Deployed to Azure Blob Storage: If the changes are expected, update the |
Tachometer resultsCurrently, no packages are changed by this PR... |
b075661
to
ac54c75
Compare
`<sp-tags>` is a `role="list"` container that manages a collection of `Tag` elements. It has an `aria-label` attribute that defaults to "Tags". | ||
|
||
`<sp-tags>` uses the roving tabindex pattern for efficient keyboard navigation. `Tab` enters the collection, arrow keys navigate between tags, and only deletable tags are focusable. The container provides `role="list"` semantics with each tag as a `role="listitem"` for proper screen reader support. |
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 great but can we extend this a bit and make it more granular for the users? I was thinking can we add Mouse and keyboard interaction sections under Accessibility
and add the usage patterns for the same.
**Mouse**
Read-only tags: Do not get mouse functionality besides a mouse cursor on hover and do not have interactive functionality.
**Keyboard**
Read-only tags: Can not be operated by a keyboard and have no interactive functionality.
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 know Rajdeep has a few comments here, and I added a couple more that I don't consider to be blockers -- looks good to me!
- **Tags**: The container component (`<sp-tags>`) that manages a collection of `Tag` elements. | ||
- **Tag**: The individual tag element (`<sp-tag>`) that represents a single tag. [Read more about the `Tag` component.](/components/tag/) | ||
|
||
### Examples |
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 don't think there's anything wrong with the examples as they are right now, but they could be consolidated similar to how other components have been done by using tabs.
Or, honestly, we don't need to show 3 different examples for tags to show no visual, avatar, icon, etc., since that can be covered by the singular tag component, so one single example might be fine.
Not a blocker as far as I'm concerned, just some food for thought!
- **Tags**: The container component (`<sp-tags>`) that manages a collection of `Tag` elements. | ||
- **Tag**: The individual tag element (`<sp-tag>`) that represents a single tag. [Read more about the `Tag` component.](/components/tag/) | ||
|
||
### Examples | ||
|
||
```html-live |
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.
Is there a preference between html
and html-live
? I see more html
in the components we've already done but am not sure if there's a specific preference.
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.
Nice work! For clarity, I think maybe we should add either some headings for the different variant options, but other than that, I only have suggestions!
|
||
### Accessibility | ||
|
||
`<sp-tags>` is a `role="list"` container that manages a collection of `Tag` elements. It has an `aria-label` attribute that defaults to "Tags". |
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.
Just to sort of follow Rajdeeps suggestions, what do you think about changing "Tag
elements" to "
` elements?
- **Tags**: The container component (`<sp-tags>`) that manages a collection of `Tag` elements. | ||
- **Tag**: The individual tag element (`<sp-tag>`) that represents a single tag. [Read more about the `Tag` component.](/components/tag/) | ||
|
||
### Examples |
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.
Do you think we should add any additional headings to like, name the tag variants? Or at least have a heading for "With an image" or "With an icon" something? We could do a set of tabs, too.
Just a thought!
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.
Also- should this be "Examples" or "Options?" Looks like the documentation structure has "Options" instead.
|
||
`<sp-tags>` is a `role="list"` container that manages a collection of `Tag` elements. It has an `aria-label` attribute that defaults to "Tags". | ||
|
||
`<sp-tags>` uses the roving tabindex pattern for efficient keyboard navigation. `Tab` enters the collection, arrow keys navigate between tags, and only deletable tags are focusable. The container provides `role="list"` semantics with each tag as a `role="listitem"` for proper screen reader support. |
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.
oh oh oh! I was just looking into roving tabindex. Want to link to the documentation?
/tools/roving-tab-index
Co-authored-by: Rajdeep Chandra <[email protected]>
Co-authored-by: Rajdeep Chandra <[email protected]>
Description
Improving the accessibility documentation of components.
Related issue(s)
SWC-416
Author's checklist
Reviewer's checklist
patch
,minor
, ormajor
featuresDevice review