Keyboard trap (WCAG 2.0, 2.1.2)

I'm reviewing Zotero to see if it is built to meet Web Content Accessibility Guidelines (WCAG) 2.0.

I'm looking at Success Criteria 2.1.2

For various reasons, many researchers rely on the keyboard rather than a mouse to move the system focus through an interface (e.g., carpal tunnel syndrome)

I'm applying the WCAG test procedure to detect the successful build of reliable technique #G21

- Mac
- Desktop Zotero

Testing procedure
1. Press Tab to move the system focus through every focusable element on the interface
2. When you get to the last focusable element, press SHIFT + TAB or other keyboard keys to go back to the first element

Step #2 fails at "Extra" and "Title" fields in the item editor. Additionally, the complete toolbar cannot be accessed by Tab/Shift+Tab

Is there anything I can do to help the Zotero dev team meet Success Criteria 2.1.2?
  • Yeah, that's a bug. It actually works in Extra if you just Tab into the field once and then Shift-Tab, but it looks like it gets stuck if you press Tab again once you're already in Extra, and in Title it's doing it all the time. It's not really a trap, in that you can press Esc to cancel or Shift-Enter to save and return focus to the items list, but Shift-Tab should still work when it's not being used for something else (e.g., unindenting in Extra). We'll try to fix this. Issue created.
    Additionally, the complete toolbar cannot be accessed by Tab/Shift+Tab
    Yes, we need to fix this. Issue created. (Some of these operations are available via the menu, but not all of them.)

    Thanks for investigating this.
  • I've fixed Shift-Tab for Title and Extra in the latest Zotero beta.
  • That's great. Thank you dstillman. I think it will make a big difference.
  • mweiler1 I'm interested in the results of your Zotero accessibility review, and if there are still WCAG 2.0 criteria that are not met (after your fix described above)?
Sign In or Register to comment.