How I test
I look at how an experience actually unfolds: screen reader flow, keyboard movement, structure, forms, dialogs, error states, and whether someone can make it all the way through a task without unnecessary friction.
Accessibility portfolio
A more human way to show how I actually approach accessibility work.
This page exists because a resume only tells part of the story. What matters more to me is whether you can get a feel for how I test, how I notice things, and how I turn those observations into something useful for product teams and for disabled users.
What this portfolio shows
I do not want this to feel like polished theater. I want it to feel like a real window into how I work.
How I write findings
I try to describe barriers in plain language, connect them to real user impact, and give teams enough context to understand not just what is broken, but why it matters.
How I think about fixes
I care about whether a recommendation is actually usable. A good fix is not just technically correct. It should make the experience clearer, reduce friction, and feel realistic for a real team to implement.
Featured studies
Two recent public-site reviews showing how I document both broken accessible names and broken screen reader flow.
Case study
Manual homepage accessibility review
I reviewed a public event discovery page with screen reader testing, keyboard navigation, DOM inspection, and accessibility tree checks to understand whether event browsing remained understandable once controls and links were exposed through assistive technology.
Scope: Homepage event cards, location search, headings, interactive navigation, and link naming
Tools: VoiceOver, keyboard-only navigation, Playwright, live DOM inspection, and Chromium accessibility tree review
What worked: The page exposed visible event titles clearly in browse reading, and the event detail page itself appeared stronger than the homepage card layer
Primary barrier: Event card links used an unresolved accessible-name template instead of the actual event title, causing assistive technology to announce placeholder text
Secondary barrier: A product fulfillment area on another public retail site appeared to contain duplicated or hidden interactive controls that disrupted screen reader navigation near pickup and quantity selection
Testing note
The important part of this review was not just hearing something odd once. I verified the homepage issue in the live React-rendered DOM and confirmed that the computed accessible name for multiple event links was the unresolved placeholder string rather than the visible event title.
Source tested: Eventbrite homepage event discovery flow
Source URL: https://www.eventbrite.com/
Finding format
The strongest portfolio artifact for tester roles is often not a full audit. It is a clean defect writeup based on a real experience.
When I document accessibility issues, I focus on what the user was trying to do, what failed, how to reproduce it, and what kind of fix direction the team needs next. I prefer real findings over generic examples whenever I can use them responsibly.
Finding structure
- Issue title with clear scope
- Affected users and user impact
- Reproducible steps and observed behavior
- Relevant standards reference when needed
- Plain-language remediation direction
Recent findings
Two real defect writeups from public-site testing, edited for clarity and portfolio use.
Finding 1
Event links expose unresolved placeholder text instead of the actual event title
- Issue
- Homepage event card links expose placeholder text in the accessible name rather than the specific event title shown visually on the page.
- Affected users
- Screen reader users and anyone relying on programmatic link names to move through a list of events efficiently.
- Environment
- Public event discovery homepage tested with VoiceOver, keyboard navigation, live DOM inspection, and accessibility tree review.
- Steps
- Open the homepage, move through the event cards with a screen reader or link navigation, and compare the announced link name with the visible event title.
- Observed
- The link name is exposed as unresolved placeholder text rather than the actual title of the event.
- Expected
- The link should expose the actual event title, or a clear action label that includes the actual event title, so each event link is distinct and understandable.
- User impact
- Users navigating by links can hear repeated, low-value names instead of meaningful event titles, which makes browsing slower and less reliable.
- Suggested remediation
- Populate the accessible name template correctly or remove the overriding
aria-labelso the visible event title can provide the accessible name.
Finding 2
Fulfillment and quantity controls create inconsistent screen reader navigation on a product page
- Issue
- Near the pickup and quantity area on a product page, screen reader navigation becomes inconsistent and can jump away from the expected interaction path instead of moving cleanly through fulfillment and purchase controls.
- Affected users
- Screen reader users, especially people relying on predictable sequential navigation to move through fulfillment, quantity, and purchase controls.
- Environment
- Public retail product page tested with VoiceOver in Safari and Chrome, with stronger impact observed in Safari. Live DOM and accessibility-tree review were used to support the finding.
- Steps
- Navigate through the product fulfillment section, move across pickup-related controls, and continue toward the quantity picker using screen reader navigation.
- Observed
- Screen reader interaction becomes unstable near the pickup and quantity controls, and navigation can jump away from the product interaction area rather than continuing in a predictable sequence.
- Expected
- Users should be able to move through fulfillment selection, pickup details, quantity, and add-to-cart controls in a stable, logical order without being pushed out of context.
- User impact
- Users may lose context before completing a purchase-related task, which increases confusion and makes fulfillment selection and cart actions less reliable.
- Suggested remediation
- Review the fulfillment and sticky add-to-cart implementation for duplicated or hidden interactive controls. Only the active control set should remain available to assistive technology, and hidden variants should not interfere with navigation order or accessible focus.
Testing approach
What I pay attention to when I evaluate an experience.
Screen reader flow
I look for whether the experience stays understandable and operable in sequence, not just whether individual controls have labels.
Keyboard flow
I care about focus order, interaction states, trap conditions, and whether a keyboard user can complete the task without guesswork.
Structure and meaning
Headings, landmarks, buttons, links, form labels, error handling, and state changes all need to communicate the right thing at the right time.
Tools and methods
The point is not to name every tool. It is to show how I use them to evaluate real user experience.
Assistive technology
I use VoiceOver, JAWS, and NVDA to evaluate whether a flow stays understandable, navigable, and complete for screen reader users.
- Screen reader flow and announcement quality
- Navigation landmarks, headings, and controls
- Task completion, not just isolated element checks
Manual interaction testing
I combine screen reader testing with keyboard-only review to check focus order, interaction states, dialogs, forms, and error recovery.
- Keyboard operability and focus management
- Form labeling, instructions, and validation feedback
- Dynamic content behavior and modal handling
Reporting and remediation
I document findings in plain language with reproducible steps, user impact, and practical remediation guidance teams can actually work from.
- Clear defect framing for product and engineering teams
- Impact tied to real user barriers
- Retesting and remediation validation after fixes
Next step