Validate a11y attributes

[dgp1130]

Which @angular/* package(s) are relevant/releated to the feature request?

compiler-cli

Description

We should have the Angular compiler validate the types for a11y features of the DOM, such as role or aria-* attributes to make sure they are always set to valid values. This could allow the compiler to error or warn on bad a11y values and help users identify mistakes in their code which can lead to a more accessible experience.

Proposed solution

This could potentially be done as an extended diagnostic, or possibly through a *.d.ts typecheck or other direct compiler integration. I'm not sure which would be more appropriate here.

Alternatives considered

N/A

[angular-robot]

This feature request is now candidate for our backlog! In the next phase, the community has 60 days to upvote. If the request receives more than 20 upvotes, we'll move it to our consideration list.

You can find more details about the feature request process in our documentation.

[flash-me]

Is it checking on a syntactical level or are you going to check also semantics?

e.g. the attribute aria-checked is not valid on div, p, span elements etc.

However, if a custom checkbox (or option etc.) is implemented and is semantically defined as such by providing the role,
the aria-checked attribute becomes totally valid:

<!-- custom checkbox implementation -->
<div role="checkbox" aria-checked="true"></div>

I mean...the possible amount of combinations (and even more coming with WAI-ARIA 1.2) is huge.

Nonetheless, looking forward for this feature, even if it's only checking on the syntactical level!

cheers
flash ⚡

[dgp1130]

I think checking semantics should be on the table, an extended diagnostic should be able to identify that you put aria-checked on the wrong tag.

As you said, there's a lot of complexity there, so we may start small and expand the check over time. We'll have to see what is practical to implement.

[twerske]

Love this idea! A great small start would be adding a check for alt on <img> elements.

[twerske]

Additional checks to consider

• check for a title attribute in the Route definitions
• Heading levels should have a meaningful hierarchy, e.g.: (check nesting order of h1, h2 etc)
• Form labels and labelFor could likely be statically checked or at least add warnings for
• Buttons can check for a label
• All ARIA strings can be checked to confirm if they are empty strings "" which would be invalid/not best practice

Another source we can check for additional checks is what the axe tool's static HTML checks are: https://github.com/dequelabs/axe-core

[angular-robot]

Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.

Find more details about Angular's feature request process in our documentation.

[markgoho]

imo accessibility is too big a domain for Angular to provide any level of real guidance and this should best be left to other tools that already provide the same level of feedback

the worst thing about this idea is the false sense it gives devs thinking no red squiggles means compliance

@twerske are you aware that not all images require alt tags? how will angular know when to flag?

[moniuch]

imo accessibility is too big a domain for Angular to provide any level of real guidance and this should best be left to other tools that already provide the same level of feedback

the worst thing about this idea is the false sense it gives devs thinking no red squiggles means compliance

Totally agree on that. On top of what @markgoho said:

Given that WCAG are only guidelines and not a standard/specs, it means that every team should be able to decide on how and if they want to implement them. For this there are appropriate opt-in tools, such as angular/eslint where individual rules can be enabled.

Also, as the guidelines will most likely evolve, this will create additional burden on the Angular project to keep pace. In case this fails, this will cause frustration, users will eventually resort to other tools focused specifically on a11y, and the contributors' effort on this issue might eventually be wasted.