WCAG compliance is a necessary condition. It is not a sufficient one.
Zoom’s accessibility documentation covers keyboard navigation, screen reader support, and captioning. Those features do not address what happens to slide semantics during screen share: participants experienced shared content as a flat image with no accessible structure.
The heading structure, reading order, and alt text built into a source file did not survive the share in practice. A screen reader could announce that sharing started. It could not read the slide.
Slide-based presentations are among the most common formats in professional, educational, and enterprise settings. If the live moment is inaccessible, the audit result is irrelevant to the people in the room.
Treat this as a live system problem, not a static compliance problem. The failure lives at the intersection of platform rendering, presenter behavior, and AT configuration, not in any single layer alone.
It changed the scope of what a fix could look like. Compliance patches one layer. Designing for live access requires all three to work in the same moment.
The moment where access breaks down is the format most professional meetings rely on.
Accessibility work tends to be evaluated at rest. A document can be checked. A PDF can be scored. Static criteria alone don’t capture whether access holds when content is moving and the presenter has already advanced the slide.
Losing access meant guessing at content never verbalized, waiting for chart descriptions that never came, and managing competing audio on top of the cognitive work of just being in the meeting.
When the workflow (join, share, present) removes access at the moment of live delivery, that belongs in the product brief, not an accessibility addendum.
The failure only shows up while the slides are moving.
Retrospective self-report would have missed the real-time failure modes. The breakdowns we needed to document happened in the platform, with AT running. The study had to match the conditions of actual use.
- Participants
- 3 BLV participants
2 Blind, 1 low-vision - Sessions
- 45 to 60 minutes, conducted over Zoom
- Assistive tech
- JAWS, OCR, screen magnification, text-to-speech, secondary-device screen recognition
-
01
Run the live presentation in Zoom, using each participant’s own setup.
Contextual inquiry, not retrospective interview. Failure modes only appeared while slides were advancing in real time. Participants used their own devices and AT; we needed the full stack running, not reconstructed.
-
02
Debrief immediately, while the experience was still fresh.
Immediate debriefs while experience was fresh let participants name what had just happened: where AT failed, what they inferred, what they were still waiting for. Recovery strategies go unspoken in retrospective accounts.
-
03
Code in two passes, then look for what survives variation.
Two researchers coded inquiry and interview recordings independently, then collapsed findings into one affinity structure. With n=3, we treated a finding as credible only when it appeared consistently across different AT configurations and participant roles.
The finding wasn’t “Zoom is inaccessible.” It was more specific: access broke during live slide presentations.
Seven coded themes collapsed into four failure points. With n=3, these aren’t generalizable. They held across different AT configurations, participant roles, and vision statuses.
-
01
Access ran through the presenter, not the platform.
When shared slides were unreadable through AT, presenter narration became the primary access path. Verbal transitions, slide-change signals, and chart descriptions determined whether participants could follow. Presenter behavior determined how much content passed through the platform.
-
02
Access depended on multi-layer AT setups that required constant management.
Participants combined tools rather than relying on one clean access path. One routed JAWS and OCR to separate ears; another ran a screen recognition app on a secondary device while listening live. These setups created access at the cost of split attention and real-time troubleshooting.
-
03
Accessible files did not produce accessible meetings.
Even when source files had proper heading structure, reading order, and alt text, participants couldn’t access those features through their AT during screen share. The compliance work was done. It didn’t survive the delivery method.
-
04
Advance materials changed what was possible in the meeting itself.
Advance materials changed the experience from decoding to following. Without them, participants leaned on narration and post-session review. Same meeting, fundamentally different access.
Design for live access, not just accessible artifacts.
Five design implications grounded in observed failure. Each maps to a specific breakdown point the research identified. These aren’t a product roadmap. They’re what the evidence points to.
-
01
Expose slide structure to AT during screen share.
Participants couldn’t access slide structure through their AT during screen share. Platform-level direction: expose heading hierarchy, reading order, and text blocks to screen readers during share. What presenters build into source files should survive delivery.
-
02
Build narration support directly into presenter view.
When platform-level access fails, presenter behavior becomes the primary interface. Presenter view should surface contextual prompts: describe this chart, signal this transition, announce this section. Verbal accessibility built in, not appended as an optional checklist.
-
03
Reduce competing audio streams.
The issue was not identical audio setups across participants. It was unmanaged competition between the live speaker and AT output. The design question is how a platform should manage competing audio streams during live delivery. That is a design problem, not an AT configuration problem.
-
04
Build advance material distribution into the meeting workflow.
Advance materials materially changed what participants could do in the meeting. This shouldn’t depend on whether a presenter thinks to send them. Meeting platforms should prompt hosts to share materials before the session, not rely on informal workarounds.
-
05
Evaluate access under live conditions, not just static criteria.
A presentation can be built with proper accessibility markup and still fail during live delivery, when slides are advancing and AT tools are competing for attention. The evaluation standard needs to match actual conditions: content in motion, real-time pressure.
Decision Impact
Before the study: the product question was whether Zoom is accessible. After: a specific, testable design target. Can a BLV user stay oriented when the presentation is moving and the presenter has already advanced the slide?
The question transfers to any live delivery context: enterprise tools, education platforms, AI narration. Can users access content in the moment the system is moving? That is a different standard than static compliance, and it requires a different kind of evaluation.
Expose slide structure during screen share. Add presenter narration prompts. Reduce competing audio streams during live delivery. Build advance material sharing into the meeting workflow.
Test whether a BLV participant can stay oriented while slides advance, the presenter keeps speaking, and their AT stack is running.
The system framing held. The next study needs messier conditions.
Keep: the system framing as a transferable analytical tool.
Naming the interaction between platform rendering, presenter habits, and AT configuration made the findings useful beyond this study. Any live, narrated, screen-shared environment has a similar three-layer structure. The framing transfers without pretending a small study generalizes to all of them.
Change: run the study in real meetings with higher information stakes.
A controlled scenario gave clean observations but underrepresents real failure. I’d add fast presenters, dense charts, and participants who cannot pause the room. A condition with an unprepared presenter would show how far the system breaks down when that fallback fails.