Making a web application accessible can feel like a daunting task, particularly if you aren't used to taking accessibility into consideration.
The @angular-eslint
repo includes a number of linting rules that can help enforce accessibility best practices within Angular component templates.
It is important to note, however, that these rules do not check attributes and roles set using the host section of the @Component
decorator, or ones set using @HostBinding
decorators.
While passing these rules isn't a guarantee or metric for ensuring full accessibility, it is a step in the right direction.
For convenience, I've divided the rules I will be covering into three groups. The first group, general, covers ARIA roles and attributes. The second group, content, includes rules related to textual representations of content. The last group, interactivity, includes rules pertaining to user interaction and event handling.
General Rules
@angular-eslint/template/accessibility-valid-aria
This rule makes sure that all aria-*
attributes used are valid. The rule will fail if a non-existent aria-*
attribute is used, or a valid aria-*
attribute is given an unexpected value.
Content Rules
@angular-eslint/template/accesssibility-alt-text
Checks visual elements <img>
, <object>
, <area>
and <input>
(of type 'image'
) to make sure they have descriptive text.
-
<img>
elements must have analt
attribute -
<object>
elements must have either atitle
oraria-label
attribute -
<area>
elements must have either analt
oraria-label
attribute -
<input>
elements withtype='image'
must have either analt
oraria-label
attribute
Related Guidelines:
@angular-eslint/template/accessibility-elements-content
Checks heading, anchor and button elements to make sure they contain accessible content. This can be in the form of text, binding to [innerText]
, [innerHtml]
or [outerHTML]
, or use of aria-label
or title
attributes.
Related guidelines:
@angular-eslint/template/accessibility-label-for
Check that label elements and label components are associated with form elements.
Default behavior expects label
elements to either be associated with an input element via the for
attribute, or to contain a <button>
, <input>
, <meter>
, <output>
, <progress>
, <select>
, or <textarea>
element.
Configuration Options:
{
"controlComponents": [],
"labelComponents": [],
"labelAttributes": []
}
-
controlComponents
- Specify components to treat as input elements (in addition to ones mentioned above) -
labelComponents
- Specify components to treat as label elements (in addition tolabel
) -
labelAttributes
- Specify attributes that can satisfy label being associated with an input element (in addition tofor
andhtmlFor
)
Related guidelines:
Interactivity Rules
@angular-eslint/template/no-positive-tabindex
This rule checks to make sure tabindex
is only ever being set to 0
(element is tab focusable) or -1
(element is not tab focusable), and not a positive value that interferes with the automatic tab order of elements.
Related Guidelines:
@angular-eslint/template/click-events-have-key-events
Requires elements with click event handlers also handle at least one key event (keyup
, keydown
or keypress
)
Related Guidelines:
@angular-eslint/template/mouse-events-have-key-events
Requires any element with a mouseout
event handler to also handle blur
events, and any element with a mouseover
event handler to also handle focus
events.
Related Guidelines:
Passing these rules is an easy way to start the journey of making your Angular applications accessible, and hopefully encourage you to consider accessibility as you develop.
Additional Reading:
Top comments (0)