You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We often have to deal with disabled controls in Primer which are typically inaccessible to most users. If we could create a rule that would help stem that usage, then it might reduce the amount of inaccessible patterns that are commonly used with the disabled attribute.
Idea
We cannot restrict usage of the disabled attribute outright, as it may be a good option in some cases. Since there are many different nuances for how and when this attribute is used, we should restrict this rule to only be applied in specific cases.
In forms
We provide guidance against disabling save/submit buttons in forms and instead provide a reason as to why the submission isn't successful. We could potentially create a rule that throws a violation against disabled submit buttons used within a <form>, or similar form-based components.
Example of bad usage:
<form><label>Name
<inputtype="text" name="name" required />
</label><label>
Bio
<textareaname="bio" rows="5" />
</label><!-- The control is disabled, but provides no explanation as to why --><buttontype="submit" disabled>Save</button></form>
We could warn in instances where disabled is used for the submit control, much like in the example above.
As suggestions
ESLint allows you to provide suggestions to patterns without throwing an error. We could utilize this to steer developers away from disabled, by encouraging them to look into using a more accessible pattern that will fits their needs.
The text was updated successfully, but these errors were encountered:
@TylerJDev 👋🏻 I added this to the a11y eng Inbox for us to triage and prioritize, but if you were thinking this would be better addressed through avenue let me know!
Summary
We often have to deal with disabled controls in Primer which are typically inaccessible to most users. If we could create a rule that would help stem that usage, then it might reduce the amount of inaccessible patterns that are commonly used with the
disabled
attribute.Idea
We cannot restrict usage of the
disabled
attribute outright, as it may be a good option in some cases. Since there are many different nuances for how and when this attribute is used, we should restrict this rule to only be applied in specific cases.In forms
We provide guidance against disabling save/submit buttons in forms and instead provide a reason as to why the submission isn't successful. We could potentially create a rule that throws a violation against disabled submit buttons used within a
<form>
, or similar form-based components.Example of bad usage:
We could warn in instances where
disabled
is used for the submit control, much like in the example above.As suggestions
ESLint allows you to provide suggestions to patterns without throwing an error. We could utilize this to steer developers away from
disabled
, by encouraging them to look into using a more accessible pattern that will fits their needs.The text was updated successfully, but these errors were encountered: