Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Review the usage of aria-label on the blocks contenteditable #5981

Closed
afercia opened this issue Apr 4, 2018 · 6 comments

Comments

@afercia
Copy link
Contributor

commented Apr 4, 2018

Currently, the various blocks contenteditable use an aria-label attribute, some examples (with other attributes relevant for aassistive technologies):

paragraph:

<p aria-label="Add text or type / to add content" role="textbox" contenteditable="true" ...

list:

<ul aria-label="Write list…" aria-multiline="true" contenteditable="true" ...

quote:

<div aria-label="Write quote…" aria-multiline="true" role="textbox" contenteditable="true" ...
<p> ...

Though the intent is to give users some instructions or hint about what to type, this is a not proper use of aria-label, as it is supposed to override the element content. I doubt there's any expected behavior about what aria-label should do when used on a contenteditable element. contenteditable is buggy and still greatly inconsistent across browsers and assistive technologies. For example, some screen readers read out the aria-label and the contenteditable content, some don't.

Regardless, we shouldn't use aria-label this way. We should find a different way to provide users this "hint".

@afercia

This comment has been minimized.

Copy link
Contributor Author

commented Apr 5, 2018

For clarity: when using role=textbox then the element is actually exposed like an editable field (or textarea if it uses aria-multiline)

<p aria-label="Add text or type / to add content" role="textbox"

so the aria-label makes perfectly sense. Its value should be improved though.

Instead, when role-textbox is not used, the aria-label is supposed to override the element content:

<ul aria-label="Write list…" aria-multiline="true" contenteditable="true"

this is not exposed like a text field or textarea. See also #5983

@aardrian

This comment has been minimized.

Copy link

commented Jun 14, 2018

aria-describedby and point to the id of an appropriate element? Perhaps a visually-hidden button that allows keyboard access to the field (as we discussed at WCEU)?

@mtias mtias added the Needs Testing label Jul 18, 2018
@afercia

This comment has been minimized.

Copy link
Contributor Author

commented Sep 10, 2018

Removing the Needs Testing label as there's not so much to test. The visible placeholder text is used also as value for the aria-label attribute, also when the contenteditable area has content. This is far from ideal and needs to be changed for assistive technologies users. Will expand later with some proposals.

@mtias mtias removed this from the Merge: Accessibility milestone Oct 3, 2018
@mtias

This comment has been minimized.

Copy link
Contributor

commented Oct 3, 2018

Moving this out of milestone as it's not clear what remains actionable here. If we need an issue for "aria-label should be different when contenteditable element has content" let's open one and treat it like a bug.

@afercia

This comment has been minimized.

Copy link
Contributor Author

commented Oct 3, 2018

Yes there's the need for "aria-label should always be different from the placeholder". It's important enough to stay in the milestone. Please let the a11y team know if there's the need to open a new issue or just re-open this one.

@tofumatt

This comment has been minimized.

Copy link
Member

commented Oct 5, 2018

This seems to be a duplicate of #1659, specifically #1659 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.