In common OGS pages, with some items that are present also in several other pages, the so called spatial navigation (which is present in several desktop browsers today, and we do it by holding one shift key, and using arrow keys to focus a page element in that direction) does not work at all.
For example, in the start page — online-go.com — we can press the right shortcut for such navigation (these are the default, you may have it being something else, if it was changed), and it will focus the OGS logo image, together with the word “start” (translated or not); the next right focus will be the “play” (translated or not) menu; then continuing in the order, the menu items “learn”, “observe” and “community” (all translated or not) are also focused. The next item, after all these, that should be focused, is the “tools” (translated or not) item. But it is never focused!! Neither with spatial navigation, not with the classic keyboard (default) focusing keys of tab or shift+tab. For both, the neighbouring items are the search item (the text field) and the “community” menu, without the “tools” between them.
The second example of items that are never focused, in any way (like described in the previous item), are the “sphere with a check mark” to accept a game challenge, or the “sphere with an X mark” to refuse the same game challenge. This “sphere with an X mark” also appears to me in the start page, in a floating window about OGS being translated by volunteers. But we can NEVER refuse (by which I mean, to focus, and to click in those spheres) all of these floating windows.
People reading this thread, please confirm the problem. Say how it is in your browser. Comment about the normal keyboard focus, with classic tab key, and with spatial navigation too.
Do you consider it a feature request when you ask all things to work as other things already do?
You bought a car with 3 tires perfect for use, but one of them is ripped, as also the reserve tire is. Do you need a new feature in that car? Or do you need to complain about this problem?
Things seem to be working almost as they should, except the tools menu may have been created differently than the other ones are.
I am thinking about the psychology to motivate volunteer developers to do work to make what you want happen. A “bug” has connotations of “you promised this should work, but it doesn’t, so it’s your fault it doesn’t”, which can make people feel defensive and not want to spend time and effort to help you. I’m not aware of OGS having a formal spec of supported features in which one might find a promise of supporting browser spatial navigation which has been violated. Whereas a feature request has a no-fault connotation of “I’d like this thing please, it’s not your fault it’s not there already”.
While I can understand there’s some need to pamper the dev team to get requests implemented, it’s still fairly standard to call this type of issue an “accessibility bug”.
Browsers enable keyboard navigation by default, and as long as the html elements are reflective of what a user sees, keyboard nav usually “just works”.
In the case of (2), the bug is that OGS has this custom UI element that looks like a button to users, but hasn’t given any hint to the browser that it’s a button: FabX
Yes, that’s a fair point: if you do things the right way following standard html patterns a lot of these things work for free or minimal effort of adding the right attributes etc. I’d have no objection to a customer of the software product I make in my day job calling it a bug, because our customers pay us 10s or 100s of 1000s of pounds/dollars for our product and we advertise it as WCAG compliant and that’s often part of our sales process, it’s in the contracts (or their supporting documents). But for OGS being a free (or almost free for supporters, but still without all those promises and expectations of commercial software) product, toning down the “bugs” can help.
I’ve liked the OP under the assumption that its proposal reflects standard practice; I am not actually familiar with the use case
I think bug report vs new feature is largely semantics. “Bug report” emphasizes the lack of viable arguments for current functionality (I’m not passing judgement on whether or not this implication is true), but both ultimately boil down to suggesting code be altered in some way to alter behavior in some way
Personally, as per my emoji post, I appreciate Uber’s advice about considering the tone of requests.
It’s something that folk requesting stuff often don’t do (or they considered it but chose an unfortunate tone anyhow )
This particular one wasn’t the inflammatory demanding type that usually gets a bite from me
One piece of good news is that there seems to be some interest in accessibility work from volunteer developers at the moment: we’re seeing activity in that area.
I’d love to see more of it getting in, though personally I have other development priorities on my plate.
Funny the thread that was suggested to be merged with this was initiated by myself, a bit more than 1 year ago. From this other thread, I think it brings something to be added with this one, which is the accessibility for blind people. I think that just having it pointed, as it is now, is enough.
The issue I brought here is broader than what I described in the other thread because I described the “x” or “close” red buttons in floating windows, and how they cannot be used with the keyboard —and there is no alternative for them (not that I know of, currently).
The reason why I call it a bug, instead of — since we discussed this here a bit — a feature request, is because:
I think it is something that I think that was not planned to be the way it is — I assume that even developers would prefer it to be like I want it to be.
I think it is something that might have been implemented in a different way (for any unexpected and normal reason, in a collective open source project) for a lack of information in something simple as adding a new menu item, with or without subitems. So, it should be corrected, having in mind the information that seems to have been missed.
I think it is something that all users would like it to be the same way I want it to be.
Making it a step toward a more accessible OGS is something that can be seen as a feature request too. But given the 3 ideas that I enumerated for the “tools” menu, I think it is a bug. The “x” button, on the other hand, being something more general (I imagine or assume this way, I do not know nothing about the OGS project inner working and source code), might be something to consider a feature request, having it changed to (for example) a normal button, or a common link of text, both focusable with tab key.
I wanted to let you know that last week I started working actively on accessibility of OGS. Good news is that yesterday there was a first release in which part of the navigation menu became accessible. Not fully yet, but submenus, tools menu, profile menu etc… are now fully accessible. That’s an incremental process and I start with focusing on making it easy to navigate to the play screen and play an actual game. But expect most of the app to become accessible.
I’m working together with a blind person who sends his feedbacks and suggestions, and we both have a passion to make the game of go more accessible to everyone.
Happy to see that this contribution will help people asking for it!
)
