From fragmented accessibility audits to an operational accessibility platform.
HPS Accessibility began as an accessibility consulting and reporting practice and evolved toward a unified operational platform for managing testing, evidence, findings, remediation, retesting, reporting, and long-term accessibility work.
My Role
The Operations Dashboard: every client, project, and open finding in one operational view.
Accessibility programs often require client intake, structured testing, evidence gathering, issue documentation, reporting, remediation support, retesting, and ongoing monitoring.
When those activities live in separate spreadsheets, documents, scanners, tickets, and conversations, teams lose continuity and spend time reconstructing context instead of improving the product.
The design problem was not simply to create another audit interface. It was to connect the entire accessibility lifecycle while still serving people with very different needs.
Why It Mattered
The same accessibility finding can move through discovery, evidence, prioritization, remediation, verification, and executive reporting. Treating each step as a disconnected deliverable creates rework and weakens traceability.
Intake
Client scope, systems, and applicable standards are established before testing begins.
Test
Automated tooling and manual specialist testing run in combination across the defined scope.
Evidence
Screenshots, recordings, and technical detail are captured against each tested criterion.
Findings
Issues are documented, mapped to WCAG or Section 508 criteria, and rated by severity.
Report
The same findings are packaged into deliverables suited to each audience.
Remediate
Engineering and design act on prioritized findings using remediation guidance.
Retest
Fixes are verified against the original evidence before a finding is closed.
The complexity came from overlapping user needs, compliance expectations, evidence requirements, workflow states, reporting audiences, and technical constraints. I reduced that ambiguity by defining the core objects and relationships first, then designing interfaces around the decisions each role needed to make.
Five Audiences, One Record
Accessibility Specialist
Detailed scope, testing context, evidence, standards mapping, severity, remediation context, and retest history.
UX Designer
Understanding of how accessibility issues surface within the experience, the patterns affecting interaction and interface design, and a way to evaluate proposed solutions before problems reach production.
Developer
A clear defect, reproducible evidence, technical context, remediation guidance, ownership, and verification status.
Program / Project Manager
Prioritization, progress, blockers, accountability, and a reliable view across many findings at once.
Executive Stakeholder
Concise risk, trend, status, organizational exposure, and decision-ready reporting rather than specialist-level detail.
Key Insight
The same underlying finding needed to mean something different depending on who was looking at it.
The platform therefore needed one underlying source of truth while presenting information differently based on context and responsibility.
Automated accessibility checks are useful inputs, but they cannot replace manual testing, contextual judgment, evidence, remediation collaboration, design decisions, or verification. The product therefore needed to support the work around the finding, not merely display the finding itself.
Key Design Implication
Findings, evidence, remediation, retesting, and reporting needed to remain connected throughout the lifecycle so teams could see not only what was wrong, but what happened next.
Power
vs.
Simplicity
Accessibility specialists require depth, while executives, UX designers, developers, and project leaders should not have to navigate specialist-level complexity.
Resolution
Preserve the underlying depth while using contextual presentation and progressive disclosure.
Automation
vs.
Human Judgment
Automation can accelerate repetitive accessibility work, but accessibility interpretation requires expertise and context.
Resolution
Automate preparation, organization, aggregation, synthesis, and drafting where appropriate while preserving human review for interpretation and final decisions.
Documents
vs.
System
Reports are essential deliverables, but accessibility knowledge should not disappear into static PDFs and spreadsheets.
Resolution
Treat reports as outputs generated from the operational record rather than the primary place where accessibility knowledge lives.
Speed
vs.
Durability
AI-assisted prototyping and development can dramatically shorten iteration cycles, but speed can create inconsistency if the underlying system is weak.
Resolution
Use AI to accelerate exploration and implementation while maintaining reusable patterns, accessibility requirements, validation, and deliberate product decisions.
Decision
Create one underlying record that follows a finding throughout its lifecycle.
Every finding carries its evidence, remediation guidance, and retest history forward instead of resetting at each stage. Deliverables are grouped and tracked by remediation progress, not treated as a one-time export.
Decision
Allow different audiences to consume the same accessibility information at different levels of detail.
One assessment generates deliverables scoped to executive, findings, UX remediation, developer, project management, and retest audiences, each drawn from the same underlying data rather than rewritten by hand.
Decision
Connect remediation and retesting back to the original evidence rather than treating them as separate activities.
The developer remediation view reads as an assessment narrative tied to specific findings and their evidence, not a disconnected list of violations handed off without context.
My process moved from workflow definition and information architecture into interface design, reusable patterns, functional prototyping, implementation, validation, and iteration.
Figma + AI + Working Software + Human Judgment
Discover
Understand the workflow, the audiences, and the constraints before any interface exists.
Frame
Define the objects, states, and relationships the product needs to represent.
Design
Structure the interface and reusable patterns around the decisions each role needs to make.
Prototype
Build functional prototypes to evaluate interaction and workflow decisions before implementation.
Build
Move from prototype into working software, informed by real technical and operational constraints.
Validate
Confirm the built experience against the intended user, business, and accessibility outcomes.
Iterate
Adjust the experience as constraints surface, without losing the original outcome.
I did not treat static Figma files as the end of the design process. By working closer to implementation and using functional prototypes, I could evaluate interaction decisions in something much closer to the final product.
When technical or operational constraints surfaced, I could adjust the experience without losing the original user outcome.
A — In My Design & Development Process
I use ChatGPT and Claude as collaborative tools throughout product development. They help me:
I Remain Responsible For
Product decisions, UX judgment, accessibility requirements, validation, acceptance criteria, and final experience quality. The purpose of AI is to increase the speed and breadth of exploration, not replace design judgment.
B — Within HPS Accessibility
AI and automation can reduce repetitive accessibility work by helping:
But accessibility decisions require human judgment. AI should assist accessibility professionals, UX designers, developers, project managers, and decision makers — not pretend to replace expertise.
Automate the repetition. Preserve the judgment.
Engineering collaboration and AI-assisted development accelerated implementation, but I did not delegate product judgment to the tools.
I remained accountable for what the experience needed to accomplish, how the workflows fit together, and whether the implemented result met the intended user, business, and accessibility outcomes.
The project established a unified model for accessibility work spanning intake, testing, evidence, findings, reporting, remediation, retesting, and long-term monitoring.
It created the foundation for role-specific experiences, remediation tracking, executive and technical reporting, and ongoing accessibility operations rather than treating each engagement as a disconnected audit.
The biggest product decision happened before I designed the interface.
Defining accessibility as a continuous operational process changed what needed to be designed. Once that point of view was clear, individual screens, reports, workflow states, automation, and AI decisions could be evaluated against a coherent system rather than designed in isolation.
Federal healthcare reporting and regulatory submission systems for CMS.gov, built for users whose submission deadlines carry regulatory consequences.
Section 508 requirements were built into the design specification rather than audited in after the fact, the same prevention-first approach applied here.