Skip to main content
joshuaBriley

Briley Creative LLC — Example Audit Report

Harwin Financial

Design System Audit — Severe findings scenario

Client
Harwin Financial Services
Product
Harwin Advisor Portal
Audit dates
March 2–6, 2026
Report date
March 11, 2026
Prepared by
Joshua Briley, Briley Creative LLC
WCAG target
WCAG 2.1 Level AA
3 Critical findings
3 Critical6 High7 Medium3 Low

1. Executive summary

Harwin's Advisor Portal design system is under significant structural stress. What began as a shared component library has fragmented into at least three parallel implementations maintained by separate teams, with no central governance or token system. The result is a product that is visually inconsistent, partially inaccessible, and increasingly difficult to maintain.

The system is not a candidate for targeted remediation alone. The token architecture does not exist in any meaningful sense; components use hard-coded values almost exclusively. A remediation plan that addresses individual findings without also establishing a token foundation and governance process will produce the same fragmentation in twelve months.

Critical
3
High
6
Medium
7
Low
3

2. What is working well

  • The core Button component in the primary design system package (ds-core) is well-implemented, accessible, and consistent between Figma and code. It is one of the few components that has not been duplicated in the parallel implementations.

  • The Figma library maintained by the design team is internally consistent and would serve as a reliable source of truth for a future token extraction effort. The structure is sound even if the coded implementation has diverged from it.

3. Findings

3a — Accessibility

ACC-01

Custom data grid is not keyboard accessible and has no ARIA semantics

Critical
Location
AdvisorGrid — /portfolio, /clients, /transactions
Description
The AdvisorGrid is a custom-built table used on every major page of the application. It is implemented as a series of div elements with no ARIA roles. It cannot be navigated by keyboard. Tab skips over the grid entirely — keyboard users cannot access any data within it. Screen readers announce the grid as an undifferentiated block of text. This fails WCAG 2.1 Success Criteria 1.3.1, 2.1.1, and 4.1.2.
Remediation
Rebuild AdvisorGrid with proper table semantics using <table>, <thead>, <tbody>, <tr>, <th scope="col">, and <td> elements, or implement the ARIA grid pattern if a native table cannot be used. Add full keyboard interaction: arrow key navigation, Tab to move focus in and out, Enter or Space to activate interactive cells. Schedule a spike to estimate the effort before committing to a sprint.
ACC-02

Date picker is mouse-only; keyboard users cannot select a date

Critical
Location
DatePickerInput — /reports/generate, /transactions/filter, /clients/add
Description
The DatePickerInput opens a calendar popover on click but the calendar is not keyboard operable. Pressing Enter or Space on the input field does not open the popover. Arrow keys do not navigate between dates. There is no way to close the popover with Escape. This blocks keyboard users from generating reports and filtering transactions — both core advisor tasks.
Remediation
Replace the current implementation with an accessible alternative such as the React Aria useDatePicker hook or react-day-picker with appropriate ARIA attributes. Do not patch the current implementation. The interaction model must be rebuilt from the keyboard up.
ACC-03

Session timeout warning dialog is not announced to screen reader users

Critical
Location
SessionTimeoutModal — global
Description
The session timeout warning appears after 14 minutes of inactivity and gives users 60 seconds to extend their session. The modal has no role="dialog", no aria-modal="true", and no aria-labelledby. A screen reader user will be logged out without warning. In a financial application, an unexpected logout mid-task can result in unsaved client data loss.
Remediation
Add role="dialog", aria-modal="true", and aria-labelledby pointing to the modal heading. Add aria-live="assertive" to the countdown timer element. Implement focus trapping within the modal. On open, move focus to the modal heading or the primary action button. Test with VoiceOver in both Chrome and Safari.
ACC-04

All form error messages lack programmatic association with their fields

High
Location
All forms — /clients/add, /transactions/new, /reports/generate
Description
Form validation errors appear visually but are not associated with their fields via aria-describedby. This affects every form in the application. VoiceOver users completing any form cannot hear error messages when navigating between fields.
Remediation
Implement a shared FormField component with built-in aria-describedby wiring. The error element must be present in the DOM when active. Migrate all existing forms to use the shared component.
ACC-05

Navigation sidebar active state and badge counts fail contrast requirements

High
Location
AppSidebar, NotificationBadge — global
Description
The active sidebar item uses white text on #3B82F6 at a contrast ratio of 3.1:1. Notification badges use white on #EF4444 at 3.6:1. Both fail the WCAG 2.1 Level AA minimum of 4.5:1 for normal text.
Remediation
Update the active sidebar background to #1D4ED8 (contrast 5.2:1 with white). Update the notification badge to #B91C1C (contrast 5.8:1). Define both as semantic tokens.
ACC-06

Focus indicators are absent in Firefox and Edge

High
Location
All interactive elements — global stylesheet
Description
The global stylesheet includes :focus { outline: none; } with no replacement focus style. Firefox and Edge respect the rule fully and render no focus indicator on any interactive element. Keyboard users in these browsers cannot determine where focus is.
Remediation
Remove the global outline: none rule. Replace with a custom :focus-visible style — for example, outline: 2px solid #1A3A5C; outline-offset: 2px;. Test in Chrome, Firefox, and Edge. Apply the focus style as a design token.

3b — Component consistency

CON-01

Three parallel component implementations exist with no shared foundation

High
Location
ds-core, ds-advisor, ds-legacy — github.com/harwin
Description
Three separate component packages exist in the repository. Components are duplicated across all three. Button alone has three implementations with different props interfaces. There is no shared token system between them.
Remediation
Establish a single canonical package. Identify the most complete and accessible implementation of each component and treat it as the source of record. Deprecate the others with a clear migration timeline. Schedule a consolidation spike before the next quarter's planning.
CON-02

Typography scale is inconsistent across the three packages

Medium
Location
Heading, BodyText, Label — all three packages
Description
ds-core uses a 4-step scale. ds-advisor uses a 5-step scale. ds-legacy uses arbitrary sizes not tied to a scale. The live product reflects all three, resulting in visible typographic inconsistency between sections.
Remediation
Define a single type scale as part of the token consolidation work. The Figma design team's scale (12/14/16/20/24/32px) is the closest to a coherent system and should be used as the reference.
CON-03

Button disabled state is implemented differently across all three packages

Medium
Location
Button — ds-core, ds-advisor, ds-legacy
Description
ds-core uses opacity: 0.5 with the disabled HTML attribute. ds-advisor uses a custom disabled class with no HTML disabled attribute — keyboard users can still activate the button. ds-legacy uses only pointer-events: none with no visual or semantic indication of disabled state.
Remediation
Standardize on the ds-core approach as part of the package consolidation: apply the HTML disabled attribute to native buttons, use aria-disabled="true" for non-native interactive elements, and pair with consistent visual treatment.

3c — Design tokens

TOK-01

No token system exists; all three packages use hard-coded values throughout

High
Location
All component source — ds-core, ds-advisor, ds-legacy
Description
No token definition file exists across any package. Every color, spacing value, border radius, and shadow is hard-coded directly in component styles. Changing the primary brand color would require manual updates across an estimated 80 to 100 component files.
Remediation
Establish a token system before addressing individual component findings. Extract the Figma design team's local styles into a Style Dictionary configuration. Generate CSS custom properties as the primary output. Migrate components incrementally, starting with Button, Input, and Card as a proof of concept.
TOK-02

Figma local styles are not structured as a token hierarchy

Medium
Location
Figma library — local styles panel
Description
Figma local styles use flat, presentation-named styles (Blue 500, Gray 200, Red 400) rather than a semantic token hierarchy. This makes it difficult to extract a token system from Figma or to change the brand without manually re-mapping every style.
Remediation
Restructure Figma local styles into a two-tier token hierarchy: primitive tokens (raw values) and semantic tokens (role-based references). This should happen in parallel with the coded token system work in TOK-01.

3d — Documentation

DOC-01

No Storybook instance exists for ds-advisor or ds-legacy

Medium
Location
github.com/harwin/ds-advisor, github.com/harwin/ds-legacy
Description
Only ds-core has a Storybook instance. Developers working in the other packages have no reference for available components. This is a primary driver of the duplication found in this audit — developers build new components because they cannot discover existing ones.
Remediation
As part of the package consolidation in CON-01, ensure the canonical package has comprehensive Storybook coverage before the deprecated packages are retired. Do not invest in documenting ds-advisor or ds-legacy — direct that effort toward the canonical library.

3e — Handoff process

HND-01

No identifiable system owner across any of the three packages

High
Location
github.com/harwin — all three repositories
Description
No individual or team is identified as responsible for maintaining or governing the design system across any of the three packages. Decisions about deprecation, versioning, and new component acceptance default to informal consensus. The three-package fragmentation found in CON-01 is a direct consequence of this governance gap: the ds-advisor fork was created without a review or approval process because no such process existed.
Remediation
Designate a named owner for the canonical package before the consolidation work begins. Define what ownership means: who approves new components, who manages the deprecation timeline, and who is responsible for the changelog. Document this in a CODEOWNERS file and in the repository README.
HND-02

Design files contain heavily detached Figma components across all product areas

High
Location
Figma — Advisor Portal product file, all pages
Description
A review of the Advisor Portal Figma product file found that a significant majority of component instances across client, transaction, and reporting pages are detached from the shared library. Detached components do not update when the library updates, cannot be inspected for token names, and cannot be relied upon as specifications during development handoff. Developers cannot trust the Figma files as an accurate representation of how a component should behave.
Remediation
Audit all Figma product file pages for detached instances using the Figma plugin Detach Radar or equivalent. Prioritize reattachment on the highest-traffic pages first. Add a pre-handoff checklist item requiring designers to verify zero detached instances before marking any spec as ready for development.
HND-03

No contribution guidelines exist across any of the three packages

Low
Location
github.com/harwin — all three repos
Description
None of the three packages has a CONTRIBUTING.md or equivalent. There is no documented process for proposing new components, reviewing additions, or deprecating existing ones. The absence of a contribution process is one of the structural reasons the three-package situation developed.
Remediation
Write a contribution guide for the canonical package 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
CriticalACC-01Data grid has no keyboard access or ARIA semanticsBefore next release
CriticalACC-02Date picker is mouse-onlyBefore next release
CriticalACC-03Session timeout not announced to screen readersBefore next release
HighTOK-01No token system — all values are hard-codedCurrent sprint
HighACC-04All form errors lack aria-describedby associationCurrent sprint
HighACC-05Sidebar and badge contrast fails WCAG 2.1 AACurrent sprint
HighACC-06Focus indicators absent in Firefox and EdgeCurrent sprint
HighCON-01Three parallel packages with no shared foundationCurrent sprint (spike)
HighHND-01No identifiable system ownerCurrent sprint
HighHND-02Figma product files heavily detached from libraryCurrent sprint
MediumTOK-02Figma local styles not structured as a token hierarchy Next sprint
MediumCON-02Typography scale inconsistent across packagesNext 1–2 sprints
MediumCON-03Button disabled state differs across all three packages Next 1–2 sprints
MediumDOC-01No Storybook for ds-advisor or ds-legacyNext 1–2 sprints
LowHND-03No contribution guidelines across any packageBacklog

5. Recommended next steps

The volume and severity of findings in this report reflect systemic problems, not isolated component issues. Addressing individual findings without resolving the structural causes will produce diminishing returns. I recommend a follow-on stabilization engagement structured in three phases:

  1. Phase 1 — Critical accessibility remediation (2 weeks)

    Address ACC-01 through ACC-06. These are the legal and user-impact risk items that cannot wait for structural work to complete.

  2. Phase 2 — Token foundation and package consolidation (4–6 weeks)

    Establish the token system, consolidate the three packages into one canonical library, and migrate the highest-traffic components first.

  3. Phase 3 — Consistency and documentation (ongoing)

    Address remaining Medium and Low findings, establish contribution guidelines, and implement linter rules that prevent regression.

Retainer option

A monthly retainer for design system oversight may be more cost-effective than a series of individual engagements. This would include accessibility review of new components before they ship, quarterly token and consistency checks, and ad hoc guidance for the internal team.

6. Scope and methodology

Inputs reviewed

  • FigmaHarwin DS (shared library) + Advisor Portal product file
  • Repositoriesgithub.com/harwin/ds-core, /ds-advisor, /ds-legacy
  • Storybookstorybook.harwin.internal (ds-core only)
  • Live productadvisor.harwin.com (staging)

Accessibility testing tools and browsers

  • axe DevToolsChrome, Firefox, Edge
  • axe Linterds-core and ds-advisor source
  • VoiceOvermacOS, Chrome and Safari
  • Keyboard navChrome, Firefox, Edge

What was not reviewed

  • ds-legacyInventoried but not fully audited. Components being deprecated as part of CON-01 do not require individual remediation.
  • Mobile appOut of scope for this engagement.

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