Using OGS with keyboard is bad because: "Tools" top menu does not get focused!

After we access the main site, and open the starting page, we have a horizontal top menu. Using just the keyboard, I can navigate it by pressing the TAB key. It will focus, in the shown order:

  1. Play
  2. Learn
  3. Watch
  4. Community
  5. Tools? No! This menu item is NOT focused, and the focus is skipped to the next item, the search field.

It is not the only issue here, but it is an important one. And something hard to do with the browser! Using only the keyboard, I can get most buttons focused by searching their caption text. For example, in the main page I could press the button “I want to translate” by searching the word “translate” in the page, finding the button occurrence, and when I cancel the search function at this point, I can press the button with Enter or Space keys. But this does not work with the Tools menu! Why is that? What the Tools menu has that it is forbidden to be used like common website parts?


You do not say whether Find fails to find ‘Tools’, fails to focus on it or fails to start it.
I am not on a desktop at the moment, but a few ideas:

  • Examine the page source.
  • Could ‘Tools ’ be an image rather than text?
  • Could there be lookalike characters (e.g. Cyrillic or a zero)?
1 Like

Do you think I should edit my original post to mention this detail, @PJTraill? “Tools” is text, this is absolutely clear. It is found when I search the page with the browser. It is not needed to check the source.

And it could use any characters in the language I choose to use the site. It would not matter.

The point I tried to raise is: using the keyboard, the first site element to be focused in the main page is the logo/“start” text; the second element would be the “play” link; the third, “learn”; the fourth, “observe”; the fifth, “community”; and the sixth should be “tools”, but it is not focused at all, with the keyboard!

I can focus the previous elements directly by doing a browser search for the cited words. And this does not work for the “tools” element, for a reason that I do not know in the things that sites can allow or block. I can use any pointing device to use the menu. So, the menu works. The problem is: I cannot use it now! There is a basic usability issue in the top menu.

  • If it is an image, it shouldn’t be.
  • Even for buttons that are labelled only with an image, they should still be in the natural Tab order.

Ian, who lost his last job in large part due to the accessibility nightmare that is the “modern” web.

@genbeart , being an image or not, it does not matter (to get focus by pressing TAB). And for it not receiving focus, in my humble HTML knowledge, it is due a decision (or lack of one) of who created/edited/whatever that element, it does not get focus.

In HTML, page elements may or may not be allowed be in what can be (naturally) focused in the page. So, the fact that this element is not focused, seems to be a decision. Possibly using one of the techniques described here:

So, what should be done? Something else besides this discussion?

Have you tried using mouse? works for me :grinning:

If you have a bug write it in Bug Report category. If you’re asking for help then lowering your tone to make it sound like actual question instead of admonition and accusation would make it likely for you to receive equally poised response.

I don’t know if it’s the case for the OP, but some people with disabilities are unable to use a mouse, so they need to use the keyboard.


I’ve seen in some documentary guy singing to move cursor around :thinking:

People, can you understand that the OGS main site has a very simple and […] issue that all of you can notice and reproduce in 15 seconds or less, using any desktop computer? (or anything where we can use things without things like mice or direct point touching)

Among all who answered here, is there anyone who is a website front end developer? Or, at least, someone who has a basic knowledge of things in how sites work in our side of things, with Html, CSS and javascript? I imagine that such person can point the problem in one sentence, with all wanted details toward a solution. For example: “The ‘tools’ menu item is inheriting the value -1 value from the class Duh, in the menu creation function, instead of receiving a normal value, or having none, like the rest of the menu.”


The reason “Tools” gets skipped over is because it’s not a link, while the other menu items are. But it’s not just “Tools” that isn’t reachable by tab navigation. The links in the submenus are also not navigable by tab.


I think that we’re generally concerned to make OGS as accessible as possible. I’ll take a look at the tab order - as the OP says, it ought to be a basic thing that just works.

That said: we haven’t cracked “how can you place stones by keyboard”, so I have to wonder whether keyboard control of menus it’s a bit moot?

I guess we could have an accessible mode with a stone-cursor that moves around intersections by keyboard arrows.

I always get told off for implementing features that don’t work on a phone. I wonder howe this would work on a phone :laughing:


In general it would be great if more of the clickable widgets were links. I often try to middle-click to open things in a new tab and am frustrated to end up in the auto-scrolling mode instead.

There’s a well thought-out proposal for making the board accessible to keyboard-only users here: Blind people can't play · Issue #1366 · online-go/ · GitHub

I don’t think keyboard-only mobile users are a thing haha. Mobile screen readers are definitely a thing though!


“People who can’t use a mouse” is a really a different thing to “support for blind access”

Maybe the solution has similar elements, but “people who can’t use a mouse” only need a subset of the solution, I think?


Keyboard on mobile shouldn’t be too different from keyboard on desktop, hopefully. Anyway, if you make everything a link, you don’t have to think too hard about what devices people might be using, since everything should support links pretty well. Here’s a visualization of all the <a> tags on a random page:

There are a lot of clickable things there that you won’t be able to middle-click, long press, right-click, tab over, etc. It’s not a very fun game to try to guess what will work and what won’t.

1 Like

@avique , if I read the OP correctly, tabbing didn’t work either. So there are 2 accessibility issues here, that’s why I wrote 2 bullet points.

Tabbing is a good workaround for image controls, but still harder than focussing by searching. That’s why those image controls which are images for no design reason are bad.

Sometimes there is a legitimate reason for it to be an image, but the web is full of pages with image controls that are just images of text.

Yeah, the invention of the img tag in html was a step in the wrong direction. Only half-joking!

FYI, I can only place stones because MouseKeys exists.