Improvements for aria-describedby and placeholder usage
See original GitHub issueI’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.
Issue Analytics
- State:
- Created 5 years ago
- Comments:6 (4 by maintainers)
Top GitHub Comments
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?
@afercia fantastic, it’s in my Review Queue!