Tristen's Portfolio - Tristen Breitenfeldt | Digital Accessibility Analyst

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.

Case Study 3 — A11y Notebook

The problem:: Personal knowledge management — notes, tasks, documents, and research — is typically done in apps like Notion, Obsidian, Evernote, or OneNote.; Those apps are designed around visual layout: nested tree views, drag-and-drop organization, side panes, canvas views, and pointer-driven panels. A screen reader can reach parts of them, but the core workflows — finding a note, moving it, understanding how things are organized — are slow, unreliable, or impossible with keyboard alone.; No free, fully screen-reader-operable knowledge manager existed that put notes, tasks, documents, and research in one place. The result: blind professionals and students were left patching together plain text files, or doing without an organized system — not for lack of need, but for lack of an accessible tool.
I saw an opportunity to approach the problem differently:: What if a knowledge manager were designed from the start as a screen-reader-first experience?; Rather than adapting a sighted workflow, I conceptualized a notebook built around the way a blind user actually works: linear navigation, keyboard-driven actions, context menus, and spoken feedback for every operation — with a reading view that presents notes as structured documents a screen reader can navigate by heading, link, list, and table.; The barriers in existing tools show up at several points:; Organization relies on visual tree hierarchies and drag-and-drop that screen readers can’t navigate efficiently.; Tab and pane management assumes you can see what is open.; Reading views don’t expose semantic structure — headings, lists, tables — so screen-reader navigation commands have nothing to work with.; Date and time pickers use native popups that trap the keyboard or announce poorly.; Search results don’t announce counts or let you move through matches efficiently.; Blind users may be expected to organize their work using tools that weren’t designed with their access as a requirement.
This suggested a broader design opportunity:: The knowledge manager itself should model the accessibility it enables — 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 knowledge management tools include:: • blind students, professionals, and researchers; • screen-reader users managing notes, tasks, and documents; • accessibility professionals who need an organized workspace for audits and research; • blind colleagues onboarding into knowledge work that assumes sighted tools; • anyone who needs a personal knowledge base without a sighted workflow
My solution: A free, open-source, screen-reader-first personal knowledge manager for Windows and Mac.
My contribution: • I identified the problem from lived experience; • defined a screen-reader-first user experience; • conceptualized the feature set (notes, tasks, documents, research, reminders, calendar); • 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: A11y Notebook was born from personal necessity, creative problem solving, and many hours of prompt engineering and collaborative AI development — notes, files, tasks, reminders, calendar sync, citations and bibliography, and import of many document formats, with dictation, audio notes, and local transcription in the latest release, all fully operable with a screen reader and keyboard. Download the latest release for Windows or Mac.