Improvements for aria-describedby and placeholder usage

[afercia]

I've read a6af3e1 and the related issue #1214

While I understand the intent to provide a simple implementation, seems to me there's room for a couple improvements.

1
The aria-describedby attribute shouldn't be rendered when there's no element with an ID referenced by its value.

When no placeholder and no ariaDescribedBy props are passed, the aria-describedby attribute is still rendered, for example: aria-describedby="placeholder-6s22n" but of course there's no element in the page with an id placeholder-6s22n. When trying to validate a page where this happen with a couple (appreciated) accessibility evaluation tools, this is reported as an error and for good reasons. Tools used:

WebAIM Wave:
https://wave.webaim.org/extension/

Deque aXe:
https://www.deque.com/axe/
Note: axe-core is available also as package for automated UI testing:
https://github.com/dequelabs/axe-core
https://www.axe-core.org/docs/

Based on the spec, the valid value for aria-describedby is an "ID reference list" where it's implied the referenced elements must be present in the page.

https://www.w3.org/TR/wai-aria-1.1/#aria-describedby

Value: ID reference list
https://www.w3.org/TR/wai-aria-1.1/#valuetype_idref_list
A list of one or more ID references.

Also, browsers will expose to assistive technologies the information that a description exists, but actually it doesn't. A simple check could avoid to render an aria-describedby that points to nothing.

2
When using an ariaDescribedBy prop, the placeholder is not announced at all. In this scenario, the placeholder is not referenced by anything and, when landing on the editable field, assistive technologies will just ignore it. Worth noting the placeholder is meant to provide important information: its recommended usage is for a short hint intended to help users with data entry, e.g. a sample value or brief description of the expected format (designers tend to use it as replacement for a label, but that's a different matter).

The point is that precious information may be completely lost for assistive technology users. When emulating native UI, it would be great to try to replicate all the native functionalities: it's our responsibility, as developers, to give users the same experience they have with native UIs.

Natively, when both a placeholder and an aria-describedby attribute are present, they're both announced by screen readers: the placeholder first, the aria-describedby after a brief pause. Regardless of the brief pause 🙂I guess it wouldn't be so hard to reference both the placeholder and the element containing the description, as proposed at some point in #1214. It's just about putting two IDs in the attribute value.

[niveditc]

Seeking input from the folks involved in a6af3e1 - @jessebeach, @flarnie, @skarnati

[jessebeach]

@afercia I vaguely remember making a concession here because of backwards compatibility. In any case, please propose the PR. I'm happy to review!!

[afercia]

Thanks @jessebeach. There's a PR for this issue since April, see #1741 🙂There was an unrelated problem with the build not passing, I've rebased and made prettier happy. Should be good now.

[jessebeach]

@afercia fantastic, it's in my Review Queue!

[preetriti1]

Is this issue fixed yet? The aria-describedby is still set when placeholder element is not present, this violates aria-valid-attr-value.

Is there a plan to get it fixed as soon as possible?

[sedenardi]

Also wondering about this.