Accessible Voting Vendor Questions for Election Teams

Accessible voting vendor questions should go beyond whether a platform “meets WCAG.” You need to know how the vendor tests ballots, supports assistive technology, protects voter privacy, and documents issues before voting opens.

This guide gives election administrators a practical way to evaluate accessibility claims before signing, renewing, or approving a configured online ballot.

Why Vendor Claims Are Not Enough

A county clerk asked a simple procurement question: “If a blind voter calls support on election morning, what exactly happens?” The vendor had a polished accessibility statement, but no answer. That is the problem with treating accessibility as a certificate instead of an election process.

The Department of Justice’s ADA Title II web rule made WCAG 2.1 Level AA the required technical standard for state and local government web content and mobile apps. The compliance dates have shifted to April 26, 2027 for public entities with populations of 50,000 or more and April 26, 2028 for smaller entities and special districts, but the direction is clear. Election-related digital services are expected to be usable by voters with disabilities.

Even when your organization is not a public entity, the same risk appears in member elections, association elections, labor elections, and board elections. A voter who cannot read a ballot with a screen reader, reach a confirmation button by keyboard, or get private help has not received the same voting opportunity. If you are reviewing online voting software, ask for evidence that accessibility works in your election.

The Eight Questions to Ask Before You Buy

Good vendor review starts with direct questions. The goal is to learn whether accessibility is built into product design, ballot setup, support, and the final record.

1. What accessibility standard do you build and test against? The answer should identify WCAG 2.1 Level AA at minimum and explain how conformance is checked.
2. Do you test the configured ballot, not only the base platform? Candidate names, contest labels, instructions, and error messages can create barriers.
3. Which assistive technologies are included in testing? Ask about screen readers, keyboard navigation, zoom, mobile settings, and common operating systems.
4. How do voters get help without revealing their choices? Support must solve access problems while preserving ballot secrecy.
5. Can voters complete authentication accessibly? Login screens, one-time codes, timeouts, and CAPTCHA tools are common failure points.
6. How are language options and accessibility handled together? A translated ballot still needs proper structure, clear labels, and readable instructions.
7. What issue logs and test records will we receive? You need dated evidence, not just verbal assurance.
8. Who owns accessibility decisions during setup? Both teams should know who approves wording, ballot flow, notices, and support scripts.

If a vendor answers every question with “our platform is compliant,” keep pressing. Elections fail in details: a misleading instruction, an unlabeled confirmation control, a timeout during ballot review, or a help desk script that misses the real access issue.

What Evidence Should a Vendor Provide?

Strong accessibility review produces artifacts. They help your team decide before launch and defend the election afterward. Ask for evidence your election file can retain.

Automated scans can catch some problems, but they cannot tell you whether a voter understands the instructions or whether the review screen communicates intent. Manual review matters. Testing with the real ballot matters more.

How to Review Accessibility During Election Setup

Vendor review should continue after selection. Place accessibility checkpoints where you already review eligibility, ballot proofing, notices, and launch readiness.

Start with the voter journey. A voter may receive a notice, open a link, authenticate, choose a language, mark the ballot, review selections, cast the ballot, and save a receipt. Any step can break.

Next, test the ballot after final configuration. Use keyboard-only navigation from login through receipt. Listen with a screen reader. Increase text size. Try a mobile device. Check whether focus states are visible, error messages are specific, and confirmation language is clear.

Finally, rehearse support. A voter who encounters a barrier should not be told to “try again later” or to ask someone else to vote for them. Votem’s accessibility approach is built around the full election experience: platform behavior, ballot configuration, voter support, and records.

Common Red Flags in Accessibility Review

The first red flag is vagueness. If a vendor cannot say which WCAG version it uses, when it last tested the system, or who performs manual review, the program may be immature. Another warning sign is treating accessibility as an add-on. Access should be part of the default voting path.

Be careful with vendors that rely on PDFs, screenshots, or images of ballot content. Election information should be structured so assistive technology can read it in a sensible order. Also watch for inaccessible authentication. A secure process still needs labels, predictable timing, usable errors, and alternatives.

One more issue is poor documentation. If the vendor cannot provide test records, support procedures, or a post-election summary, your team may have no evidence when a board member, regulator, or voter asks what was done.

Frequently Asked Questions

What should I ask an online voting vendor about accessibility?

Ask which standard the platform follows, how configured ballots are tested, which assistive technologies are included, and what documentation you will receive. Also ask how support helps voters without seeing or influencing choices.

Is WCAG compliance enough for an election platform?

WCAG compliance is a necessary baseline, but it is not the whole election. You also need accessible notices, authentication, ballot wording, support, language options, audit records, and a tested path to receipt.

Who is responsible for accessibility if we use a vendor?

The vendor is responsible for accessible technology and services, but the election administrator still needs oversight. Your team approves ballot wording, voter notices, timelines, support procedures, and the final record.

When should accessibility testing happen?

Testing should happen before voter notices are finalized and again after the real ballot is configured. If a contest name, instruction, link, or support process changes after approval, retest the affected step.

The Bottom Line

The best accessible voting vendor questions are practical. They ask how a voter moves through the election, what happens when something goes wrong, and what evidence your team will have afterward.

If you are comparing vendors or preparing your first accessible online election, do not wait until ballot proofing to raise these issues. Contact Votem before you set final deadlines, and our team can help you review the accessibility, support, and compliance questions that should be answered before voters receive a link.