Repository navigation
Replies: 1 comment
|
Screen reader user here. This is a fantastic idea and definitely something I would personally find helpfull in terms of making websites a bit easier to use. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
I would like to propose a new accessibility rule that warns developers when they use the native
disabledattribute on interactive elements like<button>, encouraging the use ofaria-disabled="true"instead, while allowing for an escape-hatch to ignore the warning in cases where the native disabled attribute is necessary.Rationale
disabledcompletely removes an element from the browser's focus order and hides it from screen readers. This creates a poor experience for keyboard and screen reader users. In many cases,aria-disabledshould be used (along with using JS to ignore button clicks / form submissions), to keep the button perceptible to screen reader users.Valid Use Cases for native
disabledThere are valid cases for the native
disabledattribute, such as disabling an entire collection of form fields (e.g., a<fieldset>for a spouse-specific form section when you have indicated you have no spouse in a previous input).Because of this nuance, I suggest that this be a compiler warning, rather than an error. The idea here is that this rule would introduce "development friction" so devs are prompted to verify if they are mistakenly hiding an interactive element that users should be aware of when disabled. If they genuinely need it, they could use a
<!-- svelte-ignore -->comment to accept the risk.Fail Cases
Pass Cases
All reactions