Be a Better Accessibility Tester

By: Marco Salsiccia, Oct 18, 2025

Presentation info for the Beyond Repro: Be a Better Tester talk given at ATNYC 2025.

Table of Contents

Introduction

Hello there, I'm Marco Salsiccia! I've been in the Accessibility industry since 2016, starting off doing part-time iOS and Android testing at Lyft, which quickly blossomed into becoming their only Accessibility Specialist. Apart from working with designers and engineers alike on ensuring that the core app features were accessible, I filed a lot of Jira tickets, plus worked directly with the Policy teams, Web teams, and exhibited at the National Federation of the Blind conference from 2017-2022.

I went on to work at Deque Systems as a Senior Native Mobile Accessibility Coach, and was embedded with clients in order to teach their whole Agile teams about accessibility and usability. This involved writing accessibility acceptance criteria stories in Jira, walking Designers through accessibility annotation, Engineers through component implementation in iOS, Android, and on the Web, and taught QA testers how to test with the correct access technology for their platforms. I was a part of the Instructor-Led Training team, working alongside other educators to demonstrate testing techniques, accessibility fundamentals, design heuristics, usability concerns, annotation methods, and held awareness labs to show off different forms of access technology.

As the Mobile Accessibility Leader at Intuit, I regularly perform many of these same tasks with the native mobile teams for all of the Intuit apps. I regularly perform accessibility audits on the apps, web products, and design systems, while also educating every team about accessibility and usability, acting as a source of truth for compliance, regulations, requirements, and best practices.

Needless to say, I have written a ton of Jira tickets!

A Buggy Encounter

As someone who regularly uses access technology, teaches or observes others that use access technology, picture this:

An app that you regularly use in your day-to-day life updates itself overnight, and when you pop it open, it seems like the whole interface has changed. It's a dreaded UI refresh! None of the buttons, elements, or features are where you expected them to be. This can take some time to get used to, but as a blind user, you end up encountering tons of unlabeled buttons across the interface, making it impossible to know what each of them do without trial and error.

You start getting a little steamed. Exploring more through the app, suddenly your screen reader gets stuck in a trap, unable to be moved to or fro on the screen. Even more annoyed, you drag your finger around the screen to try to break the trap. You manage to focus on something outside the trap, but it turns out to be a null element that stops your screen reader from speaking.

This is a mess. Aggravated now, you know that this is just not sustainable, and you've wasted valuable time and effort trying to surmount all of these new barriers that have been thrown into your path from unaware designers and engineers. Heart rate up, you manage to finally find a contact form. You have this primal urge to let them know everything that's gone wrong, and you dump everything you've encountered into a massive, emotionally-charged email, stretching the character counter to the limit, your prose full of everything that has accumulated since first opening the app.

You slam the Send button, sit back, and wait, hopefully cooling down in the process. Except nothing comes back in a few days. Maybe a receipt email comes along, maybe a canned response, but nothing acknowledging the issues. A week goes by, then two. A new update appears, but absolutely nothing in your email has made it into the app.

There are a variety of reasons as to why accessibility feedback gets ignored or is misunderstood, but I feel that by calming down, focusing on concise and accurate information about what you are experiencing, explaining what you expected to experience, writing detailed reproduction steps, and potential remediation solutions if available, all come together into a nice package that designers and engineers are happy to receive. Something actionable, something understandable. Something that they can fully test themselves while not having to dig through the purple prose and unkind words about their mothers.

Tenets of Writing Bugs

The Web Content Accessibility Guidelines, or WCAG, are a set of criteria, practices, and standards that can be used to create a baseline foundation of accessibility for an app or website. These guidelines are built around 4 core tenets of accessibility:

I propose that these exact tenets can be used when filing accessibility bugs or sending in feedback. We can turn the P.O.U.R. tenets around to ensure that our information can be used by designers, engineers, and QA testers alike when receiving the bad news that something has broken in their product. Let's rethink of the tenets like so:

Let's dive into these tenets in more detail.

Perceivable - What happened?

We can start off by telling the developers exactly what happened. They need to be able to grasp the gist of the issue and not get lost in angry prose, or be left leaving a lot of information up to assumption.

Use Clear and Concise Summaries

Don't attempt to write the entire description of the bug in the summary. The summary is the title of the ticket that developers will see first, and this can help speed up their ability to triage the ticket to send it to the right team.

If the feedback system uses tags, put the core technology you are using in those tags. For example, [MacOS] [VoiceOver] [Safari] could be written just before adding in the specific issue in the summary.

Point out Where It Happened

Mention the page or the app screen where the issue exists, followed by the specific control or flow you are using when running into the bug. For example: Booking a Flight - To and From Airport controls.

Be specific and Informative

Write clear descriptions about the controls you were trying to use at the time. "Unable to choose To and From airports using VoiceOver" is much more informative than "Airport things are broken."

In the bug description itself, explain exactly what happened to the developers. Think about the flow you were trying to use, the goal you were trying to achieve, and how you were blocked in that Golden Path you were trying to take through their app or site.

Beware the Purple Prose

Purple Prose
Overly ornate prose or text that may disrupt a narrative flow by drawing undesirable attention to its own extravagant style of writing.

Don't wax poetic about the issue, don't pontificate on laws, guidelines, or make attacks in the description. Don't make assumptions as to what has happened. The people who are going to be fixing this issue need to know the specifics, and filling up the feedback with unnecessary bulk and emotional text can make them lose the focus of what exactly has gone wrong.

You are also not writing a novel, and the people triaging your feedback aren't looking to read a novel as well when determining the correct recipient of the ticket. Unless it's particularly relevant to the issue you are presenting, your life story and wish to flex your skills as a prosaic and prolific author can take a backseat to just presenting the clear facts.

Describe Your Technology

Briefly explain the access technology you are using and disclose your disability only if comfortable doing so. This will help the developers get prepped to test in the right environments with the right technology, rather than making them assume a certain access technology pattern or use case. This can also help them pick the right testing variables during their QA testing process when bringing in companies like Fable for actual user research and testing for the fixes.

By the end of the summary and the first step of the description, the developers should know the tech you are using, the platform you are using, where the problem exists, and what you were generally trying to do before encountering the bug.

Operable - How did it happen?

Reproduction steps are essential for determining the origin of bugs and allow developers to pinpoint which team is the correct one to fix the issue. The less you leave up to developer assumption, the better the overall outcome when the developers begin their remediation.

Take it from the Top

Your Reproduction Steps should be placed in an enumerated list. This helps guide developers from step to step through the process, and allows them to point out the specific steps in your process where bugs are occurring and use them for their own tracking and remediation purposes.

Start your repro steps from the launch of the app or loading of a website, and start from after authenticating, unless the issue is with the username/password login flow itself.

Don't start repro steps right where the bug is found. Walk the people who will be receiving this bug on how you got to it.

Detail Each Step

Use correct terminology as you are able. For a mobile screen reader for example, "Continuously swipe right with a single finger until the To Airport control is focused" is better than "Go to the To Airport button." We want to give the developers an exact guide on what we are doing with our technology to get through the flow.

Don't assume that the developers know how to operate our access technology. On the web, keyboard users utilize Tab to move between interactive elements, but screen reader users use standard screen reader navigation to move through all the elements of the page. If this is not specified in your repro steps, developers may inadvertently test a screen reader problem with keyboard/Tab key-only navigation and not be able to find the problem.

Essentially, mention every keystroke or gesture you are using to move through each step. The first time you explain a method of navigation, such as using Control+Option+Right Arrow to move through a website, quickly explain that this is a standard navigation pattern. Note: change this depending on the tech you are using.

Point Out Issues on the Way

Point out issues in separate steps as you detail your way through the process. Trying to place everything in one step can make it difficult to parse and understand when developers are working through the steps.

This also helps developers point to specific steps in the flow where they can split off issues into separate tickets and delegate them to the right teams.

Keep the steps brief and easy to follow

Your Repro steps are not the place to provide excessive detail nor pontificate on what is happening. Each step should be clear and be used to define an action you are taking to move to the next step in the process or uncover issues along the way. Just say what is happening and how you are perceiving it.

Specificity is the Key

When doing screen reader testing, feel free to add in the exact spoken feedback coming from the screen reader in quotes. This is necessary when trying to detail out grammar or spelling mistakes, or highlighting improper labeling of controls or broken alt text. Utilize the Copy Last Spoken Phrase feature to capture this verbatim.

For other access technology, describe the exact gestures, recipes, or spoken vocal phrases you are using to guide your technology through the flow. Dragon users will generally jump between the ouse grid or the "Show Links" command when trying to activate specific controls. Voice Access or Voice Control users will use "Show Names" and "Show Numbers" on mobile to pick out the exact elements they want to interact with, and developers will need to know that in order to follow your process exactly.

Basically, whatever you were doing with your personal technology setup needs to be communicated to get a fully accurate reproduction of the bug.

Understandable - What was expected to happen?

After detailing out your repro steps, now you can explain what you expected to happen based on your usage patterns. Stick to the facts and don't try to assume how something has gone wrong, unless you have direct access to the code and know how to read it.

Tell Your Story

This is your time to shine in terms of detailing out exactly how this experience should work. While you might not get developers to fully redesign an experience, you are at least giving them more data points from a missed or marginalized set of users, and that can go a long way in determining new designs moving forwards.

Explain your Assistive Technology

Explain the issues in the repro steps in more detail if necessary. Bring up the key commands or gestures you use, how they generally work when you've used the same patterns and controls in accessible apps, and compare those experiences to the issue you are filing.

This ultimately is where developers will gain knowledge and understanding of how access technology works with content and how they've broken it. Don't assume the developers know how assistive technology functions, and don't assume that they have been testing with it unless you know that for a fact. These additional details help create these awareness or educational moments that most developers tend to miss out on when going through their coding bootcamps or getting their degrees in Computer Science and Technology.

Time to Bring Up WCAG

While not generally necessary for feedback, you can get more movement on a ticket by pointing out specific criteria and standards that are being broken by the bug. If the company is familiar with accessibility lawsuits, or if they are contractually obligated to be compliant with the Web Content Accessibility Guidelines, knowing the exact criteria helps designers and developers push through fixes and helps prioritize during the triage.

You aren't expected to have all of the WCAG criteria memorized, and I built a handy set of websites that are easily navigable and break down the criteria for Web products and for Native Mobile apps. Keep this on hand when you encounter a bug, and explain which, if any, of the criteria are being violated. Call out both the number of the criteria and the criterion title, like 4.1.2 - name, role, value, or 1.3.1 - Info and Relationships.

Point these out if you are sure they are being broken, and if your repro steps and explanation corroborate the violation. These criteria will go a long way towards helping developers fully understand the breadth and seriousness of the issue, plus this provides educational moments for anyone who isn't familiar with the guidelines and standards.

Also make sure that you can differentiate between a true violation and a best practice. Following the WCAG criteria are the requirements, but if a best practice isn't being followed and it's just causing a frustrating experience, it's not technically a violation. It's fully on the companies to use WCAG as the barest of minimums to make their products accessible, and all of the usability they build on top of that foundation comes from your feedback and all of the other user research they perform.

Robust - How Best to Show What Happened

Even after being detailed in your repro steps and explanations of what happened, developers still need to see the experience so they can determine variables like app version, feature version, if the broken experience is some kind of experiment that has rolled out to a small amount of users, etc. Providing screenshots is the quickest way to accomplish this, and most bug feedback systems will allow for file uploads if you are not already directly emailing with them.

Screen Reader Tips

Screen readers, no matter the platform, will generally render a focus indicator on the screen around whichever element is in focus. Make sure your particular screen reader does not have that focus indicator turned off before taking the screenshot.

For screen reader specific issues or anything that involves dynamic interaction, screen recordings are much more ideal. They allow developers to both hear the spoken feedback and observe how focus and components are functioning as you use the experience.

When creating screen recordings, make sure that the caption panel or text viewers are on. This allows sighted developers to see the spoken output of the screen reader. This really helps folks who have trouble parsing the screen reader speech, have audio processing issues, or are Deaf.

That being said, please remember to slow down your screen reader speech when demonstrating a screen reader issue!

iOS Screen Recording

iOS has a built-in screen recording function that can be accessed through the Control Center. When doing testing, it's highly recommended to add the screen recorder feature to your Control Center so it can be easily toggled on and off.

As a VoiceOver user, performing a triple-tap or double-tap and hold on the Screen Recorder button opens up additional recording options. This is where you can choose specific apps that can receive the final output of the recording, and also turn on the Microphone. While hearing VoiceOver helps, if you can clearly narrate your actions while going through the experience, it helps quite a lot more so developers can hear your thought process.

Don't speak while the screen reader is speaking! It can be very overwhelming to hear both a screen reader and try to listen to your voice at the same time, especially for folks who don't use screen readers daily.

Detail out any gestures you are using, and if you perform any explore by touch gestures. This helps developers follow along and not get lost when focus suddenly jumps in the screen recording between elements that are nowhere near each other on the screen.

Turn Do Not Disturb on! Nothing is more frustrating than finishing up a recording only to get an embarrassing notification right at the last minute, or being interrupted by the same kind of notification just as you are detailing the issue you are trying to demonstrate.

Detail out your gestures if you are demonstrating Zoom/Magnification issues. Note that screen recordings may create bad audio feedback or static if you attempt to dictate into a text field while the recorder is on.

Android Screen Recording

Unlike iOS, Android's built-in screen recording software does not record TalkBack speech output. As of this writing, I have not found any other third-party apps that can pick up TalkBack directly from the system. The only current method is to open the screen recording settings and ensure that the audio capturing is on, and that only the Mic is set as the audio source. Then when recording, turn the accessibility/media volume all the way up.

The high volume allows the phone mic to pick up the TalkBack speech, but will also capture your voice and any other surrounding sounds. Note: the TalkBack volume has to be uncomfortably loud in order for the screen recorder to actually pick up the voice clearly.

Alternatively, you can use a document camera and mic to pick up TalkBack while recording to another device. I regularly used a document camera plugged into my Mac and set up to capture the full screen of my Android device to create evidentiary videos.

The more advanced way of capturing is through the Command Line. Installing android-developer-tools will put a little command line app called "scrcpy" on your system. This can be used to mirror the Android screen on your computer complete with the TalkBack speech output, and can also be used to create a direct screen recording with very clear TalkBack output. Highly recommended if at all possible.

scrcpy Documentation on Github

Zoom Meeting for One

Zoom can be used for direct screen captures when showing website, desktop, or even native mobile app issues.

Start your own meeting, share your screen and turn on Sound and video recording optimization, and then press record. The recording can be made locally or will get uploaded to the cloud depending on your Zoom version and setup.

Sharing your Sound allows for screen reader audio to get picked up in addition to your personal narration through your mic. By setting your iPhone screen to be shared through the advanced sharing options, you can focus on recording native mobile apps.

Note: Use the previously mentioned scrcpy command line tool to share an Android device screen on your desktop, then use the full screen sharing option in Zoom to capture that window.

Start the recording, switch over to your browser, demonstrate and narrate through the issue, then stop recording. If you need to show multiple issues, it's best to create a short video for each issue rather than one long video.

Once you are done recording, leave the meeting. If you've recorded locally, the video files will appear in the folder you have chosen in the Zoom Settings to receive downloads or screen recordings. If doing cloud recording, you will receive an email shortly after ending the meeting that will link you to a Zoom page where you can download the recording video files.

The video files will already be in the mp4 format, but depending on the length of the videos and how much motion there is in them, you may need to shrink the size of the video frame and compress the file into a smaller output. Handbrake is perfect for this.

Mac and Windows Screen Recording Options

If you don't want to use Zoom, MacOS QuickTime allows for full screen or app-specific screen captures, however these recordings will not pick up the VOiceOver speech output. QuickTime or the built-in screen recording methods allow for demonstrating non-audio based issues, so these options work well for keyboard or voice control issues.

Windows has the GameBar, which allows for full screen capture, but as of this writing I have not had the opportunity to use this. SnagIt is a third-party app that does screen recordings, but is not very accessible to Jaws or NVDA. Please email me if you happen to have other workable options for Windows screen capture and recording!

Keyboard and Other Assistive Tech Tips

When doing keyboard testing and demos, remember to speak the keys you are using. It's good to start off with the overall keyboard mantra to ensure that developers understand the correct keys to be using when doing their own testing or going through your repro steps:

When recording with other assistive tech, be sure to quickly detail anything that you haven't already put in your written descriptions, and quickly talk through what you will demonstrate, perform the task, then quickly explain what happened. Generally, you'll be giving a Too Long' Didn't Read version of your bug in your screen recording.

Compressing Your Videos

Be prepared to compress any videos you create when sending in feedback. Keep your videos relatively short and concise, just showing the issue and perhaps narrating a bit about what is going on. Leave the repro steps and expectations to the written part of your ticket.

Recording screens and apps isn't like recording direct video from a camera. The footage in a screen recording can compress really well when using an app like Handbrake for turning any video into an mp4.

Handbrake is accessible and useful for trimming clips, resizing, and exporting out to manageable mp4 videos, but use any compression tools you are comfortable with.

Handbrake, the Open Source Video Transcoder

Bringing it All Together - A Sample Ticket

Here is a sample bug written for a native mobile app for an airline. There is a very specific app with a very specific problem, and we want to highlight it with our feedback. putting everything in the POUR breakdown into practice.

We have a clear summary with an iOS tag to start it off (generally placed in the Summary text field for a feedback form), followed by a clear description of the problem, along with me disclosing my disability, the version of iOS, and the access technology I'm using.

We follow that with the repro steps in an enumerated list, then go into the overall expectations of what should be happening in this flow, and what is actually happening.

A Sample Bug from an Airline iOS App

[iOS] Unable to set To and From Airports when booking a flight

As a blind user using VoiceOver in iOS 26.0.1, I am unable to set the TO and From airports when trying to book a flight. Focusing on the To and From Airport controls and double-tapping activates a keyboard, but typing in my airport codes doesn't let me actually set my airports. Choosing them from the lists under the controls ends up either selecting the wrong airport or doesn't select one at all.

  1. With VoiceOver on, launch the app.
  2. From the top of the screen, swipe right with a single finger to move the VoiceOver cursor to the Book a Flight tab button, then double-tap to activate it.
  3. Swipe right on the Book a Flight screen until the From airport dropdown menu is focused. Double-tap to activate the dropdown.
  4. With the onscreen keyboard activated, type in SFO. Note that a list of Bay Area airports appears under the type-ahead dropdown's search field.
  5. Focus the cursor on the From airport text field, then swipe right to navigate down through the airports. Focus on SFO and double-tap it to choose it from the list.
  6. Note that SFO does not get chosen as the airport, and that focusing on the From airport dropdown again reveals that there is no airport selected as an accessibility value.

When using a type-ahead combobox or dropdown menu like this, I was expecting that typing in my airport code would automatically choose that specific airport and set it for my departure airport for my trip. Instead, it just gave me a list of Bay Area airports including SFO, and this option either sets itself to an incorrect departure airport when I double-tap SFO, or doesn't choose it at all. After thinking that I've chosen the correct airport and continued on with the Arrival airport and date process, I am unable to Find Flights since I keep getting an error saying that I have not chosen a From/Departure airport.

Remediation Recommendations

If you are already doing testing or are well-versed in WCAG and how to identify accessibility failures in HTML, offer suggestions to the developers on how to solve the issues. This can include providing code snippets copied out of the source code for the page or CSS selectors. If you feel comfortable modifying the code, such as showing proper Aria, alt text, or retooling inputs, write it out and offer it to them as a solution.

For native mobile, if you can identify the components or controls the developers are using, offer guidance based on the terminology from Apple's HIG or Google's Principles of Improving App Accessibility. Point out accessibility labels, values, roles/types, and hints/action descriptions.

For Web bugs

For Native Mobile apps

Recommending remediation can walk the fine line between knowledge via facts and assumption. Not being 100% sure of what is causing an issue can lead to misunderstandings and annoyed misled developers. Also recognize that it's not your job to fix their issues, only to point them out. Don't give up your time and effort for free, although I'll be the first to admit that I sometimes can't help but give them as much information as I'd give my own designers and developers just to kickstart them on their way into solving the issues. You do you!

My A11y Link List