After we access the main site, and open the starting page online-go.com/, 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:
Play
Learn
Watch
Community
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)?
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.
@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?
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.
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
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.
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.
@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.
