Automating Accessibility Monitoring for My Portfolio with n8n

After spending time testing and improving my portfolio manually, I started thinking about something:

What if my portfolio could check itself?

Accessibility is something I don't want to think about only when I'm actively working on the website.

As I continue adding features and changing components, there's always a possibility that a new change could introduce an accessibility issue.

So I decided to experiment with n8n and build a small automated accessibility monitoring workflow for my portfolio.

This became one of my first opportunities to combine QA, automation, accessibility, APIs, and AI-assisted development into one project.

What I Wanted to Build

The idea was to create a workflow that could:

The overall concept became:

Portfolio
    ↓
Accessibility Check
    ↓
n8n
    ↓
Process Results
    ↓
Identify Issues
    ↓
Notification

Instead of manually remembering to check the website every time I made a change, I wanted the workflow to act as another layer of QA.

Why n8n?

I've been exploring n8n because of its potential for connecting different tools and automating repetitive processes.

For this project, I wanted to see if I could use it for something practical rather than simply building a generic workflow.

Accessibility monitoring seemed like a good use case because it involves a predictable process:

Check → Analyze → Report

That made it something that could potentially be automated.

Building the Workflow

I started by breaking the process into smaller steps.

Step 1 — Trigger

The workflow needs something to tell it when to run.

Depending on how I want to use it, this could be:

For monitoring, a scheduled trigger makes the most sense because it allows the check to happen automatically.

Step 2 — Access the Portfolio

The workflow then needs to interact with the deployed website.

This gave me an opportunity to think about the portfolio as an actual system under test rather than just a website I was building.

I wanted the workflow to check the real deployed version instead of only testing locally.

Step 3 — Run Accessibility Testing

The accessibility testing layer is responsible for identifying potential issues.

The checks focus on common accessibility problems such as:

The goal isn't to assume that automated testing can find everything.

Instead, it's another automated layer that can help catch common issues earlier.

Using AI During Development

AI was also part of the development process.

I used it to help me understand how the different pieces of the workflow could fit together, particularly when working with n8n nodes and connecting different parts of the process.

It helped me:

This was particularly useful because I was still getting comfortable with n8n.

Instead of spending a long time trying to figure out an unfamiliar configuration from scratch, I could use AI to explore possible approaches and then test whether they actually worked.

Turning Results Into Something Useful

One thing I realized while building the workflow is that detecting an accessibility violation isn't enough.

A raw automated result can contain a lot of technical information.

What I actually need as a QA is something actionable.

For example:

Accessibility Check
       ↓
Violations Found
       ↓
What is wrong?
       ↓
Where is it happening?
       ↓
How serious is it?
       ↓
What should I investigate?

That made me think about the workflow not just as an accessibility scanner, but as a QA reporting process.

Testing the Automation

I also had to test the workflow itself.

That meant checking:

This introduced another interesting layer.

I'm not only testing the portfolio.

I'm testing the automation that tests the portfolio.

What I Learned

Accessibility testing can be automated, but shouldn't be the only layer

Automated tools are useful for catching common accessibility issues, but they don't replace manual testing.

Keyboard testing, screen reader testing, and understanding the actual user experience are still important.

Automation requires thinking about failures

It's easy to build the "happy path":

Trigger → Test → Success

But a useful QA workflow also needs to consider:

No issues
Multiple issues
Workflow failure
Invalid response
Website unavailable
Unexpected data

n8n can be useful for QA workflows

This project helped me see n8n beyond general workflow automation.

It can potentially connect different parts of a QA process:

Test
 ↓
Process
 ↓
Analyze
 ↓
Notify
 ↓
Track

AI helped me learn faster

AI was especially useful when I encountered unfamiliar n8n configurations or needed help understanding how to connect different pieces of the workflow.

But I still had to test the workflow myself and verify that the automation actually behaved as expected.

Final Thoughts

This project started with a simple question:

"Can I automate accessibility checks for my own portfolio?"

It turned into an opportunity to explore how automation could become part of my QA workflow.

Instead of waiting until I manually remember to check my website, I can start thinking about ways to make quality checks continuous and repeatable.

It's still a small experiment, but it's one of the projects that made me more interested in combining QA + automation + accessibility + AI.

And honestly, using my own portfolio as the system under test makes it even more useful.

If I break something, I get to fix it.

If the automation catches something, I get to investigate it.

And if the workflow itself breaks?

Well... I get another thing to test.