-
Notifications
You must be signed in to change notification settings - Fork 7
DSD-1900: ARIA landmarks guide #1806
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: development
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
export const WithSearchElement: Story = { | ||
render: () => ( | ||
<search> | ||
<SearchBar |
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.
SearchBar
still contains role="search"
so this is technically not the appropriate pattern (and it won't be until v4 where the DOM is updated). I think you should replace SearchBar
with separate heading, input, button, and checkbox components.
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 true. Then maybe this should go into v4
since the original intention of this guide was to clarify how the search landmark should be used, and I'd like to keep this specific example with Searchbar
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.
Discussed in standup– this is not gonna go into v4
so replacing the searchbar with a TextInput
for now so the pattern is 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.
This is great, thanks! Just some minor comments.
|
||
Landmarks can be indicated with `role="landmark"` or by using the landmark's HTML element. | ||
|
||
**Some Reservoir components already define their own landmark roles, and some landmarks must be defined by the consuming app since they could wrap many components.** |
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 makes it seem like the components are defining roles beyond the eight native ones.
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.
Does this update make it clearer
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.
Minor comments but not blockers.
render: () => ( | ||
<search> | ||
{/* TODO: Replace with Searchbar component. */} | ||
<TextInput id={"search-input"} labelText={"Search"} /> |
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.
nit: you don't need braces around string prop values.
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 could also use a simple button component.
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 learned a lot from this! Some small suggestions included.
|
||
Elements under [Navigation](../?path=/docs/components-navigation) should be wrapped by the `navigation` landmark. | ||
|
||
### region |
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 wonder how to differentiate between complementary and region. Could you include something about how to think about this?
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 a note below
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.
Great! Small typo: "content should supports or modifies" - remove extra s's.
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.
Further, should region
landmarks be nested inside the main
landmark or do they typically sit outside main
?
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.
Approving latest update, thanks for swapping the searchbar out.
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.
Great information. I just have some suggestions.
| region | `<section>` | | ||
| search | `<search>` | | ||
|
||
Landmarks can be indicated with `role="landmark"` or by using the landmark's HTML element– both methods mean the same thing in the document. |
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.
If you can get away with it, replace the dash with —
(em dash). If that does not render properly, use —
. Also, remove the space after the em dash character.
### banner | ||
|
||
The banner landmark is an area that has global, rather than page-specific, information or actionable elements. | ||
For example, a website's logo and primary navigation would be expected child elements of a `banner` landmark. There should only be a single `banner` landmark per interface. |
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.
It was my understanding, and it is also stated on w3schools.com, that it is ok to have multiple <header>
elements on one page. For example, each significant section on a page may have a <header>
element.
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 follow MDN's doc and not w3schools (they have a bad reputation). That said, you can have more than one header/banner role on a page but if so, it should have a unique label. So that should be updated here (and for contentinfo)
|
||
The `complementary` landmark indicates an area that contains additional information that "complements" the main content. Though complementary, the content it represents should also be understandable on its own. | ||
|
||
The `Banner`, `StatusBadge`, `Notification` , `Hero`, and `FeaturedContent` components could all be `complementary` landmarks. |
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.
Out of the box, Banner
and Notification
are <aside>
elements, so they are inherently complementary
landmarks. Would consuming apps need to explicitly add the role to the other components that are mentioned?
|
||
### contentinfo | ||
|
||
`contentinfo` is another globally repeating landmark, like `banner`, with information about the parent document. If `banner` is usually the site's header, `contentinfo` is usually the footer. There should only be a single `contentinfo` landmark per interface. |
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 thing here...it is generally accepted that more than one <footer>
element can be added to a page.
<Banner | ||
content={ | ||
<> | ||
<strong>IMPORTANT:</strong> Use the search landmark instead of the form | ||
landmark when the form is used for search functionality. | ||
</> | ||
} | ||
type="warning" | ||
/> |
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!
|
||
There should only be a single `main` landmark per interface. Since `main` represents the primary content of a page, it is the most important destination for [skip links](../?path=/docs/accessibility-guide-skip-navigation--docs), bypassing recurring elements like the header or navigation. | ||
|
||
The `Template` [component](../?path=/docs/components-page-layout-template--docs) renders the `main` landmark (and the `header` and `footer`). |
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 will need to be updated for v4, as the header and footer regions are not part of the updated Template
component.
### navigation | ||
|
||
The `navigation` landmark identifies groups (e.g. lists) of links that are intended to be used for website or page content navigation. | ||
There can be multiple `navigation`s on a page, but if a `navigation` landmark has the same set of links as another `navigation` landmark on the page (think mobile versus desktop), use the same HTML `label` attribute for both. |
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.
Nit: change "multiple navigation
s" to "multiple navigation
elements"
The `navigation` landmark identifies groups (e.g. lists) of links that are intended to be used for website or page content navigation. | ||
There can be multiple `navigation`s on a page, but if a `navigation` landmark has the same set of links as another `navigation` landmark on the page (think mobile versus desktop), use the same HTML `label` attribute for both. | ||
|
||
Elements under [Navigation](../?path=/docs/components-navigation) should be wrapped by the `navigation` landmark. |
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.
Only two components in our Navigation
category do not have a <nav>
element baked in. In fact, one of the two that doe snot have it should be updated to have it added. So that would leave Link
as the only component that needs to potentially be wrapped in a navigation
landmark, and even that would depend on how it was being used.
This is a long winded way of saying this comment should be reworded.
|
||
Elements under [Navigation](../?path=/docs/components-navigation) should be wrapped by the `navigation` landmark. | ||
|
||
### region |
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.
Further, should region
landmarks be nested inside the main
landmark or do they typically sit outside main
?
|
||
The `search` landmark contains the page's search and filter functionality, which will likely include form controls (such as an `input type="search"`). | ||
|
||
Inspect below to see `<search>` in the DOM– notice that it wraps the `Heading`, the `TextInput`, the `Button`, and the `Checkbox`, not just the searchbar: |
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.
Replace the dash with an em dash and remove the trailing space.
If we are going to ask users to look for the DS components, let's tell them to click on the Show code
button in the lower right corner. Conversely, if we are going to ask them to inspect the DOM, then let's ask them to look for the native HTML elements.
Fixes JIRA ticket DSD-1900
This PR does the following:
How has this been tested?
Accessibility concerns or updates
Accessibility Checklist
aria-live
is used, a screenreader was used to verify the text is read.ref
s, focus management was reviewed.Open Questions
Checklist:
Front End Review: