Accessible Solitaire

It was suggested to me that I might post my latest LinkedIn article here, for people who don’t have a LinkedIn account. So here we go.

The latest article

After nearly two years of working on an app which explores a variety of accessible experiences with a selection of solitaire games, someone posted this comment about what I’d done:

“Honestly I don’t know what they were thinking.”

It’s moments like this when one has to ask oneself: What do I think? And if that person’s comment is fair (which it most certainly is), is my publishing of an app called “Accessible Solitaire” an indication that I really don’t know what I’m talking about, or I’m trying to mislead people?

So what do I think’s gone well?

I originally started on the app when an Android accessibility advocate asked me: “are you considering adding a version of the solitaire game?” I had no plans to do that prior to this question, but clearly there was interest, so I set to work. I only build .NET MAUI apps these days, as MAUI makes it relatively straightforward to build an app for all of Android, iOS and Windows.

I first built a Klondike version of the solitaire game, as that was the only solitaire game I knew. But following the success of that game, players asked for more games, so the app now also contains Spider, Baker’s Dozen, Pyramid, Tri Peaks, and Royal Parade solitaire. I’m very grateful to Angela and Rose who suggested most of these new games, and also to a player who suggested at Pyramid Solitaire – A new version of the available solitaire that I might add Spider solitaire. Details on how to play all these games are at the Accessible Solitaire blog.

Overall the games have gone down really well with players who use the iOS VoiceOver screen reader. From a dev perspective, the experiences were made possible thanks to the ease of use of some of the features described at Build accessible apps with semantic properties. Please do review that page yourself and consider how your own app can be made more usable to more people.

Some of the encouraging feedback I’ve received is below, and it’s made this app the most rewarding I’ve worked on in over twenty years of building exploratory apps.

• “If you like solitaire card games, this is amazing. Works on Apple Silicon too. I just won two games of pyramid solitaire on the Mac.”
• “…this morning, I won my first game of solitaire ever, while playing the pyramid version…”
• “I LOVE this new solitaire variant! I’ve never heard of it before either! It’s a fun game! ”

I believe the game is also playable using iOS Voice Control or Switch Control, and I received this comment relating to voice input: “I wanted to let you know that my consumer updated me today that he has been playing nonstop!”

In addition, I hope the app can be used as an educational tool for considering other aspects of accessibility, including many of the very important UI considerations mentioned in the Web Contact Accessibility Guidelines (an intro into which is at the UK Government’s Understanding WCAG 2.2). For example, use of timeouts for transient UI, or the size or colour of the various UI elements shown in the app. I had some great discussions with devs on these subjects at various get-togethers last year.

The following set of pictures show the Accessible Solitaire app running its various solitaire games on various devices with various assistive technologies.

Figure 1: An in-progress game of Klondike solitaire running in the iOS Accessible Solitaire app, in high contrast mode, with VoiceOver running. VoiceOver’s caption shows: “Moved 4 of Hearts, revealed 10 of Spades in dealt card pile 5”.

Figure 2: An in-progress game of Spider solitaire running in the Android Accessible Solitaire app, with TalkBack running. TalkBack’s caption shows: “Moved 5 of Spades, revealed 5 of Diamonds in dealt card pile 6.”

Figure 3: An in-progress game of Royal Parade solitaire running in the iOS Accessible Solitaire app, with Switch Control running. Switch Control is highlighting the second row of cards with a faint dotted rectangle, and the 9 of Clubs on that row with a solid blue rectangle.

Figure 4: An in-progress game of Baker’s Dozen solitaire running in the Windows Accessible Solitaire app. The NVDA Speech Viewer is shown beside the app, containing all the announcements made by NVDA when interacting with app. The last announcement is: “7 of Spades in Dealt card pile 6 can be moved to 8 of Hearts in Dealt card pile 12”.

Figure 5: An in-progress game of Pyramid solitaire running in the iOS Accessible Solitaire app, with Voice Control running. Voice Control is showing text by all interactable elements in the app. For example, “Menu”, “Next”, “Queen”, “6”.

Figure 6: An in-progress game of Tri Peaks solitaire running in the iOS Accessible Solitaire app, with VoiceOver running. VoiceOver’s caption shows: “Queen of Spades Row 4 can be discarded”.

So that’s all well and good now isn’t it. But…

Do I think it’s all over?

I believe everything I just said is true. However:

• The comment “Honestly I don’t know what they were thinking” was very fair. Some of the visuals shown in the app are way too small to be called accessible. They’re not even close.
• In one of the games, various colours are used to make playing the game more efficient for sighted players. While technically the colour use isn’t the only way the related information is conveyed to players, in this case its use is contrary to the spirit of building experiences that can be enjoyed by everyone.
• In some situations large text can be clipped rather than reflowing in its container.
• After receiving some great feedback from a local organisation which works with people who are partially sighted, I added a long-press feature to show a zoomed popup of a card, and a setting to customise the colours of the suits of the cards. I then found the zoom feature can trigger unexpectedly, and I removed the suit colour customisation feature because it seemed related to app crashes. So I need to revisit both of those features.
• While I claim the games can be played using voice input or a switch device, I’ve only received feedback from one person related to voice input, and none at all relating to switch device use. I don’t believe anything I build is usable until multiple users tell me it is, so I really don’t know how usable the app is with voice input or a switch device.
• Regardless of the positive feedback I’ve had from some players who use screen readers, I’ve not been able to figure out how to avoid some iOS VoiceOver behaviors that degrade the game-playing experience, and in some cases it’s even worse using the Android TalkBack screen reader.
• Perhaps related to that previous point, as far as I know, usage of the app on Android is very low. It’s also low for the Windows version. If it weren’t for the fact that the usage on iOS is far higher than any app I’ve previously built, I probably would have packed all this in by now.
• I have quite a collection of bugs and feature suggestions to address, and I really have no idea what progress I’ll make with those.

And this list could go on. All in all, the list of what’s going well is noticeably smaller than the list of things that make up the “Is the Accessible Solitaire app a con?” list.

So what’s a dev to do?

As much as I’d like to address everything in the list of problems in the app, the main challenge is finding the time. I can only work on a small proportion of the improvements that the app needs, and so I choose to only work on the things that players contact me about. While I can still only work on a subset of those, at least I know I’m working on something that matters to players.

Another reason why I’ve not addressed some players’ requests is that I don’t know how to. I’ve had requests to add a setting to only present games that are winnable, but I just don’t know how to do that. If anyone has ideas on related publicly usable approaches which I could incorporate into the game, I’d very much appreciate it.

One very important aspect of my time building exploratory apps over the years is to try to plug a gap in what’s available to people. If an app already exists which does a reasonable job, there’s no way I want to spend time on a similar app at the expense of something else I could be working on. Given that there seems to be many solitaire apps at the various stores which claim to show large, high contrast visuals, I won’t feel too bad about some of the problematic visuals shown in my app today.

I do still acknowledge that it’s unhelpful of me to publish an app with “Accessible” in its name, when for many people it’s not accessible.

Now, with each new game I add to the app, its codebase becomes increasingly precarious. The original app was never designed for all the games it currently contains, and the ice on which the app stands gets thinner and thinner. I need to stop adding new games and take a few months to clean up the code and make it robust. Otherwise the next game I add could break the lot, particularly given that the more games there are in the app, the less time I can spend regression testing each of the existing apps.

This is where all you cool devs out there may think: “I don’t see what the big deal is. I could get an AI agent to build these games in a few hours, and the code (which I’d not even have to review) would be robust.” And that would be lovely. If you’d be happy to have your AI agent deliver a truly accessible and efficient solitaire app for everyone, react to players’ requests, and make the game a free and ongoing concern, please do. I’ll move on to working on something else that doesn’t seem to be available. Until that happens, I’ll plod on with my app.

So what do I think now?

I have wondered about renaming my app to more accurately reflect the fact that in many ways the app’s not accessible. However, I’m not going to. While I don’t want people to waste their time trying out the app only to find it’s not usable, this is something I’m just going to have to live with. If I can continue to deliver an app that for at least a few people is plugging that gap in what’s available, that’ll be enough for me.

The app’s freely available at:

• Accessible Solitaire for iOS
• Accessible Solitaire for Android
• Accessible Solitaire for Windows

The app code’s all public at Accessible Solitaire at Github, but it’s only public to show how the app makes use of the very helpful SemanticProperties and Semantic screen reader. The rest of the code is a big bowl of spaghetti, to be ignored at all costs.

So now I should get on with those few months of tidying up the code and turning the app into something more robust. Mind you, someone at What new types of solitaire would you like me to consider later in the year for the Accessible Solitaire app? did suggest a few more games I might add. I’m sure I could squeeze just one more game into the app before the whole house of cards comes crashing down, I think…

Guy