Fix/issue 1659 give editable fields better labels

[timwright12]

Description

Fixes #1659

How has this been tested?

In browser tests with the inspector
Ran local unit tests
Ran local e2e tests
Regenerated snapshot

Types of changes

Added aria-labels to fields outlined in the issue so they differ from the placeholder attributes

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[jorgefilipecosta]

This changes tested well and the code changes look correct.
Before:

After:

[timwright12]

@gziolo I fixed the conflict, but I'm getting some troubling build and npm install permission errors since the latest merge in from master, so I'm not able to regen the snapshots for or run the e2e tests right now. I'll work that out, but if someone has it working locally and can run that command before me, that would be great as well.

[timwright12]

@gziolo Looks like all checks are passing now

[afercia]

Thanks for working on this! These changes are an improvement for screen reader users but I'm afraid they won't solve all the accessibility concerns.

A quick example to clarify: quote and paragraph:

The quote visible placeholder is "Add quote". Note this is not a real HTML placeholder attribute so it doesn't get announced by screen readers. It's just text which disappears as soon as the field gets focused.

The quote aria-label is "Quote". This gives the filed its accessible name which is announced by screen readers and clearly identifies what this field is about. Perfect.

However, the visible text mismatches the accessible name.

Speech input users see a visible text "Add quote" and will try to voice a command like "Click add quote" to focus the field. That wouldn't have any effect because the actual accessible name of the field is "Quote" instead.

This is one of the reasons why, as accessibility specialists, we always stress that visible labels are always preferred. In this case, the root cause of the issue is a design that didn't take into account accessibility requirements.

The only way I see as a viable option without design changes is to make the placeholder match the aria-label, e.g.: Quote…. This applies to all the blocks.

The paragraph is a special case.
For the aria-label, I'd suggest to always use Paragraph…. Not sure using Empty paragraph block when the block is empty is really helpful.

The visible text Add text or type forward slash to choose a new block type totally mismatches the accessible name. Also, this text is not announced by screen readers. The only compromise I can think of would be trying the following:

When the paragraph has no content:

• aria-label: Paragraph
• the placeholder text Add text or type forward slash to choose a new block type should be targeted by aria-describedby set on the editable field (unique IDs would be required)
• when the empty field gets focused, the placeholder should not be removed from the DOM: it should just be hidden and still be targeted by aria-describedby

When the paragraph has content:

• aria-label: Paragraph
• remove the aria-describedby and the placeholder

I now it's getting complicated, but it's because of the design constraints.

[gziolo]

I'm seeing that there is some discussion about unifying placeholder and aria-label. If that happens then we might want to revisit the part which removes using placeholder value also as aria-label.

Another thing to consider is using screen-reader-text class name with an HTML element included inside RichText component out of the box when placeholder is provided. A similar solution for the post title:

gutenberg/packages/editor/src/components/post-title/index.js

Lines 120 to 122 in ce8f61d

	<label htmlFor={ `post-title-${ instanceId }` } className="screen-reader-text">
	{ decodedPlaceholder || __( 'Add title' ) }
	</label>

I don't think label would be correct in such context but we could use aria-labelledby somehow as presented on MDN:
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/textbox_role#Description

[afercia]

Note the hidden <label> element on the title was added in #5669 to support speech input software (Dragon). We should take into consideration Dragon doesn't fully supports ARIA.

[gziolo]

@timwright12 - this PR needs to be rebased with the latest changes in the master branch. In general, most of the test files were removed, so hopefully, this shouldn't be a big issue.

Otherwise, this PR should be good to land assuming that proposed changes were reviewed by the Accessibility team.

I now see the comment from @afercia, it still needs some work.

[gziolo]

Is there a corresponding ticket opened in WordPress core to update placeholder text set on PHP side?

[ellatrix]

Is this information not useful as a label? Just wondering

[timwright12]

@timwright12 pinging myself on this one

[jorgefilipecosta]

Hi @timwright12, thank you for the effort in this PR. It seems the PR needs some updates/rebase. Is there any difficulty you are having or anything we could do to help move the PR forward?

[ellatrix]

I'm not quite sure if #12473 (review) is solved. This PR makes changes so that the visible placeholder is different from the label, which isn't what we want?

[youknowriad]

Hi There! I've triaging PRs today and it seems this one is stale. I'm going to close now but please consider reopening if you have some time to dedicate to solving those issues. Thanks for your efforts.