Grammar, content, and type changes #1
Conversation
|
|
||
| ```html | ||
| <svg> | ||
| <title>description of svg</title> | ||
| </svg> | ||
| ``` | ||
|
|
||
| 1. Hide the svg via `aria-hidden="true"` and add a visually hidden element that describes it. | ||
| 2. Hide the svg via `aria-hidden="true"` and add a visually hidden element that describes it. |
There was a problem hiding this comment.
In markdown you can prefix each item in list with 1. and markdown will take care of enumerating it. This makes it easier to reorder lines without having to manually change the numbers in each line
There was a problem hiding this comment.
@aoxrud-ww I'd normally agree with that method but bc of the html blocks separating them they were both rendered as 1.
| Assistive technologies wouldn't announce the disabled styling so the disabled state should be indicated using the [aria-disabled](https://www.digitala11y.com/aria-disabled-state/) attribute. | ||
|
|
||
| For example: a button needs to be shown as disabled and it should still be clickable. | ||
| Maybe clicking on the disabled button triggers a validation announcement. | ||
| There are exceptions where the inputs are styled as visually disabled and they don't have the `disabled` attribute declared. For example: a checkbox needs to be visually disabled but it should still be focusable. We'd want this so its content is still accessible to the screen reader. |
There was a problem hiding this comment.
Not sure this checkbox example is an actual use-case. We wouldn't denote a checkbox as disabled but still have it checkable. It would be conflicting information to the user.
We did use the pattern where buttons are disabled but still clickable and when you do that it triggers the form validation
There was a problem hiding this comment.
@aoxrud-ww I was confused here. I thought aria-disabled hid elements from the screen reader but that's not the case. That being said I think this section could benefit from a brief discussion of disabled vs aria-disabled
| There are exceptions where the inputs are styled as visually disabled and they don't have the `disabled` attribute declared. For example: a checkbox needs to be visually disabled but it should still be focusable. We'd want this so its content is still accessible to the screen reader. | |
| For example: a button needs to be shown as disabled and it should still be clickable. | |
| Maybe clicking on the disabled button triggers a validation announcement. | |
| It's important to note that the `disabled` attribute will hide the element from the screen reader. This should be avoided because although the element is disabled it still provides valuable information to the user. For example if a next button has a `disabled` (instead of an `aria-disabled`) attribute by default until some condition is met that button will be hidden from the screen reader. Knowing that there **is** a next button and it's disabled is valuable information which can be conveyed through `aria-disabled`. |
No description provided.