DEV Community: Praise Agbabiaka

Building a Component Library: From First Component to Fully Automated Pipeline

Praise Agbabiaka — Tue, 19 May 2026 21:20:19 +0000

I was asked to architect and build a React component library from the ground up.

The problem was clear. We kept rebuilding the same components across different applications. The same buttons, inputs, modals, and layouts, recreated from scratch every time. Someone needed to own a component library and that someone ended up being me.

I nodded like I had a plan. I didn't.

I'd never built a component library before. I didn't know how to structure one, how to distribute one, or honestly how to scope one. But I figured the best way to learn was to start.

So I started small. Buttons. Inputs. The boring stuff that touches everything.

I focused on getting the foundations right, and I made the decision very early on that accessibility would be baked in from day one. Every component designed to be usable by keyboard users, screen readers, and other assistive technologies from the start. Not as a future improvement. Not as a "nice to have." Just part of the standard.

Then, the library kept growing.

Today, it's documented and hosted in Storybook, published as an npm package, and fully automated with CI/CD pipelines that handle Storybook deployments and npm publishing on every release.

What started as a vague ask turned into real infrastructure the team relies on daily.

A few things I'd tell anyone starting from zero:

You don't need to know everything upfront. Start with the smallest components and let the architecture reveal itself.
Treat accessibility like functionality. If it doesn't work with a keyboard, it's not done.
Automate early. Setting up CI/CD for publishing and deployment saved me more time than I expected.
Document everything. Storybook isn't just a demo tool. It's how the team actually adopts the library.

The gap between "I have no idea what to do" and "this is running in production" is smaller than you think. It's just a lot of small steps.

Building My First Wagtail Site

Praise Agbabiaka — Mon, 30 Oct 2023 04:09:01 +0000

Software development is an ever-changing field. Often, one has to pick up new technologies rather quickly. This was the case for me with Wagtail. And thanks to its simplicity, I was able to do so in no time.

Why Wagtail?

An opportunity to improve the accessibility of websites built with Wagtail opened up recently. And I immediately jumped on it. I was so excited at the prospect of putting my accessibility skills to use that I didn’t give much thought to the fact that I had no experience with Wagtail. I figured I could pick up Wagtail quickly enough if I put my mind to it. And since I learn best by doing, I decided to build a blog site to gain hands-on experience with Wagtail.

What’s Wagtail?

Wagtail is an open-source Content Management System built on Django. So, much of the process for building websites with Django translates directly to Wagtail. But Wagtail abstracts the need to define urls, views and admin functionality. In Wagtail, emphasis is placed on page and page content. Every page is built from a Django model that inherits from Wagtail’s Page model. Wagtail also provides a number of custom template tags and filters that extend the capabilities of the Django templating engine.

Building the Blog Site

I decided that my blog site would have a home page, a blog index page, blog post pages, and an about page. Since a home app comes out of the box with Wagtail, I only had to create a base and blog app for my Wagtail project.

In the home app, I updated the HomePage model to include fields for a hero image, heading, introduction and link to the blog index page. I defined the image and link fields as a Foreignkey to Wagtail’s Image and Page models, respectively.

As the name suggests, the base app defined functionalities shared across apps within the project. It contained snippets for the site logo, main menu and breadcrumb navigation. Within this app, I constructed a ContentBlock that allowed me to dynamically add subheading, image, list and rich text content to a page. This ContentBlock inherited from StreamBlock. It was used to define a StreamField to populate the body field of the about and blog post pages. Because the about page didn’t belong in the home or blog app, I defined a StandardPage model to create it.

The blog app held models and templates for the blog index page and blog post pages. I defined the BlogPage model as child page of the BlogIndexPage. And I populated the blog index page with meta data for each blog post. Thus, a new blog site was built.

I’m glad that I can now add Wagtail to my toolkit as a web developer. If you’d like to see my code, check out the praiztech_blog repository on GitHub. I'm still working on the front-end, though.

Growing My Skill in Web Accessibility

Praise Agbabiaka — Fri, 27 Oct 2023 12:21:44 +0000

As a self-taught web developer, my first impulse whenever I encounter a new concept is to search the Web. There's almost always a blog post or video that explains it in enough detail to help me understand. For the most part, this has been no different for web accessibility.

Using Online Resources

Once I learnt about web accessibility on Mozilla, it was quite easy to find other related posts. I found several excellent posts to expand my knowledge of accessible web development. I learnt to write accessible code with semantic Hypertext Markup Language (HTML) elements. I also learnt to test my websites with automated testing tools such as WAVE, axe DevTools and ARC Toolkit. To understand how blind users experience my websites, I learnt to test with NVDA and TalkBack screen readers. I also learnt to enhance the output of screen readers with Accessible Rich Internet Applications (ARIA) when there are no HTML alternatives.

Learning from a Great Mentor

As my knowledge of web accessibility grew, I realized that I was lacking an important skill. I didn't know how to perform a manual accessibility audit. I searched the Web but I couldn't find a simple guide on the process of manual accessibility testing. Yet, I knew I had to gain this skill. Manual auditing is the only way to identify all accessibility issues on a website.

So, when Rachele DiTullio posted on LinkedIn that they had created manual accessibility audit videos, I was excited. First, I watched the videos to understand their testing process. Then, I sent them an email requesting their mentorship. They were very receptive and agreed to mentor me. They agreed to provide weekly testing exercises and give feedback on the results. Thus began my journey into manual web accessibility auditing.

My first manual accessibility testing workbook

The Journey So Far

As I've performed manual accessibility audits, my skill have evolved over time. I've learnt to break down each webpage into smaller sections to test. I'm learning to better interpret the Web Content Accessibility Guidelines (WCAG). I'm learning how WCAG failures impact the web experience of users with disabilities. It's a journey. I'm getting better at it.