Andrew Lucieer

Staff design technologist · Frontend engineer

Portfolio / 2026

Interfaces are only good when everyone can use them.

I'm Andrew. I build the systems behind accessible, dependable interfaces—connecting design intent to code that works across teams, products, and people.

Explore selected work Try the accessibility lab

Design systems → Accessibility → Product craft

Scroll to work

01 / Selected work

The work behind
better interfaces.

Three examples of how I turn design-system thinking and accessibility findings into tools other engineers can use.

01 / Design system

One system, five applications.

Reusable components, documented decisions, and theme choices that work across newer Angular apps and legacy ones still being upgraded.

Design system docs showing primary, outlined, text, and elevated button variants with disabled states.

A design system app I built by hand and maintain across enterprise applications, with separate versions for Angular 21+ and legacy apps still being upgraded. It extends Angular Material with branded themes and variants Material doesn’t provide, like small buttons applied with a single class. Each component links to its code, Figma source, and the Angular Material API reference. It also serves as guardrails for another Claude skill I wrote that generates pages from mockups using the system’s components.

Form components shown side by side in light and dark mode, including text fields with error and focus states, selects, and a multiselect.

The same components in light and dark mode, with error, focus, and disabled states carried across both themes. Theming is driven by CSS custom properties, and apps that don’t need dark mode can disable it with a Sass flag, so those styles are never generated at build time. While preparing this image, I found and fixed a contrast issue in the dark mode error state; both themes now pass WAVE contrast checks.

02 / Accessibility guidance

Make the right pattern easier to find.

Practical guidance pairs common accessibility mistakes with fixes engineers can apply in their own components.

Accessibility guidance page with WCAG 2.1 AA notes and side-by-side Do and Don’t Angular code examples.

Accessibility guidance I wrote and maintain for engineers building on our design system. Each Do/Don’t pair shows a common mistake, like unfocusable links, unlabeled icon buttons, or orphaned form labels, next to the accessible fix, so teams can avoid common WCAG 2.1 AA failures without having to be accessibility experts.

03 / Claude Code accessibility skill

Turn a failed fix into a stronger check.

A repeatable skill for resolving WAVE-reported issues, refined through fresh-agent tests on the same component.

Settings side sheet before remediation, with numbered markers on unlabeled toggles, unlabeled drag handles, and a low-contrast close button.

Before: WAVE reports 4 errors and 1 contrast error in the dashboard settings side sheet. The toggles have no labels (1), the drag handles are empty buttons (2), and the close button has very low contrast (3). Numbered markers added to link each WAVE-reported error to its location.

Process / Three fresh attempts

How I refined the skill

This component became a test case for improving the skill itself. For each attempt, I reverted the component to its original state and started a fresh Claude Code agent with no shared context, so each run tested only the skill.

  1. Attempt 1: The skill couldn’t fix the close button’s contrast, because the low contrast came from opacity, not a raw hex color. I updated the skill’s contrast guidance to handle that case.
  2. Attempt 2: The contrast fix worked, but the skill left off the attr. prefix on an aria-label binding. The label rendered the variable names instead of their values. That kind of bug passes a quick glance and fails a screen reader user. I updated the skill’s verification file to check for that specific mistake.
  3. Attempt 3: Starting from the same original component, a fresh agent fixed every WAVE-reported error in one pass, with no manual edits.

Each failure became a permanent check in the skill, so the same mistake won’t happen on the next component. The skill handles what automated checkers can find. It doesn’t add keyboard reordering for the drag handles, which WAVE can’t detect, so that still needs a human.

Settings side sheet after remediation, with WAVE reporting 0 errors and the original branded styling unchanged.

After: a fresh Claude Code session using my skill fixed all 4 errors and the contrast issue in one pass, with no manual edits. The toggles and drag handles now have labels, and the close button meets contrast requirements, with the branded styling unchanged. This was the third attempt; earlier runs exposed gaps that I fixed in the skill itself.

Diff adding a verification gate to the Claude skill that requires runtime-bound ARIA attributes to use attr. binding and be confirmed in the rendered DOM.

The check I added to the skill after attempt 2. A missing attr. prefix on an aria-label binding compiles cleanly but never reaches the rendered DOM. The skill now confirms the attribute in the DOM, not just in the template. Each failure becomes a permanent check, so the same mistake won’t happen on the next component.

A working principle

A component isn't done when it looks right. It's done when it behaves right, too.

SemanticsKeyboard accessClear feedbackConsistency at scale

02 / Built to be used

Accessibility is
in the details.

This small React demo shows practical choices: native controls, visible focus, readable states, and a layout that adapts when people change how they view it.

LIVE COMPONENT / 01

Preference panel

Use Tab to move through the controls. Try changing the view, then save your preference.

Preview options

Real buttons. Clear labels. Visible states. No custom keyboard rules to memorize.

Example interface

ACCOUNT / PREFERENCES

Stay in the loop

Choose whether to receive updates about changes to your account.

 

Try keyboard navigation and browser zoom, too. The demo uses native form controls and announces the saved result.

03 / About

I care about what happens after the mockup.

I've spent 20 years building software, starting in full-stack development and spending the last 11 across frontend engineering, UX, and design systems. At Magnit, I lead accessibility investigations and help turn findings into shared components and guidance. Earlier work includes component libraries, Storybook, prototyping, and mentoring teams through implementation.

The thread through it all is straightforward: make good design dependable for the next engineer and usable for the next person.

LinkedIn GitHub Email Andrew