Insert link accessibility #694
Comments
|
Looking back at this I see there's now a field to enter the link URL and seems almost ready (no search for now). However, the button to insert a link:
needs to be labeled (an
as there's nothing to announce what these buttons are, they're announced just as "button". To be 100% compliant, the input field itself needs to be labeled (explicitly associated label, nor wrapping, using for/id attributes) and the label can also be visually hidden (screen-reader-text) if a visible one isn't desirable. Once a link is inserted in the content, and the cursor on the link makes the toolbar appear, I couldn't find a way to use the Edit and Unlink buttons with a keyboard, unless I'm missing something. |
|
I'm interested in working on this feature and improving the accessibility of the add a link functionality. |
|
Thank you for the suggestions, @afercia Also, I created a 30s screencast showing how one would arrive to the edit / unlink buttons with the keyboard: |
|
@mehigh thanks! I'd just consider to improve a bit the label text and change: "Submit" to "Apply" or maybe "Insert link" "Unlink" to "Remove link" |
|
Thank you. I've updated my PR to include the wording you suggested. I picked the common "Apply" to allow existing translations to pass through into this button properly. |
## Description Fixes WordPress#694 by improving the screen reader accessibility of the element. My updates apply to the add link and edit link pop-out elements, handling the following aspects: - The buttons (Apply, Edit, Remove) now have the aria-label attribute added in for accessibility purposes. There is no visual change for them. - The URL input now has an ID that makes use of the withInstanceId feature from components - The URL input now has a screen-reader-text label which uses the ID on the for attribute to improve the screen reader accessibility of the element. This label is not visible. ## How Has This Been Tested? I used the browser's inspector (screenshots reflect that) to confirm the presence of the a11y attributes and screen-reader-text elements on both the add link and edit link forms. The updates done in blocks/editable/format-toolbar.js were visible in the add link / edit existing link workflow in the text block, just like the screenshots show. I wasn't able to figure out where is the "blocks/library/button/index.js" actually used. It has in the edit function a form with a class of editable-format-toolbar__link-modal, just like the one generated with the insert/edit URL. Locally only I tried adding an extra class on the form.editable-format-toolbar__link-modal and trying to hunt it in the browser, but I wasn't able to stumble upon it myself. That's why the changes done on that file are minimal (added the button aria-label and added a <label for> and added an ID to the URL input element itself, without making use of withInstanceId - because there is no export default I could add the withInstanceId call around). ## Screenshots: Add link form:  Edit link form:  ## Types of changes New feature (non-breaking change which adds functionality). ## Checklist: - [x] My code is tested. - [x] My code follows the WordPress code style.
* Insert link accessibility ## Description Fixes #694 by improving the screen reader accessibility of the element. My updates apply to the add link and edit link pop-out elements, handling the following aspects: - The buttons (Apply, Edit, Remove) now have the aria-label attribute added in for accessibility purposes. There is no visual change for them. - The URL input now has an ID that makes use of the withInstanceId feature from components - The URL input now has a screen-reader-text label which uses the ID on the for attribute to improve the screen reader accessibility of the element. This label is not visible. ## How Has This Been Tested? I used the browser's inspector (screenshots reflect that) to confirm the presence of the a11y attributes and screen-reader-text elements on both the add link and edit link forms. The updates done in blocks/editable/format-toolbar.js were visible in the add link / edit existing link workflow in the text block, just like the screenshots show. I wasn't able to figure out where is the "blocks/library/button/index.js" actually used. It has in the edit function a form with a class of editable-format-toolbar__link-modal, just like the one generated with the insert/edit URL. Locally only I tried adding an extra class on the form.editable-format-toolbar__link-modal and trying to hunt it in the browser, but I wasn't able to stumble upon it myself. That's why the changes done on that file are minimal (added the button aria-label and added a <label for> and added an ID to the URL input element itself, without making use of withInstanceId - because there is no export default I could add the withInstanceId call around). ## Screenshots: Add link form:  Edit link form:  ## Types of changes New feature (non-breaking change which adds functionality). ## Checklist: - [x] My code is tested. - [x] My code follows the WordPress code style. * 694 - Fix formatting * 694 - Removed visually hidden labels, added aria-label attribute on the input * 694 - Reverted the edit function declaration * 694 - Dropped accessibility text comment
See also #679
All form elements need a properly associated label. As per the WordPress accessibility standards, it must be an explicitly associated label (with for/id attributes, not wrapping the field).
The label can be visually hidden. Also, please consider the placeholder attribute is not a replacement for a label, see https://core.trac.wordpress.org/ticket/40331
Regarding the buttons, at the moment they don't have any text or label that can be announced by assistive technologies, they contain just SVG icons, see #528
These buttons need to be labeled, an
aria-labelattribute or a visually hidden text within the buttons would be appropriate.when inserting a link:
when editing a link:
not sure what to do when editing a link, currently there's no form, just a not-editable link element with an empty
hrefattribute. Waiting for development to complete for further review.The text was updated successfully, but these errors were encountered: