Keyboard functionality (WCAG 2.0, 2.1.1)

I'm reviewing Zotero to see where it needs some attention to meet Web Content Accessibility Guidelines (WCAG) 2.0. I'm looking at Success Criteria 2.1.1 https://www.w3.org/WAI/WCAG21/Understanding/keyboard.html

In particular, I'm looking at 2.1.1's requirement "All functionality of the content is operable through a keyboard interface"

System
- Mac
- Desktop Zotero

Testing procedure

I'm testing for the the general build technique G202 https://www.w3.org/WAI/WCAG21/Techniques/general/G202#tests

For step 1, the functionality I'm assessing is the ability to move an item from one collection into another collection. (For example, a user is reorganizing items). I can performance this function with the mouse by dragging and dropping the item into another collection.

For step 2, I covered my trackpad so I would only use the keyboard. Using the tab and arrow keys, I could get to an item in a collection. However, I was unable to move it to the new folder. I tried using Cut (command X), then paste (command P) in the new folder, but that didn't work. Step #2 fails.

Let me know if there's anything I can to help
  • Yes, the lack of ability to move items between/place them into collections via keyboard is a known accessibility issue (long awaiting attention: https://github.com/zotero/zotero/issues/37 ).

    At this point, I'd guess it won't be fixed until Zotero moves to its new Electron platform but dstillman will be able to say.
  • I wonder what's involved in ensuring the Cut/Paste keyboards commands work? The delete keyboard command works, so maybe success is close?

    As it stands, WCAG 2.0's success criteria 2.1.1 is failing, which mean's it's not conforming to WCAG 2.0. If it won't be fixed, is this documented in a VPAT?

  • That GitHub issue is about a more complicated context-menu option, but we could add support for doing this via the keyboard pretty easily. (And context menus aren't accessible on macOS anyway.)

    There's a cross-platform difference in the standard behavior, though.

    Copying is easy — that's just Cmd-C/Ctrl-C.

    For moving, Windows supports Ctrl-X to move files, and (if I recall) the row becomes grayed out when it's in that state. (I'm not sure we would bother with that part.) macOS doesn't support Cmd-X, and instead you use Cmd-Option-V to move instead of copy, with Edit → "Paste Item" turning into "Move Item Here" when Option is held down. I assume file managers on Linux follow Windows, but I haven't tested.

    Some other complications:

    1) Moving from an item in My Library isn't possible, but cutting/Option should probably still copy.

    2) Copying doesn't make sense on child items, but Cut/Option-V could theoretically be used to move a child item from one item to the other or convert a note between standalone and child. It would be a bit conceptually muddled, though, because it would mean that the items list selection would only be meaningful when a move was a valid operation for both the item and the selection. In other words, if you copied a regular item from one collection and pressed Cmd-Option-V while on a regular item in another collection, the item selection wouldn't be meaningful and the item would just be moved to that collection. But if you copied a child note and pressed Cmd-Option-V while on a regular item, it would move the note under that item. If multiple items were selected and you pressed Cmd-Option-V…I guess it would ignore the selection and move the note to the current collection, the same as if no items were selected? If you wanted to make a child note a standalone note, pasting on a standalone note would probably work, but if you didn't have a standalone note, would it be enough to Shift-Tab to the collection and paste there, causing the unfocused selection in the middle pane to be ignored? If you Option-paste while on a child note, is the copied note turned into a sibling child note? This might all be intuitive in practice, but it's not exactly straightforward.

    3) If you just copy and paste a file in the same folder, macOS (and I assume Windows) duplicates the file. I don't think we would do this, because unlike a filesystem, items can exist in multiple collections, and it would be too easy to duplicate an item in a given collection where it already existed. (It would also exacerbate the problems with (2), since the selection would have even more dramatic effects.) We can just add Duplicate Item to the File menu to make it more accessible.

    4) I guess you should also be able to Cut/Option-V collections to move them.

    5) We should have Undo/Redo anyway, but it would become even more important with these actions, which would be less transparent than dragging (particularly if we did (2)).
  • Hi dstillman, I'll try to adjust my plans for the day so I have time to re-evaluate and respond based on what you've written. Sometimes solutions are just around the corner!
  • I have replicated the problem reported on April 10th on Windows 10.

    1) It's not possible to copy an item to another folder using the keyboard alone

    Windows 10
    When an item in a collection has the system focus, the user does not have the option to use the Cut keyboard command (Ctrl + X)

    Mac
    When an item in a collection has the system focus, the user does not have the option to use the Cut keyboard command (Ctrl + X)

    2 & 3) I'm not sure I follow all the details of the implementations. What WCAG 2.0's guideline 2.1 ("Keyboard Accessible - Make all functionality available from a keyboard") is saying is that when building content, if something can be done by a mouse input device, then a method is needed to do it by keyboard commands too.

    https://www.w3.org/WAI/WCAG21/quickref/?versions=2.0#keyboard-accessible

    4) Yeah, to meet WCAG 2.0, if a user can use a mouse to move a collection in a library, then it should be possible to do the same thing with Cut and Paste keyboard commands

    Is something more I can do to contribute? Let me know.
  • Sorry, my message wasn't actually for you — I was just detailing some of the issues that we'll need to address when implementing this in case other Zotero developers have thoughts. (And for 1, I wasn't saying cutting/Option works now — I was pointing out that cutting (as opposed to copying) from My Library doesn't make sense on a conceptual level.)
Sign In or Register to comment.