Kyruus Health
Led Kyruus Health's largest accessibility improvement: resolving 69 WCAG 2.1 AA audit findings solo across Pre-Visit, a nationwide patient check-in product.
Role
UX/UI designer(sole accessibility lead)
Timeline
Jun - Sep 2023(3 months)
Team
Cross-functionaldesign, engineering, legal, audit firm
Tools
FigmaGoogle Sheets
Jira
Results
- Resolved all 69 audit tickets within a 3-month window, solo in a 400+ person organization with no dedicated accessibility team.
- Handed off 60 dev-ready tickets to engineering; 40%+ were implemented during my tenure.
- Delivered the largest single accessibility improvement in Kyruus Health's history.
- Moved the Pre-Visit product meaningfully closer to full WCAG 2.1 AA compliance, from significant access barriers to a product that works for screen-reader users, keyboard-only users, and users with mobility impairments.
- Established a repeatable remediation process, documentation system, and cross-functional workflow that the team could build on after my departure.
Overview
Kyruus Health is a Boston-based healthcare technology company serving over 400 employees. Their flagship product, Pre-Visit, is a patient check-in application used by healthcare providers across the US. In 2023, an external accessibility audit conducted by an audit firm identified 69 issues across the product, ranging from critical access blocks to moderate usability gaps, against WCAG 2.1 AA standards.
I was the sole designer tasked with resolving the entire audit over a 3-month period, working across design, engineering, and legal in a 400+ person organization to move the needle on what became the largest accessibility improvement in the company's history.
The challenge
Kyruus had committed to WCAG 2.1 AA compliance following an external audit by an audit firm. The audit surfaced 69 issues across the Pre-Visit product: 8 critical access blocks, 21 significant barriers, and 24 moderate friction points, spanning every major user flow in the application.
The challenge wasn't just the volume. I was operating as the only person dedicated to this initiative in a company of over 400. There was no accessibility team, no established remediation process, and the product was mid-migration from one design system (M2) to another (MUI/M3), which added constraint to every solution. Every ticket required coordinating with developers and cross-referencing with both the audit firm and, in some cases, the legal team.
My job was to translate 69 external audit findings into actionable, dev-ready design decisions, scoped, prioritized, and documented, while maintaining alignment across engineering, legal, and product.
My process
Because I was working alone at scale, I needed a repeatable process I could apply consistently across all 69 tickets in a short window. I built a tracking system in Google Sheets, carrying over all audit data from the audit firm's platform, where I documented every ticket's status, my notes, communications, and decisions throughout the initiative.
For each ticket, I followed five steps:
1. Ticket analysis and WCAG guideline review
Review the ticket against the relevant WCAG criterion, coordinate with the audit firm for clarification on requirements and intent.
2. Current solution assessment
Examine the existing implementation from both a user-facing and code perspective, in collaboration with the dev team.
3. Identify technical and legal constraints
Map what's feasible given the MUI migration, development scope, and any legal considerations (HIPAA compliance being a recurring factor in a healthcare product).
4. Research, iteration, and proposal
Iterate on solutions, pressure-test with devs and the design team, and produce a final dev-ready ticket with designs where required.
5. Documentation and tracking
Record all decisions, communications, and outcomes in Jira and Sheets for full team visibility and future reference.
Scope and results
Over 3 months, I worked through all 69 audit tickets, analyzing, scoping, designing, and handing off to the development team. The work spanned the full complexity spectrum: from quick wins like color contrast adjustments, alt-text revisions, and ARIA label additions, to medium-complexity tickets requiring new component designs, restructured flows, and cross-functional alignment.
A few notable tickets beyond the quick-win category:
Taking / not taking medication buttons (E-408, E-409)
Two related critical-impact tickets: the medication status buttons weren't identifiable as selectable objects by screen readers, and their selected state was communicated by color alone, invisible to users who can't distinguish color. I explored edge cases and potential flows in Figma before creating dev-ready tickets addressing both the ARIA role issue and a visible state indicator to replace color-only feedback.
Race field and chips (E-291, E-426)
Two critical tickets around a custom race-selection component. The "Race" label wasn't identified as a selectable object by screen readers, and the resulting chip selections weren't structured as buttons, leaving screen-reader users with no way to interact with or remove them. I worked with the team to restructure the component as an accessible input pattern.
Modal restructure (E-264, E-413)
The Terms of Use modal and the check-in flow's modal carousel both had focus management issues: screen reader and keyboard focus wasn't being directed correctly on open. I collaborated with engineering on a restructured modal component using the MUI M2 base, styled toward M3 specifications, to resolve the focus behavior across both tickets simultaneously.
SignaturePad replacement
Of all the tickets in the audit, the SignaturePad replacement was the most complex and the most impactful. It was a critical-severity ticket, meaning it represented a total block of access, and it affected nearly every user flow in the product.
The problem
The on-screen signing component, SignaturePad, required users to drag a finger or pointer across the screen to produce a signature. This made it completely inaccessible to screen-reader users, keyboard-only users, and anyone with a mobility impairment or condition affecting fine motor control.
Since a signature was required to complete nearly every flow in the Pre-Visit application (consent forms, patient intake, insurance verification), this wasn't a niche edge case. It was a gate that blocked a significant portion of users from using the product at all.
Research: four options
The audit firm pointed us toward DocuSign as a reference for accessible e-signature patterns. After reviewing DocuSign and other e-signature tools, we identified four candidate approaches:
Option 1: Draw (current)
The existing solution. Inaccessible to screen-reader users, keyboard-only users, and those with motor disabilities. Could not stand alone as the only option.
Option 2: Upload image
Allowed users to upload a photo of a handwritten signature. Added significant friction, requiring a user to draw on paper, photograph it, and upload, and did nothing to solve the core problem for users who couldn't draw a signature in the first place.
Option 3: Checkbox
A simple "I agree" checkbox, familiar from Terms & Conditions flows across the web. Detectable by screen readers and operable by keyboard. Promising, but we had no clarity on whether this met HIPAA compliance requirements for a legally binding signature in a healthcare context. Flagged for legal review.
Option 4: Type
A text input where users type their full name, which is then rendered as a handwritten-style signature. Recommended directly by the audit firm. Fully accessible if the input field is screen-reader compatible. Also flagged for legal review before proceeding.
Legal review
Both the Checkbox and Type options required legal sign-off before we could move forward, specifically on whether each method constituted a valid, HIPAA-compliant e-signature in a healthcare context.
I prepared a presentation outlining both options, their accessibility rationale, and the technical feasibility of each, and presented it to the legal team. After review, legal approved the Type option and ruled out the Checkbox, which did not meet HIPAA compliance requirements for a binding signature.
Design
With the Type solution approved, the next challenge was implementation within the constraints of the ongoing MUI migration. All components had to stay within the MUI framework, with slight visual modifications if deemed necessary.
MUI offered two components with tab-like switching behavior: Tab and Button Group. I explored both, testing different layouts and placements within the signature UI. I ultimately chose Tab, positioned above the signature area as it followed the natural reading pattern from top to bottom and thus created a better visual hierarchy:
Solution
The final solution presented users with a Tab group component between Draw and Type modes, positioned directly above the signature area. The Type input field was fully screen-reader accessible and keyboard operable. With some visual customization to align the MUI component with the existing application style, the ticket was ready for engineering handoff.
The result: a signature component that maintained the existing Draw experience for users who preferred it, while providing a fully accessible Type alternative, removing a critical access block from the most user-critical component in the entire product.
Results
- Resolved all 69 audit tickets within a 3-month window, solo in a 400+ person organization with no dedicated accessibility team.
- Handed off 60 dev-ready tickets to engineering; 40%+ were implemented during my tenure.
- Delivered the largest single accessibility improvement in Kyruus Health's history.
- Moved the Pre-Visit product meaningfully closer to full WCAG 2.1 AA compliance, from significant access barriers to a product that works for screen-reader users, keyboard-only users, and users with mobility impairments.
- Established a repeatable remediation process, documentation system, and cross-functional workflow that the team could build on after my departure.