My accessibility info site renewal project

I've been wondering about renewing my accessibility site on and off for a while now. The accessibility site is a quite basic Drupal project - a Drupal 9 site with a custom Drupal theme. Since I now have a single Drupal site for the backend of both my portfolio and blog, I've been thinking if I should add the accessibility content to that Drupal and get rid of the extra work that comes with maintaining two separate Drupal sites.

Defining the hopes and dreams for the new site

Before diving into the tech changes I first stopped to think about the content. I now have it in two languages and the first menu level is getting quite long in both language versions. I've also collected quite a few new content ideas, some of which don't really fit under any of the existing menu items. So a structure renewal was needed as well.

Then I stopped to think about the content types. I currently have two types in use, basic content, and demos. I also have already started working on a glossary section, for which I have a separate content type. I also have a content type for the blog highlights, but those I've been planning to get directly from the blog itself in the future.

Planning the new site structure

While I worked with my previous employer, site structure Excel sheets were a very common thing. They were used for both defining the site structure as well as defining needed redirects. So based on the good memories with these, I decided to use a sheet to define the structure I wanted.

I wanted to keep a lot of the structure but add new content wrapper topics. The old "Accessibility" menu became "Accessibility fundamentals". Under that one, I added "The basics" where pretty much all the content from the original menu will be located in the future. This allowed me to add accessibility laws easily under the umbrella term of accessibility fundamentals.

I decided to get rid of the old resources section and spread the content to multiple places instead.

Digging deeper into the content types

The basic content is a very simple content type with only a base WYSIWYG editor for the body, some meta tags, and another WYSIWYG editor for the source material. So this could be easily created with any backend option currently available.

The demo content type is slightly more complex. I'd need to add code to the page, because I'd need to add classes and HTML. But if the backend doesn't allow this, I can always create all the demo content on the frontend side. Doesn't really make a difference. On some level, it might even be easier to have all the demo stuff, styles, and all, on the front end and not scattered.

A new content type I've been planning for is the glossary. I'm planning to add some common and maybe some less common terms to the site to help users navigate the terminology of everything related to accessibility. For this, I don't need much. Basically a title and some content. Possibility to add links. So should be relatively easily doable on any setup.

Tech choices

There are currently a lot of technologies to choose from for both the backend and the front end. While I love that there are so many options to choose from, the downside is also that there are so many options to choose from. I also always like to choose something that might at least on some level be relevant to my work. Well, technically, you could say any web technology is related to my work. But you know what I mean.

Backend option one: Combining my Drupal sites into a single, even larger site

The idea of having all my content in one Drupal has its advantages. Lesser maintenance requirements, for one. And the familiarity of a CMS (Content Management System) I know and love is always comforting.

The first small hiccup is that both my portfolio and my blog only exist in English and I intend to keep them that way. My accessibility site is available in both Finnish and English. So I would need to add language features to the Drupal site. This is not a huge thing, since Drupal has good language capabilities. But it would still be extra complexity for the site.

Then I also started to think about what benefits does Drupal actually bring to this site. Not much, to be honest. A familiar user interface that I prefer to many others is probably the biggest benefit. But as long as I have a backend I can use without getting angry at the world, I'm good. The site is currently so simple in structure that the best Drupal features (the best in my opinion, of course) aren't even used much on the site.

So... if I won't benefit from Drupal that much, should I maybe investigate some other approaches? I decided to do just that.

Backend option two: Using a new backend for the accessibility website

There are a lot of new technologies appearing all the time. So getting to know a new technology is always an option on my mind. I've been reading a lot about various headless CMSs.

I'm not looking into the paid options because my projects are just for fun. There are a lot of CMSs that offer a free tier as well as the paid tier, which gives me quite a few options.

Testing out one of the new technologies sounded like a fun idea. It has also been a while since I've last done something like that, so it felt like the right time to be a bit more experimental.

Frontend options

The idea of going headless has been on my table for a while now. Partly because I want to practice accessible searches in headless projects. The real options for me were Gatsby and Next.js. Both I have some experience with, and both I enjoy using. Knowledge of both can likely benefit me at work as well. So neither would be a bad option to pick.

What I wanted to add to the front end was TypeScript. I've finally started learning about it, so this hopefully is a good project to practice it with. And since I have this specific look and feel on my sites, I might do the same for my other sites as well later on.

What did I end up choosing?

For the backend, I first decided to take a look at Payload CMS. It looks decent, is created with TypeScript, and seems to meet all my basic needs. I wasn't too happy with their site causing me nausea because of all the animations. But hey, why not respect the reduced motion setting when you can ignore it? When I started to test it, I found it was lacking in documentation, or even more specifically, examples. In the end, I decided to give Payload CMS developers more time to finish up the product.

I had already a few years ago taken a look at Strapi. At that time it was really unstable and felt unfinished. But I decided to take a new look at it. And it seemed like a good fit for me this time. So I will use Strapi as the backend.

For the front end, I ended up choosing Next.js because that is what my portfolio and blog run as well. I hope major updates will be easier to handle when everything uses the same technology. I decided that I didn't want too many new things for this project, so sticking to a familiar front end would be good for me. I can always do yet another rework project later if I want to also try some new technology for the front end.

Let's see how the project goes. Hopefully, I'll get to report my first thoughts on Strapi after a successful project.