LinkField accessibility

maxime-rainville commented 4 months ago

As a content author I want LinkField to adhere to accessibility best practices so that I can use the field regardless of any impairment.

Acceptance criteria

Accessibility practices for dndkit are adhere to.
Focus is consistent between keyboard and mouse usages.
When a user is done editing a Link in the LinkModal focus is returned to
- to the LinkField that was being edited (Single LinkField)
- to the Link being edited (Multi LinkField)
When archiving a link, the focus is returned to a suitable element (ask UX team for feedback on this one)
Link list should be an actual list.
Code is re-factored to avoid bad React practices like using Intervals or directly setting attribute on DOM elements. - update see comment below
Fix is targeted to next minor (October)

Potential problems

The focus before and after the Modal closes depends on whether you are using the Keyboard or the Mouse.
When using the keyboard to save the Modal, the cursor appears to be on the correct spot, but the button doesn't actually have tho focus. So if I hit the Enter key, nothing happens.
Our sorting library has accessibility recommendation. It's not clear that they've been applied across the board.
- e.g. There's no screen reader announcements.
There's unusual logic in there around setting interval, manually detecting key presses, directly setting attribute on DOM elements.
Some of the Aria attribute seem poorly defined.
- The Div containing the LinkField button has a role of button. The button inside there also has a the role of button.
- Disabled LinkFIeld have aria-disabled="false" applied to them.
- aria-describedby is empty. It should point to the label.
- In MultiLinkField, the list of link should be define as an actual list ... either with UL or with the equivalent aria-role.
The link list is not an actual list.

New issues created

PRs

maxime-rainville commented 4 months ago

UX Questions

When you click on a LinkField, a Link Modal shows up that allows to enter the details for that specific Link.

In the current implementation, if you use the keyboard to trigger the edition of the Link, when you are done editing the Link, the focus goes back to the LinkField.

If you use the mouse to trigger the edition of the Link, when you are done editing the Link, we don't do anything with the focus. The focus goes back to the top of the page.

My assumption

It shouldn't matter whether you use the mouse or the keyboard. The focus should behave the same.
Once you are done editing a Link, the focus should go back to the LinkField.
- Whether you decided to save the Link or decided to dismiss the modal doesn't make a difference on where the focus should go.

maxime-rainville commented 4 months ago

I've run my assumptions by Cassie and she agrees.

emteknetnz commented 4 months ago

Probably need to account for clicking the archive link, presumably it would go back to the picker. However this might be weird for MultiLinkField if you archive a link that's far away from the picker e.g. 4 links down, cos then focus would jump up quite a bit.

Other option, which seems like it may be better, is to put focus on the the link or link picker that is "one above" the archived link

maxime-rainville commented 4 months ago

@emteknetnz That's a good question. Doing a quick search for "Web accessibility where should focus go after an element is deleted" returns two broad views:

Replace the deleted element with a "Deleted" row, optionally fading the row out after a few seconds.
- https://ux.stackexchange.com/a/99411
- https://ux.stackexchange.com/a/132948
Focus on the next element in the list (or the previous one if you were at the end of the list)
- https://ux.stackexchange.com/a/99358
Option 1 seems like the "better" one accessibility wise. Option 2 would probably be easier to implement while still making generally good.

maxime-rainville commented 4 months ago

On another topic, I notice that the sort handle gets the focus before its actual link.

My gut feeling is that the Link should get the focus first and then the sort handle ... but I've got no data to back that feeling.

Side note: Elemental doesn't provide a way to sort blocks with the keyboard right now. Maybe after we do this, we should have a look there next.

emteknetnz commented 3 months ago

Regarding DOM manipulations:

I did refactor out one of them here https://github.com/silverstripe/silverstripe-linkfield/pull/264/files#diff-137b4934bf6fa4a21e7201f82126c992a55a2646a00786e8ebc5d256a50d02ebL91

I did not refactor out the DOM manipulation in LinkField.js for handleUnpublishedVersionedState(), which updates the state of the Page/GridField publish button, which had this comment above it

   * This is fairly hackish code that directly manipulates the DOM, however there's no
   * clean way to do this since the publish button is not a react component, and the existing
   * jQuery change tracker does not allow independently updating only the publish button

I don't think it's viable to refactor this out, as it would require a major change to the existing change tracker. As it is the changetracker essentially adds a binary 'dirty' state to fields when they're changed from the value they were initialized with. If the form contains any dirty fields then any elements matching 'button[data-text-alternate]' which will normally be the page save & publish buttons, will get set to an 'alternate' state which indicates the user needs to click them to save/publish changes

With this current setup there's no way to specify "only indicate the user needs to click the publish button and not the save button" - we'd need that because linkfield saves links via XHR when the link modal is submitted, though publishes via owner publish

GuySartorelli commented 3 months ago

PRs merged

silverstripe / silverstripe-linkfield