New Accessibility Rules in Codelyzer (v5.0.0)
Making Angular Apps accessible to all (including blind users)!
I am a Software Architect at Tekzenit Inc, and currently working on a React project for one of our clients. I have also helped and worked on half a dozen more clients who have used Angular in their projects in the past year alone. At Tekzenit, we give a lot of importance to accessibility, security and performance of the applications. Currently, we have more than six clients whose projects are being actively developed using Angular alone.
When I was doing code reviews for these Angular projects, I didn’t like the fact that we had to highlight accessibility issues again and again. I thought wouldn’t it be great to have a linter for these accessibility checks. Then we could automate this process and include it with the Angular CLI; benefiting many more Angular projects.
I first thought would it be best to have it in the Angular Language Services itself, and then tweeted about it and walaa I got a reply from the maintainer of codelyzer, also a member of Angular Team, Minko Gechev.
And then I thought, doesn’t codelyzer just work for internal templates? But I was wrong, as Minko corrected me, it does work for external templates and stylesheets (But for now they will only be displayed when you run ng lint and not in the editor). And then Wassim Chegham asked me if I would like to contribute to Codelyzer, to which I replied:
Here is the list of all the accessibility rules that are introduced in Codelyzer v 5.0.0 (coming in Angular CLI v8 near you 🎬):
1) template-accessibility-label-for (PR# 739)
Rationale: Screen reader users should be able to understand the context of the Form element.
<label>First Name</label>
<input [(ngModel)]="firstName">When the screen reader focuses on the input element, it will not have the information about what the input element is for. For the screen reader to know, you can either use the for attribute on a label or have an input element inside the label element.
<label for="firstName">First Name</label>
<input id="firstName" [(ngModel)]="firstName"><!-- OR --><label>
First Name
<input [(ngModel)]="firstName">
</label>
2) template-accessibility-alt-text (PR# 741)
Rationale: Alternate text lets screen readers provide more information to end users.
<img src="company-logo.png">If screen reader users see this image using a screen assistive device, he will have no clue what this image is about, so we need to provide an alternate text for him to understand.
<img src="company-logo.png" alt="Company Name">
<img src="company-logo.png" [attr.alt]="'Company Name'">
<img src="company-logo.png" [attr.alt]="companyName">This rule also works with object, area, input[type="image"]
3) template-click-events-have-key-events (PR# 761)
Rationale: A non-interactive element that has a click event, should be accompanied by one of the key events (keyup, keydown or keypress)
<div class="card" tabindex="0" (click)="selectCard()">...</div>A keyboard user who has a problem in using a mouse, will not be able to select the card, because he cannot initiate the click event, which is specific to the mouse. Interactive elements like button can initiate the click event on keyboard events, but non-interactive elements like the one in the example will not work with keyboard events. To solve this we need to add a key event
<div
class="card"
tabindex="0"
(click)="selectCard()"
(keyup)="selectCard"
>
...
</div>4) template-mouse-events-have-key-events (PR# 759)
Rationale: Mouse events (mouseover and mouseout) are specific to a user that uses a mouse for accessing a website, but other users will not be able to trigger it.
<div (mouseover)="triggerAction()">...</div>A mouseover should be accompanied by a focus event and mouseout should be accompanied with a blur event so that any user can trigger the action
<div
(mouseover)="triggerAction()"
(focus)="triggerAction()"
>...</div>5) template-accessibility-element-content (PR# 762)
Rationale: Some elements are required to have content in it so that the screen assertive device can understand and read it out. Elements include anchor, heading and button elements.
6) template-accessibility-tabindex-no-positive (PR# 744)
Rationale: Positive values for tabindex attribute should be avoided because they mess up with the order of focus (AX_FOCUS_03)
7) template-accessibility-table-scope (PR# 743)
Rationale: The scope attribute makes table navigation much easier for screen reader users, provided that it is used correctly.
If used incorrectly, it can make table navigation much harder and less efficient. (aXe)
8) template-accessibility-valid-aria (PR# 746)
Rationale: Elements should not use invalid aria attributes (AX_ARIA_11)
9) template-no-autofocus (PR# 749)
Rationale: autofocus attribute reduces usability and accessibility for users. (w3c)
10) template-no-distracting-elements (PR# 760)
Rationale: Elements that can be visually distracting can cause accessibility issues with visually impaired users. Distracting elements include marquee and blink.
Conclusion:
Always try to automate the issues that you face every day. Check if something exists in the community that could solve your problem, if not, try to help the community build that, so that not only will your projects benefit from it, but the whole community gets the benefit, and it gets better and better with the help of Open Source.
👋 Hi! I’m Zama Khan Mohammed. I work at Tekzenit as a Software Architect — Web Technolgies. I’m actively involved in working on Projects using Angular, React and Serverless Technologies along with writing a book “Angular Projects”.
EnterpriseNG is coming November 4th & 5th, 2021.
Come hear top community speakers, experts, leaders, and the Angular team present for 2 stacked days on everything you need to make the most of Angular in your enterprise applications.
Topics will be focused on the following four areas:
• Monorepos
• Micro frontends
• Performance & Scalability
• Maintainability & Quality
Learn more here >> https://enterprise.ng-conf.org/
