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 analtattribute -
<object>elements must have either atitleoraria-labelattribute -
<area>elements must have either analtoraria-labelattribute -
<input>elements withtype='image'must have either analtoraria-labelattribute
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 toforandhtmlFor)
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)