Welcome to my portfolio! On this page, you can read about some of my various projects and case studies. Where available, links to the actual project are provided.
Case Study 1 — ART (the Accessibility Reporting Tool)
- Problem
- Accessibility testers often rely on a patchwork of spreadsheets, documents, issue trackers, screenshots, browser extensions, and testing tools to document their findings.
- These tools may support individual parts of the testing process, but they aren’t necessarily designed around the way accessibility testing actually happens.
- The result is a reporting process that can be time-consuming, repetitive, difficult to standardize, somewhat disorganized, and ironically, sometimes inaccessible to the people doing the testing.
- I saw an opportunity to approach the problem differently:
- What if the accessibility reporting process itself were designed as an accessible experience?
- Rather than creating another accessibility testing tool, I conceptualized an accessible reporting environment designed specifically around accessibility testers and the teams responsible for remediation.
- at several points:
- Testers may have to move information between multiple tools.
- Findings can be difficult to organize consistently across projects.
- Screenshots, reproduction steps, WCAG references, severity, and remediation guidance may live in different places.
- Reporting interfaces are not always optimized for keyboard or screen-reader workflows.
- Teams receiving reports may have difficulty translating individual findings into actionable remediation work.
- Organizations often need customizable reporting formats to fit their existing workflows.
- Accessibility testers may be expected to document barriers using tools that weren’t themselves designed with accessibility as a primary requirement.
- This suggested a broader design opportunity:
- The reporting experience should reduce cognitive and operational overhead rather than add another layer of work.
- Some of the User groups most impacted by the irregularity, disorganization, patchwork accessibility, and lack of dedicated reporting tools in the professional accessibility space include:
- • blind accessibility testers
- • low-vision testers
- • screen-reader users
- • accessibility teams
- • organizations managing remediation
- My solution
- An accessible, customizable, open-source reporting platform.
- My contribution
- • identified the problem
- • defined the user experience
- • conceptualized the feature set
- • designed workflows
- • identified accessibility requirements
- • built the solution using AI-assisted development
- • iterated based on usability/accessibility considerations
- The result
- ART (the Accessibility Reporting Tool) was born from a dream, creative problem solving, some project management, and many hours of prompt engineering and collaborative AI development.
Case Study 2 — FRAME PDF Studio
- Problem
- PDF remediation — making PDFs accessible through proper tagging, reading order, form labels, and document structure — is typically done in Adobe Acrobat Pro.
- Acrobat Pro is expensive, and its remediation workflows were not designed for keyboard-only or screen-reader operation. A blind tester cannot reliably use it to do the work.
- No free alternative existed that was fully operable with a screen reader. The result: blind accessibility professionals were effectively locked out of document remediation jobs — not for lack of skill, but for lack of an accessible tool.
- I saw an opportunity to approach the problem differently:
- What if a PDF remediation tool were designed from the start as a screen-reader-first experience?
- Rather than adapting a sighted workflow, I conceptualized a remediation studio built around the way a blind tester actually works: linear navigation, keyboard-driven actions, context menus, and spoken feedback for every operation.
- The barriers in existing tools show up at several points:
- Remediation panels rely on pointer interaction and visual layout.
- Tag trees are presented as visual hierarchies that screen readers can’t navigate efficiently.
- Reading-order tools require drag-and-drop.
- Form field labeling assumes you can see the visual relationship between labels and fields.
- The cost of Acrobat Pro puts it out of reach for freelancers, small nonprofits, and testers between contracts.
- Blind testers may be expected to remediate documents using tools that weren’t designed with their access as a requirement.
- This suggested a broader design opportunity:
- The remediation tool itself should model the accessibility it produces — every function keyboard-reachable, every action announced, every workflow linear.
- Some of the user groups most impacted by the cost, inaccessibility, and sighted-default design of existing PDF remediation tools include:
- • blind accessibility testers and remediators
- • screen-reader users asked to fix document accessibility
- • freelancers and small organizations priced out of Acrobat Pro
- • accessibility teams onboarding blind colleagues into remediation work
- • anyone who needs to remediate a PDF without a sighted workflow
- My solution
- A free, single-file, screen-reader-first PDF remediation studio.
- My contribution
- • I identified the problem from lived experience
- • defined a screen-reader-first user experience
- • conceptualized the feature set (read, remediate, fill, check, export)
- • designed keyboard-driven workflows with full context-menu access
- • identified accessibility requirements for every interaction
- • built the solution using AI-assisted development
- • tested and iterated using my own screen-reader workflow as the benchmark
- The result
- FRAME PDF Studio (Free Remediation And Manual Editing) was born from personal necessity, creative problem solving, and many hours of prompt engineering and collaborative AI development — read, remediate, fill, and export tagged PDFs, with an accessibility checker, remediation reports, undo/redo, session save/load, and e-signature support, all fully operable with a screen reader and keyboard.