Screen Reader Testing for Online Ballots: Complete Guide

A screen reader test tells you whether an online ballot can be completed independently. Follow the voter’s path from sign-in through selection, review, and confirmation. This guide shows election administrators how to find barriers before a live vote.

The objective is not to collect a generic accessibility statement. It is to confirm that the configured ballot, with its own contests, instructions, deadlines, and support links, can be completed privately and independently.

Why Screen Reader Testing Must Be Election-Specific

A platform may use accessible components and still present a difficult election. A race for three seats, a ranked-choice contest, a bilingual instruction, or an eligibility warning can change what a voter hears and how they move through the page. A test of a blank demonstration ballot will not expose those problems.

Test the experience voters will receive: invitation, sign-in, identity checks, ballot styles, review, confirmation, and support. Listen for whether a contest name arrives before candidate options, whether an option announces its selected state, and whether a voter can understand a selection limit without guessing.

The standard is meaningful access, not merely the absence of an obvious error. The W3C’s keyboard guidance says functionality should be operable through a keyboard interface; a screen reader test shows whether the actual voting flow is understandable. For state and local election offices, the Department of Justice’s Title II web rule guidance identifies WCAG 2.1 Level AA as the technical standard for covered web content and mobile apps, subject to its deadlines and limited exceptions. Private member organizations should not assume the rule applies to them, but the same test is sound risk control.

What a Successful Ballot Should Sound Like

When a voter enters a contest, the screen reader should make the contest’s purpose and selection rule clear before asking for a choice. A voter should hear the candidate or response, its control type, and whether it is selected. If a correction is required, the error needs to explain what happened and how to fix it.

Unexplained buttons, repeated labels, and vague “required” announcements create risk. A voter who cannot confirm a choice may abandon the ballot, submit an unintended undervote, or need help.

Use plain contest labels and native controls where possible. Then listen to the whole flow with the configured candidate names and ballot questions. A well-coded control does not solve a contest title that gives no context or an instruction that appears after the options.

A Seven-Step Screen Reader Ballot Test

Run this test after ballot configuration is substantially complete and again after any late content change. Use at least one common desktop screen-reader and browser combination, then add the mobile assistive technology most relevant to your voters. Record the version, browser, device, ballot style, tester, and result.

1. Start with the voter notice. Open the same notice or email link voters will receive. Confirm that the deadline, support contact, and voting link are understandable without an image or color cue.


2. Sign in without a mouse. Navigate authentication with keyboard commands only. Check that labels, errors, timeout notices, and recovery steps are announced in a useful order.


3. Enter each contest and listen first. Before selecting anything, listen for the contest name, number of permitted selections, and special instruction. Verify that headings make it possible to move between contests without losing context.


4. Mark, change, and clear a choice. Confirm that a selected state is announced. For multi-select or ranked contests, test the exact limit and the message received when a voter exceeds it.


5. Trigger an error on purpose. Leave a required contest incomplete or exceed a limit in the test environment. The ballot should identify the affected contest, explain the correction, and return focus to a useful place.


6. Review before submission. Confirm that every selected choice is announced accurately and that a voter can return to a specific contest without losing prior work or becoming unsure what changed.


7. Submit and document the outcome. Complete the test ballot, listen to the confirmation, and save a dated note. Document the control tested, result, and remediation, not simulated vote choices.

Have a second tester repeat the route. If the election includes multiple ballot styles, test each one. Accessibility cannot be inferred from a single easy contest.

Separate Product Defects From Election Setup Problems

When a test fails, classify the issue before deciding who owns it. That keeps the correction moving and leaves a clearer election record.

A passed vendor audit does not approve a configured ballot, and clear ballot wording does not repair a broken control. Bring the issue log into your election operations review. For a material barrier, correct it, repeat the affected test, and record the retest rather than relying on a verbal assurance.

Keep an Evidence File Before Voters Are Affected

Keep the test plan, device and software combinations, findings, fixes, retest dates, and final signoff. Screenshots or recordings can help explain an issue, but do not include a tester’s choices or personal information that is not needed for remediation.

The U.S. Election Assistance Commission notes that assistive technology is used throughout the election process, including screen readers at home. Support agents should help with navigation without requesting, viewing, or recording a voter’s choices. A live report needs an escalation path, documented decision, and privacy-preserving fallback where appropriate.

Frequently Asked Questions

Which screen readers should we test for an online ballot?

Start with common, platform-supported combinations. Many teams include a Windows desktop screen reader, VoiceOver on Apple devices, and a mobile test. Document the environments tested; one passing combination does not prove every setup behaves identically.

Can an automated accessibility scanner replace screen reader testing?

No. Automated tools can find many code-level issues, but they cannot judge whether a contest makes sense when read aloud, whether a selection limit is clear, or whether a voter can understand the review page. Use scans alongside a manual, task-based screen reader test.

What should support do if a voter reports a screen reader barrier?

Log the report, preserve ballot secrecy, and escalate it through a pre-approved process. Support can explain navigation or provide a documented alternate route, but should never ask the voter to disclose selections. Investigate whether the report signals a broader defect affecting other voters.

The Bottom Line

Screen reader testing is a rehearsal of the private, independent experience you are promising voters. When the real ballot is tested end to end, problems become specific enough to fix before they become a live-election incident.

If your team needs an outside review of ballot configuration, accessibility testing, and launch evidence, talk with Votem before you set final voting deadlines. A documented pre-launch review can protect voter access without compromising ballot secrecy.