Conducting Accessibility Research In An Inaccessible Ecosystem — Smashing Magazine

Prototype Testing Has an Accessibility Problem

UX research that includes disabled participants is essential for building inclusive technology, especially during prototyping when key design decisions are made. Yet there is a fundamental obstacle that is rarely addressed: the prototypes used in testing are often themselves inaccessible. This creates a paradox where the very research meant to improve accessibility is blocked by inaccessible research tools.

Excluding disabled users from feedback loops leads to technology that fails a significant portion of the population. Checklists and guidelines are not enough; direct input from disabled users is required to get accessibility right. But waiting for the ecosystem to become fully accessible before conducting this research means waiting indefinitely. Researchers must instead work with the tools available to create viable testing environments.

Note: Uses identity-first language (as in “disabled people”) rather than person-first language (as in “people with disabilities”). Identity-first language aligns with disability advocates who view disability as a human trait description or community, not a subject to be avoided or shamed.

Inclusive Prototype Phase Research

Accessibility-focused research is often deferred until after development, when the most accessible artifact exists to test against. But this approach has a critical flaw: significant design and feature decisions have already been made. The real opportunity to ensure an accessible and inclusive system is by assessing user needs at the start and then evaluating iterative prototypes along the way. This early-and-often approach is the best way to integrate accessibility into a process naturally.

When prototype testing includes participants with various disabilities, teams can make informed decisions before investing in significant development resources. These insights supplement accessibility guidelines with real-world feedback, allowing teams to incorporate key considerations thoughtfully in each iteration.

If disabled participants are only included near the end of a project, critical feedback leads to patchwork fixes, and less urgent issues get backlogged where they compete with new feature development. The team then remains in a cycle of catch-up rather than building accessibility in elegantly from the start.

The problem with treating accessibility as separate research

Accessibility testing is also too often treated as a distinct effort from what is viewed as the “main research” with users. This perceived separation reinforces a notion of disabled people as secondary participants whose needs are an adjunct to the core work rather than integral to it. That framing has negative consequences for how teams prioritize inclusive design and for the perceived value of disabled people’s perspectives, reinforcing ableist assumptions that devalue disabled people in society. UX research with diverse participants covering a wide range of disabilities can go a long way in dismantling those assumptions and creating vitally needed inclusive technology.

The difficulty lies in practice. Discovery research needs minimal tooling to gather qualitative insights, and summative research can leverage a nearly complete system. Prototype testing, however, sits in an awkward middle: high-fidelity enough to simulate interactions but not yet built with accessibility support.

The Prototype Tooling Gap

The technology used to design and test is itself broadly inaccessible. WebAIM’s Million report has consistently found that 96% of web homepages have accessibility errors that are fixable and preventable. Web and mobile application prototypes are no exception. The tools used to mock up an accessible final product are often not accessible themselves.

Figma: inadequate in key ways

Designers commonly prototype initial experiences in Figma. These files are a frequent artifact for prototype testing research. Improvements in the tool deserve recognition: significant work has gone into screen reader support and keyboard functionality within Figma prototypes, and this is progress worth noting. Still, limitations block inclusive research.

Properly created Figma prototypes mimic a final website layout and code, but that requires careful authoring. Elements must appear in the correct reading order in the Layers panel, icons styled to look like buttons must be actual button elements with labels, and images must include alternative text. Designers do not often build thinking about these requirements during iterative prototyping, so keyboard and screen reader navigation fails.

The tool does not support <select> configuration of visual adjustments: text zoom via browser capabilities, dark mode for ease of viewing, or selecting text so a screen reader can read it aloud. Participants needing these adjustments cannot depend on Figma prototypes during testing.

Getting the research done anyway

Prototype accessibility for research should not stall simply because the tooling is not perfect. A pragmatic path is to think beyond a single prototyping tool. Part of crafting any research study is deciding what artifact best supports its goals. If a Figma file from designers does not suit accessibility needs, the researcher should consider what other artifact can serve the purpose of the study to get the job done.

Five Ways to Test Prototypes Without an Accessible Prototype

Gathering feedback from disabled participants during the prototyping phase is achievable, even when the primary design artifact — a Figma file, for example — isn’t accessible. The key is to keep the research questions front and center and select methods that work with participants’ capabilities. Here are five practical strategies for conducting prototype research around inaccessible artifacts.

Run a Survey Instead

Not every research question at this stage requires a working prototype. Questions about general product features, content wording, or navigation logic can often be answered effectively with a survey. For instance, you can validate whether navigation options are intuitive by presenting a written scenario alongside a list of menu choices, or test content comprehension by asking users to describe their next steps after reading a passage.

Ensure the survey itself is WCAG-compliant, with accessible form layouts and question types so participants can navigate with assistive technology. Qualtrics offers an accessible form layout, and accessibility tips for Google Forms are available. If sharing a document, use built-in features like Microsoft Word’s ribbon styling to enhance accessibility.

Tip: Search for the product name plus “accessibility” to find official accessibility documentation for any software you use.

Conduct Co-design Sessions

Co-design and participatory design methods let you build prototypes with participants rather than presenting a finished artifact. You can co-create using any materials that match participants’ abilities and your research goals, from high-level workflow discussions to detailed visual design feedback. Use storyboards to illustrate scenarios, or present equivalent systems and mock-ups to guide the conversation.

The artifacts themselves can range from low- to high-fidelity. Participants without mobility or vision impairments might sketch with paper and pencil or use a whiteboard. Those with limited mobility may prefer a tablet-based drawing tool like an Apple Pencil with an iPad. Participants with visual impairments may engage better with three-dimensional materials — craft supplies, modeling clay, or cardboard. A collaborative online document can be the most accessible option, letting users work with their own assistive technology.

Offer a variety of feedback methods by default. This empowers participants to choose what works for them and signals that you’ve built an inclusive environment. When recruiting, ask participants whether the planned materials will be operable or what alternatives they prefer.

Facilitation depends on communication styles. Deaf participants may need sign language interpreters but can still view visual artifacts, while blind participants require verbal descriptions of key visual information. The study format ultimately follows who you recruit and what level of feedback you need; accommodations follow from there.

The author ran two co-design sessions while developing a wearable navigation device for blind pedestrians. Early on, participants worked with low-fidelity supplies — a Braille label maker, cardboard, clay, Velcro, clipboards, tape, paper, and pipe cleaners — and shaped a clipboard-and-pipe-cleaner prototype. Later, when discussing size and weight, the team taped together Arduino hardware pieces representing features participants had identified.

This approach yields unfiltered feedback that is participant-led and less influenced by the design team, which can lead to more thoughtful outcomes.

Test With an Equivalent System

Most projects build on existing inspiration. Instead of creating a prototype, test a live, similar system. Participants can use their assistive technology naturally, making the study more accessible and authentic. Findings can cover feature desirability, plus the accessibility and usability of individual page elements, informing your design and code decisions.

Before testing, check the existing system for accessibility barriers. Look for WCAG conformance documentation, run the system through WAVE, or simulate how participants will use it with their own assistive tech. For minor issues, work around them or guide participants past inaccessible sections — but if the system is unusable, choose another method.

If the site is workable, you can make real-time updates during sessions if you have engineering skills. Browser developer tools let you add, remove, or restyle elements live, bringing the test system closer to your team’s intended design.

Build a Rapid Website Prototype

Physical-device research doesn’t face the same accessibility roadblocks as web testing; you can prototype with cardboard, fabric, or 3D-printed materials, such as sewing haptic vibration modules into a leather bracelet. But for websites, a rapid prototype may be necessary to bypass inaccessible artifacts like an unformatted Figma file.

Choose a site builder with accessibility features. The author recommends WordPress, SquareSpace, Webflow, and Google Sites.

In one recent case, the author used Google Sites to replicate a client’s draft pages within hours. The agency’s Figma files weren’t formatted for screen reader use, so the author rebuilt the pages using a similar template, structured headings, recreated expected column and card layouts, and substituted placeholder images with projected alt text for the client’s custom graphics.

The screen reader session evolved into an impromptu co-design exercise, where changes to the live site could be tested and discussed immediately. This uncovered which headings were unnecessary and prompted detailed conversations about image alt text. The researcher relayed specific design and code feedback to the team and shared the prototype’s code for comparison.

The trade-off: the prototype wasn’t a 1-to-1 visual match, which skewed feedback from sighted disabled participants — including low vision and neurodiverse users — who wanted to evaluate colors, fonts, and wording but couldn’t make their typical visual adjustments. The prototype still sparked important discussions about what makes a page genuinely accessible for them.

Limits on design fidelity or developer help are common. When they arise, consider whether a pared-down version can still yield valuable feedback or whether no site at all would be better.

Use the Wizard of Oz Method

Wizard of Oz (WoZ) involves facilitators simulating a working system’s responses. You can approximate functionality using accessible tools and processes rather than building the full thing.

An Ally Financial research team applied this method for screen reader users. They pre-programmed screen reader prompts into a clickable spreadsheet and asked participants to speak the keyboard actions they would take. The facilitator then triggered the corresponding prompt — not ideal for either party, but it brought screen reader users into early design conversations. See their talk, “Removing bias with wizard of oz screen reader usability testing,” for details.

WoZ works beyond screen readers. The author used it for Voice User Interface (VUI) design while developing an Alexa skill. With the prototype unfinished, a Bluetooth speaker announced prompts from a clickable spreadsheet. Participants spoke commands to the speaker — believing it was Alexa — while the facilitator selected pre-recorded responses or a generic “I don’t understand” fallback.

Any system can be mimicked by breaking it into its interactions. WoZ setups require creativity and setup time, but the payoff can be significant, especially on longer projects. Once built, these prototypes can be edited and reused across studies. Most importantly, the investment pays off if it uncovers critical issues before the finished product is built — which is exactly the goal of this phase: helping teams know what to expect before the hard work of final development begins.

A Two-Front Push for Accessible Research

Simply asking product teams to consult accessibility guidelines before building is no longer enough. Direct user feedback — especially from disabled participants — is the only way to truly validate design decisions. Yet this creates a real dilemma: the prototypes available for testing are often themselves inaccessible, which means the test itself is compromised from the start.

Researchers are being told to be inclusive while being handed tools that are not. The solution is not to accept the limitation, but to push back on it — methodically, on two parallel tracks. First, make the research as effective as possible with what we have right now. Second, use that effort to advocate for the tools and resources that would make such research far easier in the future.

The primary objective is to get disabled perspectives into the decision-making record — not as a side note, but as a core part of the dataset that product teams rely on. Even when the testing conditions are not ideal, getting that feedback logged can shift the culture inside an organization. It helps turn “should we include disabled users?” into “how do we include them properly?” It also exposes, in concrete terms, the cost of inaccessible prototypes — a cost that is otherwise easy to ignore.

That visibility is what moves the second track forward. Once teams see what gets lost when prototypes cannot be used by everyone, the pressure to fix those barriers becomes organic. For some, that means pushing accessibility up the roadmap within their own organizations. For those at prototype tooling companies, it can become an argument for funding deeper work on accessibility features inside those products.

The larger ecosystem may feel too tangled to fix all at once. But the standard for research should not wait for the ecosystem to catch up. Disabled users are users first, and their perspectives cannot be deferred until the tools improve. The push has to happen now, on both fronts — even if it means doing imperfect research while demanding the tools to do it better.