Glad you enjoyed it. Nice catch on the Silver card - I'll try to get the fix up this weekend.
As for how things are implemented, well let me tell you, it wasn't easy. The ARIA spec just doesn't seem to be cut out for interactive experiences like a game. It's best for the more one-sided "I decide how to navigate and consume largely static content" paradigm, and rather poor for other situations.
From a technical perspective, what's going on is that I'm using an aria-live region to speak things to the player and basically trying to structure things so that such a fragile speaking context works with the mechanics of the game.
One big problem is that you have very little control over what the aria-live region speaks, and in particular, you have no guarantee that it will speak anything, so you cannot reliably inform the player of anything! It interrupts itself all the time, which is great for contexts in which most people use web browsers, like tabbing through items on a page; you don't want to have to sit there listening to things when you've moved on. But in a game, the game needs to be able to exert information of its own. It's not a passive thing you browse (generally), and that model isn't really supported with the ARIA spec.
As a result, you need something that, at any given time, is a browseable, static reality that WILL work with the ARIA spec, which basically means: turn-based. I structured the game like a conversation – the game prompts you to make a decision, you make it, it tells you what you need to know to make the next decision. This runs counter to how screen readers treat just about every other page on the internet AND you're fighting the learned conventions of the person playing the game, but at least it's workable if you can convey some concepts to the player on how to navigate it. So the game has to establish some conventions of its own, and then hope that the ingrained behaviors of the player aren't so strong that they render them useless.
Because of the above, I came up with the concept of a "sentinel page" that explains some of this stuff on the front end, and some uniform conventions like always being able to type some keys for a recap of the current situation and context-sensitive help, but ultimately, there's not a lot of guidance out there regarding how to implement stuff like this. What's here was cobbled together from reading lots of articles about more mundane screen reader support cases, which usually boil down to "how to make your web form accessible", which only gets you so far.
If you're interested in still more details, the code is unobfuscated; just use the developer console in your web browser to check it out. You'll have to open the iframe itchio puts the game in and then browse the sources for accessible-game-framework.js, which is the heart of the game.
Just keep in mind this was all made in 48 hours one week for a game jam (the #7DRL), so it might be a little messier under the hood than it otherwise would be!