Adding accessibility features to game?

[valthea]

Hi everyone! I’m currently helping develop a game on BGA Studio, and I realized that (like most games on the platform it seems) it isn’t possible to navigate or play using the keyboard alone (e.g. you can't tab through elements on the page). I’d really like to make sure the game I’m working on is accessible to players who use screen readers, can’t use a mouse, or rely on other assistive tech.

I haven’t found much documentation or examples about accessibility in the forums or wiki docs, so I wanted to ask:

• Has anyone tried implementing keyboard navigation? (e.g. using tabindex, handling Enter/Space for clicks)

• Are there known ways to make the game state more screenreader–friendly (like with aria-label or live regions)?

• Have you run into limitations with how the BGA client handles focus or dynamic elements?

My background is in graphic design, so I already know about or am already addressing things like color contrast, adding focus outlines, image descriptions, and mobile responsive layouts.

I’d really appreciate hearing from anyone who’s looked into this - whether you’ve implemented small things, have ideas, or ran into roadblocks. Even knowing what’s possible (or not) within BGA’s architecture would be super helpful!

If there’s interest, I’d love to start compiling any findings or code examples into a small guide so others can make their games more accessible too

Thanks in advance!

[thoun]

It's definitely in interesting subject, and we hope we can do better for accessibility in our games!

So far I just replaced in the framework buttons created as links (this.addActionButton) by real buttons (this.statusBar.addActionButton) so it's less confusing for screen readers, but it's a really small first step.

[valthea]

It's definitely in interesting subject, and we hope we can do better for accessibility in our games!

So far I just replaced in the framework buttons created as links (this.addActionButton) by real buttons (this.statusBar.addActionButton) so it's less confusing for screen readers, but it's a really small first step.

Thank you, that's really helpful, I actually didn't even know those "buttons" get created as just <a> links!

[RicardoRix]

There was a forum thread that was started by a blind user, trying to play Amalfi. They brought up some interesting insights and found similar problems in usability. I can't even start to understand just how difficult it would be to try and do that.

I did look into it a little bit for my own game, I did some research and quickly realised it was a much bigger topic than I could fully appreciate.
I did however adpat my game Auntie Mildreds list of Random Tasks to some degree adding certain informative aria html attribute tags (aria-*). It is at-least largely related to adapting just 1 file, the game.js file. But I can't really claim I did a top-notch job.

Pure speculation, but the BGA framework could perhaps automatically add things like this to the title bar and user action buttons, player panels, etc.

https://developer.mozilla.org/en-US/doc ... ility/ARIA

[robinzig]

I want to add something to this topic. For background, I'm am a front-end developer professionally, and making accessible user interfaces is really important to me. I've also developed one game for BGA (Deus, if interested - don't expect that to be any more accessible than the others though I'm afraid), and was planning to do more (and did start one) but I doubt I will now as I have other interests which I prefer to devote my time to.

The biggest problem I see, in terms of screen-reader users at any rate, is far more fundamental than incorrectly marked-up buttons/links. It's: how does a screenreader report what the game state is - ie what's on the board(s), and where.

In virtually every BGA adaptation, this information is purely visual. You can only figure out what's going on by looking at stuff. All the visual game information is conveyed by a div (a semantically meaningless element), with a "background-image" CSS property which makes it look like the game board or some other game piece. Similarly for the player pieces - they're divs with a CSS background-image so they look like the appropriately-coloured meeple (for example), and the position of these things on the board is conveyed simply through visuals (as indeed it is in a physical boardgame).

And with the best will in the world, I don't see how you can present any of this - certainly for games on the more complex end of the spectrum - with clean semantic elements (or aria roles) and attributes telling screenreader users exactly what the player will need to know. Maybe it's just my own lack of imagination - I'm sure with some effort, some makeshift could be come up with. But it would need very careful thought for each game, rather than anything which can be simply changed at the "BGA framework" level.

I'm not saying BGA, and individual developers who adapt games for the platform, shouldn't think about these things. Absolutely they should - and in particular, by doing things like exposing buttons (marked up as such, so they're tabbable to, with a clear focus outline and good colour contrast etc) to perform game actions (rather than forcing the user to click on a div inside another div), games could be made much more accessible to users who, while they can see the screen, rely on a keyboard (or some assistive technology) rather than a mouse to perform actions.

But full screenreader accessibility, so that blind or severely visually-impaired users, can fully parse the game state and participate fully, while absolutely something all web applications should try to provide, sadly seems out of reach at the preset state of BGA. Perhaps with it being "baked" in from the very beginning it would stand a better chance, but as it is it's dependent on individual developers not only thinking of it in the first place (which many sadly won't), but then designing the whole game adaptation from the start to make this happen. And I don't even know if that's possible, for some of the more complex games at least.

[valthea]

There was a forum thread that was started by a blind user, trying to play Amalfi. They brought up some interesting insights and found similar problems in usability. I can't even start to understand just how difficult it would be to try and do that.

I did look into it a little bit for my own game, I did some research and quickly realised it was a much bigger topic than I could fully appreciate.
I did however adpat my game Auntie Mildreds list of Random Tasks to some degree adding certain informative aria html attribute tags (aria-*). It is at-least largely related to adapting just 1 file, the game.js file. But I can't really claim I did a top-notch job.

Pure speculation, but the BGA framework could perhaps automatically add things like this to the title bar and user action buttons, player panels, etc.

https://developer.mozilla.org/en-US/doc ... ility/ARIA

Yeah, it’s such a huge topic! It would be amazing if BGA would add some of these things directly in their framework - it would make a huge difference! But based on some of the accessibility related bug reports I've seen, they don't seem to have the resources to do this, or don't prioritize it.

But that's awesome that you were able to make some adaptations for your game, even small things can be helpful for many players! Every bit of progress helps

[valthea]

I want to add something to this topic. For background, I'm am a front-end developer professionally, and making accessible user interfaces is really important to me. I've also developed one game for BGA (Deus, if interested - don't expect that to be any more accessible than the others though I'm afraid), and was planning to do more (and did start one) but I doubt I will now as I have other interests which I prefer to devote my time to.

The biggest problem I see, in terms of screen-reader users at any rate, is far more fundamental than incorrectly marked-up buttons/links. It's: how does a screenreader report what the game state is - ie what's on the board(s), and where.

In virtually every BGA adaptation, this information is purely visual. You can only figure out what's going on by looking at stuff. All the visual game information is conveyed by a div (a semantically meaningless element), with a "background-image" CSS property which makes it look like the game board or some other game piece. Similarly for the player pieces - they're divs with a CSS background-image so they look like the appropriately-coloured meeple (for example), and the position of these things on the board is conveyed simply through visuals (as indeed it is in a physical boardgame).

And with the best will in the world, I don't see how you can present any of this - certainly for games on the more complex end of the spectrum - with clean semantic elements (or aria roles) and attributes telling screenreader users exactly what the player will need to know. Maybe it's just my own lack of imagination - I'm sure with some effort, some makeshift could be come up with. But it would need very careful thought for each game, rather than anything which can be simply changed at the "BGA framework" level.

I'm not saying BGA, and individual developers who adapt games for the platform, shouldn't think about these things. Absolutely they should - and in particular, by doing things like exposing buttons (marked up as such, so they're tabbable to, with a clear focus outline and good colour contrast etc) to perform game actions (rather than forcing the user to click on a div inside another div), games could be made much more accessible to users who, while they can see the screen, rely on a keyboard (or some assistive technology) rather than a mouse to perform actions.

But full screenreader accessibility, so that blind or severely visually-impaired users, can fully parse the game state and participate fully, while absolutely something all web applications should try to provide, sadly seems out of reach at the preset state of BGA. Perhaps with it being "baked" in from the very beginning it would stand a better chance, but as it is it's dependent on individual developers not only thinking of it in the first place (which many sadly won't), but then designing the whole game adaptation from the start to make this happen. And I don't even know if that's possible, for some of the more complex games at least.

I totally get what you're saying, and agree it's an especially difficult challenge for more complex games, but I think anything we can add in, no matter how small, is still a step in the right direction. There's no such thing as 100% digital accessibility right now anyway, and as you mention, anything we include is still going to be valuable for players with other disabilities, including temporary and situational ones.

Sadly I don't think, at least with our current technology, it's ever going to be a very smooth/easy/fast experience for fully blind players. Similar to accessibility for movies and video games, I'm not sure we have very good solutions for them, just because of the nature of what visual sight is I guess, and I don't know what we can do about that