I'm working on an HTML5 game that entirely takes place in a canvas element that takes up the full page. I'm using NV Access to test how it works with screen readers. By using a hidden div with role="alert" that I update with JavaScript, I can get the screen reader to read text.
However, NV Access already has keyboard commands for pretty much every keyboard key, so when I try to control the game with WASD, or the arrow keys, or pretty much anything that isn't a game controller, it intercepts my key presses before the game can process them.
I've set role="application" on both the page's body and the canvas on separate tests and neither position seemed to change anything.
The only context where I could get NV Access to give control to the browser tab was by adding a hidden textbox to the page and focusing on that, which worked, but had the side-effect of having the screen reader read every key press, which led to moving the character always being accompanied by the sounds of "s. s. sssssssssss. d. d. dddddddddd."
This is essentially what the game page looks like:
<body role="application">
<div>
<div id="screenRead" role="alert"></div>
<canvas id="background"></canvas>
<canvas id="foreground"></canvas>
</div>
</body>
Ideally all key presses (barring control actions like Alt+Tab, Ctrl+Tab, etc.) will be accepted by the browser tab itself instead of being caught by a screen reader. Since player controls are configurable, adding exceptions for a few keys won't work (and aria-keyshortcuts didn't work for this context, anyway).