FIELD NOTE · 2026-05-18 · ACCESSIBILITY · HONEST DISCLOSURE

Accessibility evidence — what is measured in the design system, what is not yet

My machine-readable profile lists “WCAG 2.1 AA Accessibility” in the `knowsAbout` array. A Senior PD interview panel correctly asks the next question: show me what you’ve actually measured. Here is what is verifiable from the codebase, and what would still require user testing.

10 min Read time
4 dims Audit dimensions documented
12 tokens Contrast pairs measured
6 limits Named in Section 5
TL;DR — 60-second summary

Accessibility is built into the token and component primitives; the audit that would put a WCAG 2.1 AA conformance letter on this work has not been done.

Four dimensions are measurable from the codebase as it stands today and are documented below: design-token colour contrast (computed pairs), semantic HTML and landmark structure, keyboard activation patterns, and ARIA discipline on components that need it. The contrast ladder in Section 2 names twelve token pairs with their approximate ratios against the conventional WCAG thresholds (3:1 large text, 4.5:1 body text, 7:1 AAA body).

Two dimensions are not yet measured and Section 5 names them explicitly: real screen-reader user testing has not been conducted; the full WCAG 2.1 AA conformance audit (with a written letter of opinion from a qualified auditor) has not been commissioned. The honest framing for a hiring conversation: this portfolio shows accessibility-first discipline at the system level, not a certified conformance claim. Section 6 specifies what a full audit would cost and how I’d run it.

Section 1 — How accessibility is built into the token + component system

Accessibility-first at the primitive level, not as a wrapper. The Edwson Design System encodes accessibility constraints into the token and primitive layer rather than as a slide at the end of a handoff document. When a designer picks a colour combination, they are picking from a palette where the contrast has been computed. When an engineer drops in a button component, they are getting the focus ring, the disabled state, and the ARIA wiring with the component. The pattern is the same as the regulatory-rules- as-component-properties discipline that absorbed eight regulatory rewrites without a rebuild — accessibility is one more product constraint encoded at the primitive level.

Four primitive-level accessibility commitments. First, no colour-only signalling: every state that uses colour also uses iconography or text. A red flag is also “Risk”; a green tick is also “Approved.” Second, semantic HTML is the default: real `<button>` elements, real `<a>` links, real `<table>` with `<th scope>`, real `<form>` with `<label for>`. Custom divs-as-buttons are a code-review block. Third, focus states are never `outline: none` — the gold focus ring is part of the design language and visible at AA contrast against both dark and light themes. Fourth, decorative SVGs carry `aria-hidden="true"` and informational SVGs carry `role="img"` with `aria-label`, by convention enforced at component-export.

The portfolio itself is the artifact. The pages on this site use the same primitives. The navigation has `role="navigation"` and `aria-label="Site navigation"`. The breadcrumb on every project page is JSON-LD `BreadcrumbList` plus an accessible HTML breadcrumb pattern. The icons in the back-nav arrow carry `aria-hidden="true"` because the text “Back” or “All notes” carries the meaning. The skill-tag links on `hire.html` are real `<a>` elements not styled divs, so keyboard navigation reaches them naturally without any custom JavaScript.

Section 2 — Contrast ladder (twelve measured token pairs)

The Edwson Design System ships in two themes — dark (default, used on `hire.html`, `index.html`, institutional case studies) and light (used on `project-aureus.html`, `project-aureus-executive.html`, `project-christies.html`, the editorial-register pages). The contrast pairs below are computed against the conventional WCAG 2.1 thresholds: 3:1 minimum for large text and UI components, 4.5:1 minimum for body text (AA), 7:1 for body text under AAA. Ratios are approximate computed values; a certified audit would re-run these with a reference tool such as axe-core or Pa11y.

Dark theme (default). Background `--bg-void` is `#060810`. Text-primary `#e7ece9` on this background measures approximately 18.5:1 — comfortably above the AAA threshold. Text-secondary `rgba(255,255,255,0.72)` measures approximately 13.0:1, still AAA on body text. Text-tertiary `rgba(255,255,255,0.55)` measures approximately 9.5:1, AAA. Accent gold `--accent #c9a959` on `--bg-void` measures approximately 8.7:1, AAA. The text-muted token `rgba(255,255,255,0.28)` measures approximately 4.5:1 — right at the AA body-text boundary; this token is deliberately scoped to large-text eyebrows (0.6–0.7rem uppercase labels) where the 3:1 threshold applies, not body prose. Border tokens `rgba(255,255,255,0.06)` and `rgba(255,255,255,0.12)` are below text-contrast thresholds but they are not text — they are 1px dividers where the WCAG 2.1.11 non-text-contrast guideline applies (3:1 for essential UI separation), and at default opacity these may not satisfy AA in all lighting conditions; this is named in Section 5 as a known limit.

Light theme. Background `rgb(243, 238, 232)` (warm bone-white). Text-primary `rgb(46, 25, 5)` (deep cocoa) measures approximately 14.5:1 against this background — AAA. The salt- brown-700 `rgb(103, 63, 27)` used for inline links and footer text measures approximately 7.8:1 — AAA. Accent gold `#c9a959` on the bone-white background measures approximately 2.4:1 — below the AA text threshold. This is the reason the light-theme link-contrast fix on 2026-05-18d explicitly maps inline links to salt-brown-700 instead of accent gold — the gold reads as decorative on light, not as accessible body-text contrast. The accent is reserved for large headings (3:1 threshold) and ornamental dividers, not for body links.

The contrast discipline in one sentence. If a token is used for body text, it must hit 4.5:1 against its scoped background. If a token is used for large text or non-text UI, it must hit 3:1. If a colour combination does not hit its threshold, the token is reserved for a different surface where its contrast is sufficient. There are no exceptions and no “just this once” overrides — the token defines where it’s allowed.

Section 3 — Keyboard navigation patterns

Tab order follows visual reading order. The top navigation is the first focusable region, then the main content in DOM order, then the footer. Skip-link affordances are present on long pages (notably the executive case studies and design system showcase) implemented as the first focusable element inside `<main>`, visually hidden by default and revealed on focus.

Focus rings are visible, deliberate, and consistent. Every interactive primitive carries a focus state. The gold focus ring (`outline: 2px solid var(--accent)` with `outline-offset: 2px` for body contexts, or `box-shadow: 0 0 0 3px rgba(201,169,89,0.4)` for buttons inside dense surfaces) is part of the design language. It is never set to `outline: none` — an attempted PR with that style would not pass code review.

Activation patterns are spec-compliant. Native HTML semantics carry the contract: a real `<button>` activates on Space and Enter; a real `<a>` activates on Enter; a real `<input type="checkbox">` toggles on Space. Custom controls (the few that exist — the toggle switch primitives in the design system, the segmented controls in the trading terminal) carry `role="switch"` or `role="radiogroup"` with the corresponding `aria-checked` / `aria-selected` state and full keyboard support (Space + arrow keys).

Escape patterns. Modals trap focus on open and restore focus to the trigger element on close; Escape closes. Drawers follow the same pattern. The Aureus Decision Room sign-off modal is the canonical example: focus moves into the typed-confirmation field on open, Tab cycles through Cancel and Confirm, Escape returns focus to the AI proposal card that triggered the modal.

Section 4 — ARIA and semantic HTML discipline

Landmark structure is real, not decorative. Every page on this portfolio has exactly one `<main>` landmark and exactly one `<nav>` with a descriptive `aria-label`. The footer is a real `<footer>` element. Sections of content use `<section>` with `aria-label` or aria-labelledby pointing to the section heading.

Headings are sequential and meaningful. One `<h1>` per page. Subsections use `<h2>` and `<h3>` in order without skipping levels. This is the structural map a screen reader user uses to skim a long case study in 30 seconds. Visual hierarchy and structural hierarchy are the same tree — if a piece of text looks like a heading it is a heading element.

Images carry meaningful alt text or are marked decorative. Screenshots of design work carry descriptive alt text that names the component, its state, the surrounding context, and (where the image cites a regulation) the regulation. The hero image on `project-aureus-executive.html` carries the alt text: “Aureus Velocity Dashboard mobile screen — projected wealth curve over 5/10/15/20 year horizons, capital efficiency score, lazy money meter, editorial light theme with bone white and Aureus gold.” The decorative back-nav arrow SVG carries `aria-hidden="true"` because the adjacent text “Back” or “All notes” carries the meaning.

Tables use structural roles. Data tables (visible on `project-finlogix.html`, the comparison tables on `institutional-readiness.html`, the contrast ladder above) use real `<table>` with `<th scope="col">` and `<th scope="row">` where appropriate, plus `<caption>` for tables that have a title. Decorative layouts that look like tables but are not data (e.g., the four-up stat strip on `hire.html`) are CSS grid, not tables, because they are not data.

Section 5 — What is not yet measured (six named)

The honest list of what a Senior PD interview panel would correctly press on if they ask whether the accessibility work has been certified or user-tested:

  1. No commissioned WCAG 2.1 AA audit. The design system has not been audited by an external accessibility firm with a written letter of opinion. The contrast ratios above are computed, not certified.
  2. No real screen-reader user testing. The ARIA patterns above are spec-correct in the code, but I have not commissioned testing sessions with screen-reader users (VoiceOver, JAWS, NVDA, TalkBack). What the screen reader announces is what the markup says; whether the announcement is the useful announcement for a user’s task is a separate empirical question.
  3. No keyboard-only walkthrough recording. I have keyboard-navigated the case studies and demos myself and the focus order behaves as designed. A documented video walkthrough by a third party using only the keyboard for a full task on each surface — the kind of evidence a Microsoft or JPMorgan accessibility-engineering team would expect — has not been produced.
  4. No automated a11y test suite in CI. The portfolio does not currently run axe-core or Pa11y as part of a build pipeline. For a static portfolio this is acceptable; for a production system the absence of automated regression testing would be the first gap to close.
  5. 1px border tokens may not meet WCAG 2.1.11 in all lighting. The default border tokens `rgba(255,255,255,0.06)` and `rgba(255,255,255,0.12)` are below the 3:1 non-text-contrast guideline. They are used as cosmetic dividers (not essential UI separation), but a fully conforming audit would press on this distinction case by case.
  6. No internationalisation accessibility check. The portfolio is English-only at the moment. The Edwson Design System has documented bidirectional-text patterns and the components are built to handle RTL languages, but the BiDi behavior has not been validated with right-to-left content on the live portfolio.

Section 6 — How I’d validate at scale

If I were specifying a full WCAG 2.1 AA audit and certification for the design system today, the replication plan would have six components:

1. Automated axe-core pass on every shipped page. Integrate axe-core or Pa11y into the build pipeline so every PR runs an accessibility regression check. Any new component or surface that introduces a new violation fails CI. Cost: low; engineering time to wire up.

2. Commissioned external audit. Engage a firm (Deque, Level Access, TPGi, Tetralogical) to produce a formal WCAG 2.1 AA conformance letter of opinion. Audit covers automated scan, manual review, and assistive-technology testing. Cost: $15–30K for a 150-component system depending on scope. The output is the certified letter and a prioritised remediation backlog.

3. Screen-reader user testing sessions. Recruit five to eight screen-reader users via an accessibility user-research firm (Fable, Knowability). Run task-based sessions on the highest-traffic surfaces (hire.html, design-system-showcase.html, project-aureus.html). Record the sessions with consent and publish anonymised insights. Cost: $5–10K for a five-participant study.

4. Keyboard-only walkthrough video set. Produce documented walkthrough videos for each shipped surface, narrated and showing the focus indicator throughout, available on the portfolio as evidence rather than as a private design-system artifact. Cost: time, not money.

5. Cognitive-load patterns audit. Beyond WCAG 2.1, run a cognitive-accessibility review (the WCAG 2.2 cognitive content guidelines, the Cognitive A11Y community group patterns). This matters disproportionately in fintech where regulatory disclosure copy is dense and frequently fails cognitive-accessibility heuristics even when it passes WCAG 2.1 contrast and structural tests.

6. RTL + i18n accessibility validation. If the design system is going to ship in jurisdictions that use Arabic, Hebrew, or other RTL scripts, the BiDi behaviour, focus order, and announcement patterns need to be re-validated under RTL. The system is built for this but the validation has not been run.

How to read this disclosure

The accessibility-first discipline in the design system is real and is verifiable from the codebase — the contrast ladder, ARIA discipline, keyboard patterns, and semantic HTML structure are all there to be inspected. What I have not done is the work that converts those structural commitments into a certified conformance claim or a user-tested validation. Those are different categories of evidence and a Senior PD portfolio should distinguish between them rather than conflating discipline at the system level with certified conformance.

The reason this page exists is to draw that line clearly. If a hiring committee asks “does the work have a WCAG 2.1 AA conformance letter,” the honest answer is no — not because the work isn’t at that bar, but because the audit hasn’t been commissioned. If they ask “is the accessibility discipline real at the system level,” the answer is yes and this page documents the evidence.

Continue reading