Where creativity meets logic.
I built this because I wanted a locally-hosted project management suite. I've been starting new projects with a PM perspective. That means creating and saving foundational documentation, such as project charters and SOPs. I wanted something to view project progress at a glance: working items, risks, decisions, relationships, and recent activity. This app has increased my productivity tenfold.
Here's the boilerplate you didn't ask for, and might need, but you're here anyway. I've been finding myself using this stack a lot, and thought it'd be nice to cut a bunch of repetitive initializ-y stuff out. I created this with WCAG compliance in mind, but I didn't want to bloat it. It's ultimately up to the dev to ensure accessibility. I plan to add a few more barebones components, but I would like to keep it small so that devs don't have to remove too much if they don't need it. Tailwind has pretty good utilities for A11y, so definitely take advantage of those.
This is my first accessibility tool. I wrote it specifically for my portfolio site, but I figured it could be useful to others. It uses axe-core and Playwright to render both a report in JSON and as an HTML document that can be viewed in the browser. The project focuses on making accessibility testing more repeatable, consistent, and approachable while reducing the manual effort involved in running routine audits. Built with extensibility and maintainability in mind, Report Runner serves as a standalone testing utility that can evolve alongside accessibility standards and development practices. Rather than treating automated testing as a substitute for human evaluation, the tool is intended to complement manual accessibility audits and support a more comprehensive approach to building inclusive web experiences.
Learn the “why” behind accessible UI. Ally is an accessibility-first React component library built to explore what makes an interface genuinely usable. Rather than treating accessibility as a checklist of attributes or automated test results, Ally focuses on the reasoning behind component behavior, from native HTML semantics and keyboard interaction to focus management and assistive technology support. The goal is to create components that are useful in real applications while making their accessibility decisions understandable to the developers who use them. Why Ally Exists Modern component libraries make it easy to assemble an interface. Understanding why those components behave the way they do is another matter. A dialog might look correct but mishandle focus. A custom button might respond to mouse clicks but fail with a keyboard. An ARIA attribute might appear helpful while introducing behavior the browser never needed assistance with. Ally explores these problems from the foundation up. The project began with a simple question: What does the browser already provide, and what responsibility remains with the developer? That question guides both the implementation and the documentation. Accessibility by Design Ally uses WCAG 2.2 Level AA as its baseline, with accessibility requirements considered before implementation rather than added during remediation. Its development principles include: Native first. Prefer semantic HTML and built-in browser behavior wherever possible. ARIA with purpose. Introduce ARIA only when necessary, with a clear understanding of its effect. Explicit contracts. Make accessibility-critical requirements and component responsibilities understandable to consumers. Predictable behavior. Design keyboard interactions, focus behavior, and state ownership deliberately. Verification over assumptions. Test implementation behavior instead of assuming that semantic markup or an automated scan guarantees accessibility. Explain the reasoning. Document not only what a component does, but why its implementation takes a particular approach. Accessibility is not a feature that Ally adds. It is the foundation on which the library is built. Learning Through Implementation One of Ally's central goals is to make accessibility decisions visible. Component documentation is intended to explain relevant browser behavior, accessibility requirements, design tradeoffs, and verification methods. Planned interactive demonstrations will allow developers to explore what happens when important accessibility behaviors are missing or implemented incorrectly. These “Break It” examples are designed to make otherwise subtle problems easier to recognize and understand. The objective isn't simply to provide code developers can copy. It's to help them develop the judgment needed to build accessible interfaces independently. Engineering Approach Ally is built with React and TypeScript, using Vite for development and a lightweight approach to dependencies. The component architecture prioritizes native elements, clearly defined APIs, and minimal assumptions about the applications consuming the library. Accessibility verification is part of the engineering workflow, with unit and browser-level tests covering component semantics and behavior. The foundational button work provides an early example of this approach. Its tests examine native rendering, property forwarding, ref access, keyboard interaction, disabled behavior, and forced-colors considerations. Although a button is comparatively simple, it provides a useful starting point for examining where browser responsibility ends and component responsibility begins. Design Without Compromising Usability Ally also explores how expressive visual design can coexist with rigorous accessibility requirements. Its visual system includes Coffee and Porcelain themes, with high-contrast considerations informing color and focus treatments. Typography, contrast, focus indicators, responsive behavior, and system accessibility preferences are treated as functional design decisions. The goal isn't to make every interface look the same. It's to create room for visual personality without compromising usability. Current Development Ally is an ongoing project. Its initial work has focused on establishing engineering conventions, component contracts, testing practices, and the foundation for future components. Planned areas of exploration include dialogs, comboboxes, data tables, and form controls, where keyboard behavior, state management, and assistive technology expectations become increasingly complex. As the library grows, its documentation and demonstrations will grow alongside the components themselves. The Bigger Picture Ally is both a component library and an ongoing study of accessible interface engineering. Its purpose is to demonstrate that accessibility can be deliberate, testable, maintainable, and understandable without sacrificing the creativity that makes interface development enjoyable. Ally works with you, not for you.
Believe it or not, my first personal webpage was on the NeoPets website. I was obsessed with everything that is cringy now: flaming text, audio that played on page load, and frames. Oh, frames... More than anything, I wanted my own domain name, but was stuck with free subdomains for the time being. I went from NeoPets to Angefire (remember them?), and then was able to purchase my first domain in 2007. I was so excited. I remember starting out with PHP on that domain, and discovered the awesomeness (at the time) that was PHP includes. My first step to the DRY principle! I'd also used Wordpress and Blogger, but always preferred to write everything from scratch - silly me. In 2018 I learned VueJS and Nuxt, and launched my previous iteration of maiko.dev with Nuxt. I also started using Prismic, which is now my CMS of choice. I only discovered Tailwind CSS a few years ago and am obsessed. This site uses ReactJS and Next, which were a bit of a learning curve coming from Vue and Nuxt. The similarities between React and Vue were enough to keep me interested, and I can definitely see why React is so widely-used. It takes more to configure, but I think that's one of the things I like about it. This project is over 20 years in the making. It's gone through dozens of redesigns and several name changes, but it's always been my pet project.