Feature: Add aria-label, aria-labelledby, and aria-describedby support

[svinkle]

Based on the article, Short note on aria-label, aria-labelledby, and aria-describedby by @LJWatson, the aria-label, aria-labelledby, and aria-describedby HTML attributes have specific support and use cases. It would be great if these were included in the lint tests.

Specifically, these attributes are supported and applicable on the following HTML elements:

• a[href]
• audio[controls]
• button
• iframe
• img
• input:not([type="hidden"])
• select
• textarea
• video[controls]

Also included are landmark elements such as:

• header
• footer
• main
• nav
• aside
• section
• form

The attributes are also supported on widget elements with an explicit role.

If any other element includes these attributes, it should lead to a warning message such as:

The aria-label attribute must only be included on interactive elements, elements with an implicit or explicit role, iframe elements, or image elements.

[geoffmcl]

@svinkle thank you for the issue and blog link, but unsure what you want tidy to do?

While all, or most of, the aria-xxxx attributes are now supported, there is certainly presently no checks in tidy that the 3 attributes you mentioned are only used on the elements you mentioned...

For example, tidy, like the current W3C nu validator, will not flag a warning for say <div aria-labelledby="l1">, if that is what you suggest...

While tidy does do some level of attribute checking, but only for certain elements and some attributes... very far from all...

And I am not sure tidy will ever get into such strict, full attribute checking, but look forward to further feedback and ideas... thanks...

[svinkle]

Hi @geoffmcl, thanks for getting back to me.

I understand your reserve of implementing this request; it could prove to be quite an effort and the fact that the inclusion of these attributes result with valid HTML is a reasonable concern.

The purpose of this request, and possibly many more, would serve the purpose of aiding developers in understanding when, or when not, to add accessibility related attributes. In some contexts, using aria-* and/or role attributes can cause more harm than good, while remaining as valid HTML.

For example, applying role="button" to a <div> element is valid and screen readers will announce the <div> as a "button." For some, this likely seems a reasonable solution. Unfortunately, the reality is this introduces a host of underlying issues when using role in this manner; semantic meaning, lacking proper keyboard support, and screen reader announcement issues to name a few. In this case, I'd recommend issuing a warning and to encourage using an actual <button> element instead.

For this issue in particular, the warning would appear if any of the above attributes were applied on any elements not listed above, in addition to checking against if the element featured an appropriate widget role. I understand that this is a large task and might not make it in, but I felt like it was worth reporting and getting a dialog going to help spread awareness.

My personal and professional experience with accessibility assessment/testing has shown that developers think they're making sites more accessible by tacking on some of these attributes onto various elements. This often leads to discussions on why these attributes are not ideal and should be removed. I believe if linters made suggestions on proper aria-* and role attribute usage, this would save time and help educate people in the process.

Normally I'd happily contribute and create a PR to help out, but since this project is C based, which I have zero experience with, I'll leave it up to the experts of this language.

Let me know what you think.

[balthisar]

@svinkle, is there a language that you _are experienced with? I could refactor it into C, as coding is the easy part and the engineering is the time consuming part.

There's some precedent in Tidy for emitting messages for valid HTML, namely, the accessibility module. It's a post-processing process to look at the document structure for guideline published by the Web Accessibility Initiative.

Following the design of the current access.c/.h would make such an initiative fairly self-contained without requiring as much fiddling with Tidy's current internals, and without accumulating too many extra duties to Tidy proper.

I could tackle this in the long term, but would be willing to port if there were an existing design or even just a specification.

[geoffmcl]

Although no further comments in a while, maybe this is still open, so moving out the milestone...

[brennanyoung]

I understand that some devs get trigger-happy with tabindex and role, leading to an even worse accessibility implementation, and I think some warnings (such as not using tabindex values greater than 0) would make a lot of sense, but I'm not sure warnings about using role=button instead of plain button will be desirable in every case, as this is a very common and (in the case of retrofitting an existing site, recommended) practice. If it were switchable, it would be ok.

However, some caveats about really screwy accessibility issues could be welcome.

As for other 'code policing', I notice that tidy does not complain or 'clean up' if you use "false" as a value for a boolean attribute, which is both counterintuitively wrong, and easy to catch. Example:

<div hidden="false">this won't be hidden because the attribute is always true if present</div>

Maybe we could compile a list of accessibility 'sins' and 'smells' which we find worth reporting? Shall I begin?

• One very obvious one is: tabindex values greater than 0 - A11y folks know that such values are 'valid' but almost always bad. This should flag a warning, or be 'tidied', I think.
• Tabindex of 0 on something which is not interactive (e.g anything but a link, button or input), or does not have an interactive role. Again, this is 'valid' HTML, but almost always bad.
• Missing landmark roles. At least one top-level heading is expected by assistive tech. Something with role=main is also 'expected'.
• Pleonasms such as <button role=button> should be tidied or warned about.
• Roles which actively contradict or fuzz the default element semantics (e.g. <footer role=heading> or <h1 aria-level=4>) are a code smell, and deserve a warning, but it will be hard to identify a full set of these,
• Some roles are 'forbidden' or 'known to break' in the context of some other roles. (e.g. putting role=menu inside something which has role=button is probably not going to work with a screenreader).
• Some attributes which are required with certain roles. For example role=progressbar requires aria-valuemin, aria-valuemax to be present.

These are just off the top of my head. I guess we need to plough through the w3c roles document...