I think this task needs better title and description :) I.e. what auditory we are targeting (screen readers, high-contrast, large type, etc.?), how we want to measure it, what specifically needs to be improved?

This is the epic.
I will create concrete stories that will focus on smaller parts to improve, but nevertheless thanks for your input.

Yes, controls should be standardised and should be keyboard-accessible. I should at least be able to write queries in the edit box and use the combo box filters using standard keystrokes for those things.

Was already imported as: https://codein.withgoogle.com/dashboard/tasks/4880480144982016/

With the title: "Keyboard accessibility for Query.Wikidata.org" and the request to add keyboard-accessibility to the index.html file. However, @Jonas do you want to mention, which keys should trigger what function? :)

Mh now the epic is becoming the task.
I would have rather created a subtask....

In T173213#3772104, @Florian wrote:

Was already imported as: https://codein.withgoogle.com/dashboard/tasks/4880480144982016/

With the title: "Keyboard accessibility for Query.Wikidata.org" and the request to add keyboard-accessibility to the index.html file. However, @Jonas do you want to mention, which keys should trigger what function? :)

So, which keys should trigger what function? :P

Just tested. We are currently able to use alt+tab to

• Open, select and run an example.
• Edit query and navigate through result.
• Change language.

(though not very efficiently of course)

Perhaps

to be a better layout for accessibility? So that the user lands on textarea, then uses tab to go through the Query Helper, and finally goes to Run button.

So, which keys should trigger what function?

I think making this list is a part of the task :) But making reasonable assumptions in line with accepted best practices (e.g. Enter means "do it", Esc means "don't do it", Ctrl-KEY/Alt-KEY to call menu functions, F1 is help, etc.) would be good. Also, once it's implemented, changing the particular key if it doesn't work shouldn't be too hard.

Change 400461 had a related patch set uploaded (by Eflyjason; owner: Eflyjason):
[wikidata/query/gui@master] Implement basic keyboard accessibility for Query.Wikidata.org

https://gerrit.wikimedia.org/r/400461

OUT-DATED:

Ctrl/Command+Enter: Run query
Esc: Leave current input field/textarea
Alt+F: Click "Fliter" button in Query Helper
Alt+S: Click "Show" button in Query Helper
Alt+L: Click "Limit" button in Query Helper
Alt+D: Clear query
Alt+R: Restore previous query
?: Toggle Help menu
E: Show examples
F: Focus on "Fliter" button in Query Helper
S: Focus on "Show" button in Query Helper
~: Focus on query textarea
L: Show language menu

Known problems:

• [Partially fixed] Pressing E multiple times would create multiple example window
• After opening the language selector, Esc has to be pressed twice to first close the language selector view, and then leave the input focus inside the language selector
• The example list cannot be traveled easily using Up arrow and Down arrow. It can only be traveled by tab.

Thanks for providing the list!
Here is my feedback (ubuntu + chrome):

In T173213#3862121, @eflyjason wrote:

Esc: Leave current input field/textarea

Works good!

Alt+F: Click "Fliter" button in Query Helper

Browser shortcut

Alt+S: Click "Show" button in Query Helper

works

Alt+L: Click "Limit" button in Query Helper

works

Alt+D: Clear query

Browser shortcut

Alt+R: Restore previous query

I would skip that, because ctr+z and ctr+y works

?: Toggle Help menu

Does not work

E: Show examples

Works

F: Focus on "Fliter" button in Query Helper

Works

S: Focus on "Show" button in Query Helper

Works

~: Focus on query textarea

Does not work

L: Show language menu

Works

Maybe we could skip the alt + [...] keys for now as focus (F,S) seems to already do the job.

Updated. Should be all working now :)

Ctrl/Command+Enter: Run query
Esc: Leave current input field/textarea
?: Toggle Help menu
I: Focus on query textarea
R: Jump to query result
F: Focus on "Fliter" button in Query Helper
S: Focus on "Show" button in Query Helper
M: Click "Limit" button in Query Helper
E: Show examples
L: Show language menu
Arrow Up/Arrow Down: Select item in query result

Added R to jump to query result and Arrow Up/Arrow Down to select item in query result

Change 400461 merged by jenkins-bot:
[wikidata/query/gui@master] Implement basic keyboard accessibility for Query.Wikidata.org

https://gerrit.wikimedia.org/r/400461

Alt+S: Click "Show" button in Query Helper

works

No, also a browser shortcut, at least in Firefox. We need to test more than one browser :)

In general, Alt+whatever is reserved for the menubar, so I’m glad it was skipped.

Arrow up / down in query results doesn’t seem to work on my system – it just scrolls the page.

The description of M as “click the limit button” is correct, but I don’t think simply emulating the click is the ideal behavior for the keyboard shortcut :) when the limit popup opens, I’d expect to be able to close it with Esc (instead of pressing M again), and the focus should also be within the input field.

But apart from these details, my big question is – how do we educate our users about these new features? Currently, as far as I’m aware, the only way to find out about them would be to follow Jonas on Twitter (and see this tweet), to follow this task, or (for some of the shortcuts) to be familiar with vim (or Jupyter) and make a lucky guess. I’m fine with delaying this question for now (the current state of the Universal Language Selector, with the double-Esc issue, is very confusing), but eventually we need to answer it.

[Note: I wrote this comment several hours ago, but did send it at first because I wanted to verify the Jupyter behavior first. But it looks like PAWS is currently down…]

But apart from these details, my big question is – how do we educate our users about these new features?

I see two ways

• Mention in the documentation (assuming that only experts need the shortcuts)
• Mention in/at the corresponding GUI elements.

Mentioning at corresponding UI elements sound like a good idea. Currently the "execute query" already have a shortcut hint:

It seems this is now live on query.wikidata.org, and I’ve noticed that pressing Esc to close the editor’s autocompletions or suggestions now also removes focus from the editor. I think we need to ignore the Esc in that case, since autocompletions can happen without the user requesting them, e. g. after typing a period.

@Graham87 you should now be able to use query.wikidata.org with your keyboard.

In T173213#3903959, @Jonas wrote:

@Graham87 you should now be able to use query.wikidata.org with your keyboard.

Thanks very much! I was able to get the example queryabout largest cities with female mayors to work, but I wasn't able to generate my own about zoos outside Australia that have kangaroos , for example, using the main interface. My main problem is using the combo boxes ... JAWS doesn't read the entries in them. I'm using JAWS with Firefox ... I don't actually know what needs to be done to fix things.

Thanks I will create a ticket for the screen reader issue.