[Deque Analysis] Reorder buttons in Submission forms are not keyboard accessible (Critical Issue)

[tdonohue]

Critical: This issue results in blocked content for people with disabilities, and will definitely prevent them from accessing fundamental features or content. This type of issue puts your organization at risk. Prioritize fixing as soon as possible, within the week if possible. Remediation should be a top priority.

Deque Analysis Summary

The buttons used to reorder multi-valued fields, or Bitstreams within an item are not fully keyboard accessible. Currently, while you can tab to the button, you cannot "click" it by pressing Enter.

(Issue ID: 469927) Submission Form: Reorder buttons (when field allows multiple values, e.g. Author, Other Title, etc) are inaccessible to keyboard navigation (you cannot tab to them).

The full list of these issues (which includes links for more info) can be found at this link (requires login): https://axeauditor.dequecloud.com/test-run/0856438a-a19a-11eb-bc31-b7d5be387c86/issues?activeTab=dt-issue&page=0&pageSize=100&sortField=ordinal&sortDir=asc&row=9&filter%5Bseverity%5D=4&filter%5Bpage_number%5D=12&filter%5Bpage_number%5D=13&filter%5Bpage_number%5D=14&filter%5Bpage_number%5D=15

Related to

(Issue ID: 470936) Edit Item, Bitstreams tab: Button to reorder bitstreams (in a bundle) is not keyboard accessible.

• Described in [Deque Analysis] Reorder buttons in Edit Item / Bitstreams forms are not keyboard accessible (Critical Issue)  #3154 . It is a similar issue specific to Edit Item / Bitstreams tab:

More Information / Tools

• Consider using Deque's free Chrome plugin to check your work

[atarix83]

@tdonohue

here a possible solution is to add an input field displayed on click of the drag&drop icon. In this field should be possible to specify the position where you want to move the sortable item. The estimation is about 10hours

[tdonohue]

@atarix83 : That sounds reasonable, though I think we need to be careful to ensure the user interface still makes sense when displaying a position input field. I'm slightly worried that displaying such a field could be confusing from a usability perspective. But, I'm open to the idea, we just may want to plan it out better via screenshots or similar.

As another option here, we may want to consider whether there's a way to more easily make these reorder buttons more accessible by using arrow keys to reorder the list. Here's an example of what I'm talking about with regards to using arrow keys to sort a list of items: https://medium.com/salesforce-ux/4-major-patterns-for-accessible-drag-and-drop-1d43f64ebf09#0303 (And another example of the same idea: https://www.barrierbreak.com/can-drag-and-drop-be-made-accessible-yes-it-can-be-in-different-ways/)

That said, it's possible this arrow key resort approach is much more complex to implement right now. In which case, we could look at a way to make your idea work, or we could decide to delay this if it's too large a task at this time.

[tdonohue]

@atarix83 : Assigning back to you to look at my last comment. I think it might be easier here to try to make the reorder buttons accessible via arrow keys on the keyboard, instead of adding a new input field to reorder things. That said, if you have a simple way to achieve the input field, I'm not against it...just worried about what the page would look like & whether it'd be more confusing than the current design (so if you want to go with the input field, we might want to create a mockup of what that'd look like)

[atarix83]

@tdonohue @hostle83

4science is interested in working on this task

we think should be split in two part and we're interested in working on this part

(Issue ID: 469927) Submission Form: Reorder buttons (when field allows multiple values, e.g. Author, Other Title, etc) are inaccessible to keyboard navigation (you cannot tab to them).

Estimation is about 16h and we'll try to follow the approach mentioned by the comment above #1271 (comment)

[tdonohue]

@atarix83 : That seems reasonable to simply claim the Submission form task. I had originally grouped these tasks together because I assumed they might end up using the same drag & drop / reorder component. But, if that's not accurate, then we should split them up.

I'll update the description of this ticket to be ONLY about the Submission form reorder & move the other task to a separate ticket.

[tdonohue]

Updated ticket to be specific to Submission form (i.e. (Issue ID: 469927)).

Moved (Issue ID: 470936) Edit Item, Bitstreams tab: Button to reorder bitstreams (in a bundle) is not keyboard accessible. to #3154

[AndreaBarbasso]

We have a first version of this implementation, following the approach mentioned in comment #1271 (comment).

recording.mp4

As you can see, dragging and dropping element can now be done via keyboard.

Now, there are a few things to take in consideration:

• The accessible drag and drop idea set a tabIndex="-1" to all elements except the first one. I think this is great for lists that do not have inputs inside and that have the whole list element as a drag control, but in our use case it might be a bad practice, since the user might need to tab all the way up to the first element to drag the n-th element that they were editing. Of course, if you think it's best to set the tabIndex="-1" on all elements except the first one, let me know;
• Looking at the demo of the previously mentioned idea, the item that is being sorted is shown differently from the others by applying an italic and bold text. I used the same approach since using a border would require some changes to the template. I think it's a clean approach, but I'm open to criticism and other ideas;
• Finally, the same idea as before uses an invisible span with the aria-live=”assertive” property in order to tell instructions to the user on how to use the keyboard drag and drop functionality. I think that it's a great idea, but I'm not sure in using an aria-live="assertive" element in every component with accessible controls. This would create a lot of redundant code and can cause issues if more assertive texts are rendered on the same page. I think the best way to approach this is to use one aria-live="assertive" span that can be used by every component via a service. What do you think about this?

[tdonohue]

This was discussed briefly in today's Dev meeting and @artlowel mentioned the Atmire team is already working on a related keyboard-accessible reorder library that uses aria-live. They have a PR likely coming later this week and will link it here for reference. We hope that it will avoid duplicate effort.

[artlowel]

We've spun off the live-region service into a separate PR: #3337 That way it doesn't hold up this issue