Last weekend, I launched WAI A Day, the daily random WAI resource fun and information.

I added some things: A web page lists the URLs now together with the dates they have been picked for. This meant I had to give the page a history of all previously generated URLs. In the first version of the page, it only served as a random generator of a WAI URL and also, basically, only as an API – returning just the URL as a text string. So every time I accessed the URL, the response was different.

To change the design, I now save every URL into a JSON file, together with the date as a key. This allows me to check if a key is present for the current day and return that URL, or generate a URL if it is not. The first time the wai-a-day.yatil.net domain is accessed every day, the randomizer picks a URL and saves it to the JSON file.

I have used this way of a key/value storage quite often, and it is quick and just works. There are probably quicker ways to do the lookup that does not require as much reading from disk, but to be honest, I cross that bridge when I get to it after the JSON files gets many, many megabytes large.

What I don’t like is the monotony that the repeated generic social media previews on the WAI A Day Mastodon account bring. Sure, this might not be a big deal in the grand scheme of things, but because I only have the URLs and I cannot produce more meaningful content for the toots posts, the social media previews are distracting. I wonder if I could parse the social graph texts myself and return a more meaningful, generated image – like I do for this blog – and embed this as an image in the post. But then that would not be clickable to the resource.

Proxying all links through the WAI A Day site was a consideration, but cool URIs don’t change. While I have no problem with the WAI A Day page going away, I’d like all fragments of its existence to work independently with the original URLs.

The feedback from the community has been great, 65 followers on Mastodon and 20 on (reluctantly) Bluesky is not a huge number, but it’s a start. I wonder if I can use the data elsewhere, too. Would a Slack integration be useful? (Boo! Walled gardens!)

I want to highlight that the randomizer did a good job picking interesting pages in the first seven days (and I did a good job narrowing the options down for it):

• 2025-03-08: Planning and Managing: Initiate
  • This resource gives organizations hints on how to start making concrete accessibility changes that last. You couldn’t imagine a better first link.
• 2025-03-09: User Agent Accessibility Guidelines (UAAG) Overview
  • W3C has many standards, this is the one about Browsers and what they should do for accessibility. A little niche, but that’s why it’s random.
• 2025-03-10: Overview of “Web Accessibility for Older Users: A Literature Review”
  • If I had seen this in the dataset, I probably would have removed it from the list, as it is more of a support document to another document, and also last updated in 2008. Still relevant, though.
• 2025-03-11: Resources for Policy Makers
  • I debated letting these meta-pages in there, but seeing it here after a niche page, having a broad one feels right.
• 2025-03-12: Cognitive Accessibility Objective: Use Clear and Understandable Content
  • The supplemental guidance of how WCAG relates to cognitive disabilities is great, so I’m happy that it is included in the list! (I’m less happy that these pages use a separate navigation pattern from the main WAI site, I find it confusing.)
• 2025-03-13: Accessibility Principles
  • This page is frequently the first I guide people new to accessibility to, as it is a really nice overview of the guiding principles.
• 2025-03-14: Zoom Levels - Easy Checks
  • This is part of the relatively new draft Easy Checks, and I like it. Learn how to test zoom.

I hope the radomizer keeps picking this well. Don’t forget that you can support this and all my other indy projects on Steady. Or subscribe to the newsletter.