Prosperity is undergoing redesign for accessibility. This will be an ongoing effort that will focus on two areas: dark mode for light-sensitive users, better labeling for screen-reader users, and the use of audio cues for people who are vision impaired. The game is web based, and the container is Electron, which is a fork of Chromium. This means that a lot of accessibility issues are actually resolved, as long as the game is developed in such a way that follows accessibility guidelines. Narrator: it did not. Luckily, there isn't too much that needs to be refactored for it to work.
The Redesign Story
Imagine my surprise when I received a DM on Reddit asking if the game was accessible for someone who is blind. A potential fan is looking for a city building game, something that didn't depend on graphics because... well, blindness. I had no idea, so I explained that the game is web based but not tested for accessibility. After chatting a bit, I installed NVDA, which is an open source and commonly used screen reader, and tried to play Prosperity with keyboard navigation and listening to a text-to-speech generator. It was unbearable. The game was designed with a mouse-user with good eyesight, because that's what I am (OK, I lied, I'm nearsighted and have astigmatism to the point that without my thick toric lens I'd be clinically blind).
So, fair enough, let's label everything. Aria-label this, aria-label that... well, that didn't really help. There is a lot of information on the screen and it's not always organized the best way. See, one of the things about HTML is that it's a document read from top to bottom, and for the most part that's what screen-readers do. So, when things are put in awkward orders, it makes the screen reader read things out of logical order. Note some of the designs were made before CSS Grids became well supported, so for the most part the game's layout is a mix of blocks, flex-boxes, and floating blocks.
My strategy then was to design one page properly, to the point that a screen reader would work more or less, and then use that as a basis for the other screens. Yes, this is a lot of work, but there's a whole segment of the population that I'm probably going to join one day who needs this.
I've been working in front-end development and design for over 10 years now, but design still remains difficult. Design of the UI can clarify or confuddle users, set usage patterns, and perhaps my worst nemesis of all, overwhelm users. A common design pattern is known as the Kitchen Sink, basically over time as people request the ability to do more and more from the same place, we add more and more functionality to the same screen, and make it all work by making text smaller, reducing whitespace, letting the same control work on multiple systems depending on context, and basically it always ends up becoming a complicated mess with steep learning curves. But, that's bad for gamers, especially if you have to impress them within their first 2 hours according to Steam's refund policy. So, my philosophy is to always think simpler.
What is the player trying to accomplish on different screens? Can we simplify some common processes? Now - just tooting my own horn a bit, I think that the Trading screen is one of the better ones - different tabs have different focuses within the general area of trading resources. What I wanted to do was to set similar expectations across all the screens. See, in hindsight one of the design flaws was that different screens behaved differently. A "tab" in the technology screen is different from a tab in the trading screen; building screen had tabs and live-update of ongoing projects, which didn't really look or feel like any other screen... so basically it was an inconsistent experience both visually and mentally. This was even more evident with screen readers because different screens essentially had different levels of accessibility. The solution, almost laughingly simple, was just to ditch all the custom made UI components and go back to the basics.
Try something different
Of course, some patterns have been inherited since the original web game, one of which is the way the tech tree is set up. Both the original web version and the PC version uses d3js to render a tech tree, although the PC version is way more polished. However, tech trees are not always the friendliest for screen readers or people who just want to spend their tech point. To tackle this problem, what I ended up doing was offer 2 UIs. One UI gave a list of techs with 2 optional filters (Techs where all prereqs are met, Techs that are not yet unlocked), and one that showed the original tech tree. Not a perfect solution, definitely lost some vertical real estate with the nested tabs (also not a great design choice), but it works. The tree is great for visualizing dependencies, the list is great for just finding a specific tech. Fingers crossed that this will actually work! :)
The list form
Uses an "Accordion" Component to expand/collapse details on techs
Note the use of Filters on top, the 2 checkboxes can express various ways to show the list
The tech tree hasn't really changed much except it's now dark mode.
Lines are better at expressing the dependencies, but navigating is really only possible with mouse.
The ongoing battle
This update is not the end. There is a lot of work to do in redesign, re-layout, rethinking the game and its mechanics. The reality is that there is no one size fits all solution, but with some work, we expanded the number of people for which the one size fits (New game idea: an incremental game where you upgrade a website with various techniques and code to increase number of potential visitors.) Anyway, thank you for reading this far. My final thought: I hope you enjoy Prosperity the game, and if there is anyone you know who have some challenges playing the game because of the UI, please let me know (ideally through discord: https://discord.gg/x4D8CtX).