Hey everyone, welcome back to another blogpost about my GSoC’25 experience with Drupal. With the midterm evaluations just on the horizon, I thought it would be only fitting to put out an update detailing my progress since my last blogpost. Let’s continue where we left off.
When the coding phase officially began, it was only imperative that I set up a proper strategy. Together with my mentor, I put together a week-by-week plan on a spreadsheet that broke the project down into smaller, manageable chunks. Having those clear goals for each week gave me something concrete to aim for, while also helping us track progress and adjust when needed. It might sound like a small thing, but having this kind of roadmap has already saved me from going off-track more than once.
At the same time, I focused on getting the development setup right. I created a personal GitHub repository where I could experiment freely, and a GitLab repository that would hold the main project code in line with Drupal’s contribution workflows. To make sure everything tied back into the Drupal community, I also opened a Drupal issue for the project and set up a sandbox with a clear description of what the project is about and what functionality it aims to provide. This way, anyone in the community can follow along, give feedback, or even test things out as the work progresses.
With a solid plan and the right repositories in place, I had both the structure and the space to start building confidently.
Once the planning and repositories were ready, it was time to actually give the project a structure (a skeleton, if you will) inside Drupal. That meant creating the basic scaffolding files that every Drupal module needs in order to exist. This step involved giving the module its name and identity, defining what routes it would eventually serve, setting up basic permissions, and preparing the space for storing any custom data. In essence, it involved making sure Drupal knows the module exists, what it’s supposed to do, and how it should plug into the system.
With the scaffolding in place, the next major milestone was to start working on the accessibility dashboard. I needed to create a space where administrators could get an at-a-glance view of their site’s accessibility health, track progress over time, and prioritize fixes based on severity.
I began by sketching out a basic structure for the dashboard’s frontend. At its core, it needed to support several key functions:
The dashboard needed to provide a high-level summary of key statistics, such as the total number of pages scanned and the violation count as well as how those issues are distributed across different severity levels. So, I started working on integrating the features I mentioned above one-by-one.
The first feature I tackled was the Accessibility Settings Form. This became the control panel for how scans should run, so I built it as a configuration form using Drupal’s Form API. The form lives in src/Form/AccessibilitySettingsForm.php and stores its values through Drupal’s Configuration API, with the schema defined in config/schema/accessibility.settings.yml. The settings are organized into several sections for clarity and flexibility: