Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Improvements for aria-describedby and placeholder usage

See original GitHub issue

I’ve read https://github.com/facebook/draft-js/commit/a6af3e15120e74c8797c5670f5bb63cb45c49a32 and the related issue https://github.com/facebook/draft-js/issues/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.