Briley Creative LLC — Example Audit Report

Lumen Health

Design System Audit — Moderate findings scenario

Client: Lumen Health
Product: Lumen Patient Portal
Audit dates: January 12–16, 2026
Report date: January 20, 2026
Prepared by: Joshua Briley, Briley Creative LLC
WCAG target: WCAG 2.1 Level AA

Findings

0 Critical3 High5 Medium3 Low

1. Executive summary

Lumen Health's design system shows clear signs of organic growth without consistent governance. The component library began with a coherent structure, but two years of parallel development across three product teams has introduced significant drift. The token system exists but is partially implemented. Roughly 40 percent of components reviewed still reference hard-coded color values.

The most significant concerns are in accessibility. Three High findings affect core patient-facing flows: form validation, focus management in modal dialogs, and color contrast in the appointment status indicator. In a healthcare application, these carry both legal and patient safety implications.

The system is recoverable without a full rebuild. The remediation roadmap is sequenced to address risk first, then structural debt, then documentation gaps.

Critical: 0
High: 3
Medium: 5
Low: 3

2. What is working well

The core component set — Button, Input, Select, and Checkbox — is well-implemented and consistent across Figma and code. These foundational components are solid and do not require remediation.
Typography tokens are comprehensive and correctly applied throughout the product. No hard-coded font values were found.
The Storybook getting-started guide is clear and would orient a new developer without additional help.

3. Findings

3a — Accessibility

ACC-01

Form validation errors are not programmatically associated with their fields

High

Location: AppointmentBookingForm, InsuranceUpdateForm — /appointments/book, /account/insurance
Description: Inline validation errors appear visually adjacent to form fields but are not linked using aria-describedby. When a field fails validation, VoiceOver announces the field label without the error message. A screen reader user completing the appointment booking form cannot determine what went wrong or how to correct it without navigating away from the field.
Remediation: Add aria-describedby to each input that points to the id of its error message element. Conditionally render the error element in the DOM only when the error is active — do not use CSS visibility toggling, which leaves hidden elements in the accessibility tree.

ACC-02

Modal dialogs do not trap focus or restore focus on close

High

Location: ConfirmDialog, AppointmentCancelModal — global
Description: When a modal opens, keyboard focus remains in the document behind it. A keyboard user tabbing through the interface after a modal opens will reach interactive elements in the background rather than elements inside the modal. When a modal closes, focus is not returned to the element that triggered it. This fails WCAG 2.1 Success Criteria 2.1.2 (No Keyboard Trap) and 2.4.3 (Focus Order).
Remediation: Implement a focus trap on modal open using a library such as focus-trap-react, or write a custom implementation that constrains Tab and Shift+Tab within the modal container. On modal close, use a ref to return focus to the triggering element.

ACC-03

Appointment status badges fail color contrast requirements

High

Location: AppointmentCard — /appointments/upcoming, /appointments/history
Description: The Confirmed status badge uses white text (#FFFFFF) on a green background (#4ADE80). The measured contrast ratio is 2.3:1, below the WCAG 2.1 Level AA minimum of 4.5:1 for normal text. The Cancelled badge (white on #F87171) measures 3.1:1. Both fail.
Remediation: Update the Confirmed badge to use #166534 text on a #DCFCE7 background (contrast 7.2:1). Update the Cancelled badge to use #991B1B text on #FEE2E2 (contrast 6.9:1). Update the corresponding token values in the feedback color palette.

3b — Component consistency

CON-01

Button component has four divergent implementations across product teams

Medium

Location: Primary button — /appointments, /messaging, /account, /billing
Description: The primary button exists in four versions across the product. Font weight varies between 500 and 700. Padding is inconsistent across the four areas. Border radius is 4px in three areas and 6px in billing. None of these match the Figma specification.
Remediation: Audit all Button usages across the four product areas. Replace non-library instances with the canonical Button component from the design system package. Update the Figma component to match the coded specification before handoff on any future work.

CON-02

Dropdown menu animation timing is inconsistent

Medium

Location: NavigationDropdown, FilterDropdown, UserMenu — global header, /appointments, top nav
Description: Three dropdown implementations use different transition durations: 150ms, 250ms, and no transition. The discrepancy is noticeable when using the application.
Remediation: Define a transition-duration-fast token (150ms) and apply it to all dropdown open and close transitions. Add a motion usage note to the design system documentation.

CON-03

Loading state is handled with three different patterns

Medium

Location: AppointmentList, LabResultsTable, MessagesInbox
Description: Appointments use a skeleton screen. Lab results use a spinner. Messages use a full-page loading overlay. No documented pattern explains when to use each approach and no shared loading component exists.
Remediation: Define a loading pattern policy: skeleton screens for content-heavy lists, spinners for single-component fetches, overlays only for blocking operations. Create shared Skeleton and Spinner components. Replace divergent implementations.

3c — Design tokens

TOK-01

Approximately 40 percent of components reference hard-coded color values

Medium

Location: Multiple components — component source
Description: A grep of the component source found hard-coded colors in 14 of 35 components reviewed. The most common cases are border colors (#E5E7EB), disabled state backgrounds (#F3F4F6), and shadow values. The token system defines equivalents for all of these but they are not consistently used.
Remediation: Add a linter rule (for example, stylelint-no-hard-coded-colors) to flag raw values. Replace each instance with the appropriate token reference. Add the rule to CI to prevent regression.

TOK-02

Spacing tokens are defined but not applied in component source

Low

Location: All components — component source
Description: The token system defines a spacing scale but components apply margin and padding using arbitrary pixel values rather than token references. The scale is used correctly in Figma but was not adopted in the coded implementation.
Remediation: Audit component spacing values and map each to the nearest token on the scale. Begin with the most frequently used components. Enforce token use for spacing in new components via a linter rule.

3d — Documentation

DOC-01

No documented guidance on when to use Modal vs. Drawer vs. inline expansion

Low

Location: Design system documentation — pattern library
Description: The system includes a Modal, a Drawer, and several components that expand inline. No documentation explains when to use each. Product teams have applied them inconsistently as a result.
Remediation: Write a pattern decision guide covering the use case for each, recommended content types, and product examples. Publish it in Storybook under a Patterns section.

DOC-02

FormField component does not document accessibility requirements for implementers

Low

Location: FormField — Storybook docs tab
Description: Storybook documents the visual variants but does not explain that error elements must be rendered in the DOM (not toggled with CSS) for screen readers to announce them, or that aria-describedby must link the input to the error element.
Remediation: Add an Accessibility tab to the FormField Storybook story that explains the aria-describedby pattern, documents the DOM requirement for error elements, and includes a correct code example.

3e — Handoff process

HND-01

Figma local styles use presentation names that do not match coded token names

Medium

Location: Figma library — local styles panel
Description: Figma local styles are named by appearance (Blue 500, Red 400) while the coded token system uses semantic names (color.brand.primary, color.feedback.error). Designers and developers do not share a common vocabulary for design decisions. Every handoff requires manual translation.
Remediation: Rename Figma local styles to match the semantic token names in code. Alternatively, migrate from local styles to Figma Variables with a two-tier structure: primitive collections (raw values) and semantic collections (role-based references). Align variable names exactly with the coded token names.

HND-02

No documented process for proposing or reviewing new components

Low

Location: github.com/lumenhealth/design-system — repository root
Description: There is no CONTRIBUTING.md, RFC template, or equivalent process for proposing new components. This is a primary structural cause of the three loading state patterns found in CON-03 — developers built new components because there was no process for discovering or contributing to existing ones.
Remediation: Write a contribution guide covering how to propose a new component, the review and approval process, accessibility requirements for acceptance, and how to deprecate a component with a migration path.

4. Remediation roadmap

Remediation roadmap: severity, finding ID, description, and recommended timeline for each finding
Severity	ID	Finding	Timeline
High	ACC-01	Form validation errors not linked via aria-describedby	Current sprint
High	ACC-02	Modal dialogs do not trap or restore focus	Current sprint
High	ACC-03	Appointment status badge contrast fails WCAG 2.1 AA	Current sprint
Medium	TOK-01	Approximately 40% of components use hard-coded color values	Next sprint
Medium	CON-01	Button has four divergent implementations	Next sprint
Medium	HND-01	Figma style names do not match coded token names	Next 1–2 sprints
Medium	CON-02	Dropdown animation timing inconsistent	Next 1–2 sprints
Medium	CON-03	Three different loading state patterns in use	Next 1–2 sprints
Low	TOK-02	Spacing tokens defined but not applied in source	Backlog
Low	DOC-01	No pattern guidance for overlay components	Backlog
Low	DOC-02	FormField does not document accessibility requirements	Backlog
Low	HND-02	No contribution or component proposal process	Backlog

5. Scope and methodology

Inputs reviewed

FigmaLumen Health DS (shared library) + Product file — Patient Portal
Repositorygithub.com/lumenhealth/design-system — /src/components
Storybookds.lumenhealth.com
Live productapp.lumenhealth.com (staging)

Accessibility testing tools and browsers

axe DevToolsChrome, Firefox, Edge
axe LinterComponent source
VoiceOvermacOS, Chrome and Safari
Keyboard navChrome, Firefox, Edge

Note on healthcare accessibility risk

WCAG 2.1 Level AA compliance is increasingly required under the Americans with Disabilities Act for healthcare providers. The three High accessibility findings — particularly ACC-01 and ACC-02 — directly affect a patient's ability to complete core tasks in the portal. These should be treated as legal risk items, not routine polish.

What comes after an audit?

Depending on what your system needs most, the next engagement is typically one of these.

Component Library Starter20 accessible, documented components built to your design tokens.Design-to-Code WorkflowFix the handoff process once so your team stops losing time to it every sprint.

Prefer ongoing oversight? Ask me about a monthly retainer covering accessibility review, token checks, and ad hoc guidance for your team.

This is an example report. All company names, product names, and repository paths are fictional. Any resemblance to real businesses is coincidental and unintended.

Back to design system audits