A11y documentation updates december 23 #819
Conversation
There was a problem hiding this comment.
Good ideas overall.
I would change the wording on the component pages slightly. Now we just basically repeat the sentences from the top-level accessibility page. I don't think a developer gets much out of them this way.
Example: On the TextInput page. "Success/error states are not distinguishable without colour." What? Why? Why should I care?
Maybe we should put something like "Success/error states (input borders) are currently not distinguishable without color. In addition to status, use a descriptive statusText to indicate the input's status"
| @@ -1,5 +1,9 @@ | |||
| The `<Breadcrumb>` component is used to let the user know their current location in a web service. It is rendered as an HTML `nav` element. | |||
|
|
|||
| ### Accessibility Notes | |||
There was a problem hiding this comment.
| ### Accessibility Notes | |
| ### Accessibility notes |
There was a problem hiding this comment.
Because of these headings the "examples" section looks like it belongs to the accessibility notes, which is quite misleading.
| @@ -2,6 +2,10 @@ | |||
|
|
|||
| The component's width should match the preferred length of the user input. | |||
|
|
|||
| ### Accessibility Notes | |||
There was a problem hiding this comment.
| ### Accessibility Notes | |
| ### Accessibility notes |
| @@ -1,5 +1,9 @@ | |||
| The `<Textarea>` component is suitable for longer user inputs. | |||
|
|
|||
| ### Accessibility Notes | |||
There was a problem hiding this comment.
| ### Accessibility Notes | |
| ### Accessibility notes |
|
What do you consider the main benefit of having the accessibility statement related issues on the component pages in addition to the accessibility page? I'm not sure if I would give them such a center stage as in this PR. |
Description
Motivation and Context
Release notes