Add support for aria-label in the Link modal (Block Editor and Classic Editor)

[printsachen1]

To improve accessibility and meet WCAG 2.1 guidelines ​https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA8 , I propose extending the link options in both the Block Editor and the Classic Editor to allow users to add an aria-label attribute to links.

Use case:

Screen reader users often rely on contextual information to understand where a link will take them. In some cases, the visible link text is not descriptive enough, especially when the text is generic (e.g. “Read more” or “Click here”). Adding an aria-label allows content creators to provide more context without changing the visible content.

Proposed solution:

Add a new optional input field to the link modal for entering an aria-label value.

If the field is filled out, the aria-label attribute should be added to the anchor (<a>) tag.

Ensure proper sanitisation and output escaping for the attribute.

References:

WAI ARIA Technique: ARIA8: Using aria-label for link purpose

Related accessibility best practices: ​https://www.w3.org/WAI/tutorials/menus/structure/#describing-links

Accessibility Impact:

This enhancement will help WordPress meet modern accessibility standards (WCAG 2.1 / EN 301 549) and provide a better experience for users relying on assistive technologies.

[audrasjb]

Hello and thank you for the feature request,

I understand why you are proposing this change as I'm myself personaly very involved in accessibility, profesionnally doing accessibility compliance audit as a living, and also a member of the WP Accessibility Team.

For now, the Core team always considered this as "plugin territory" since by default, you don't HAVE to use links like "Read more" or "Click here": you can always write a full relevant anchor for any link.

This position may be reconsidered in the future, but if we decide to introduce this in Core, then I would suggest to introduce support for more ARIA attributes, like aria-hidden which is probably as important as aria-label when it comes to resolves specific compliance issues like this.

To open the discussion to a larger topic, maybe the best course of action for us would be to start working together (I mean: within the Accessibility Team) on an Universal ARIA Support community plugin. If it proves is usefulness for a wider audience, maybe it can eventually be merged into Core.
What do you think of all this @joedolson?

[audrasjb]

To be perfectly clear with my last paragraph, we at Whodunit have developed such a plugin and are about to ship it to the repository, but instead of publishing it on our name, I would be pleased to consider making it a community plugin.

Sharing a screenshot below…

[sabernhardt]

The discussion about a plugin could continue here (or elsewhere), but the idea of a Core implementation already had tickets.

• #48609 proposed adding an aria-label field to the Classic Editor links.
• GB23972 proposed adding it to the block editor interface.
• GB22332 could add an element with the screen-reader-text class instead.

[audrasjb]

I believe the implementation shouldn't only focus on arial-label which is only one side of a general implementation of ARIA across the CMS. That's probably why this improvement is stale as of now. I suggest a different approach via a community plugin, and a more general approach than only focusing on arial-label.

This is what the Performance team does with the Performance Lab plugin, and it proved to be successful to merge features into Core. Happy to discuss it when possible.

To be perfectly clear: I don't think accessibility should be an option in a plugin (even a community plugin) as Matt often suggests. But I believe community plugins are a great way to test things, to demonstrate their feasibility and their robustness, before eventually implementing them into core.

For the record, I managed to ship the theme/plugin auto-update system into core via a Feature Plugin and I think this system is pretty good to test a feature in the wide, before merging it into Core: ​https://wordpress.org/plugins/wp-autoupdates/

[printsachen1]

@audrasjb @sabernhardt

thx you for answer.

To fix the Issue / enhancement go to

​https://github.com/WordPress/gutenberg/packages/block-editor/src/components/url-popover
/image-url-input-ui.js

add new TextControl and a const onSetLinkArial

<TextControl
	__next40pxDefaultSize
	__nextHasNoMarginBottom
	label={ __( 'Link arial-label' ) }
	value={ rel ?? '' }
	onChange={ onSetLinkArial }
/>

const onSetLinkArial = ( value ) => {
		onChangeUrl( { arial-label: value } );
	};

please let me know if you would like me to create a pull request

[audrasjb]

This doesn't look sufficient to me, because it only handles links inserted via the link inserter, and not other link types, for example "Read more" type links generated via the site Editor, menu items, and so on.

But you can of course create a Gutenberg issue + PR, at least to start the discussion about this.