WCAG Compliance Checklist for Election Websites: 2026

A WCAG compliance checklist for election websites should test the complete voter journey, not merely the homepage or an automated scan. Use this pre-election review to find barriers in notices, sign-in, ballot marking, submission, and support before voters are asked to participate.

The goal is practical: every eligible voter should be able to find election information, complete the required steps, and ask for help without surrendering privacy or independence.

Start with the rule and the voter journey

WCAG gives election teams a shared technical vocabulary. The W3C’s WCAG 2.2 Recommendation organizes accessible content around four principles: it must be perceivable, operable, understandable, and robust. Those principles are useful, but a successful election review has to go further. Voters do not experience a standard one criterion at a time. They experience a sequence.

For state and local public entities, the Department of Justice’s Title II web rule names WCAG 2.1 Level AA as the technical standard for covered web content and mobile apps. The Department’s 2026 interim rule set compliance dates of April 26, 2027 for covered entities serving 50,000 or more people and April 26, 2028 for smaller entities and special districts. Read the DOJ guidance closely with counsel.

Use this WCAG compliance checklist before polls open

Run the review after the final ballot, notices, credentials, and support procedures are configured. Ask testers to complete tasks as voters would, and keep a short record of the device, browser, assistive technology, result, and correction owner.

1. Check notices and public information. Make email links descriptive, provide accessible HTML alternatives for essential PDF content, use logical headings, and ensure contact information and deadlines remain readable at high zoom.


2. Test keyboard-only access. A voter should reach every control, see where focus is, operate the ballot, change a selection, and leave a component without becoming trapped. Test modals, help links, write-in fields, and error messages.


3. Test the screen-reader path. Verify that form fields have clear labels; contest headings, instructions, required states, and selected choices are announced; and status updates do not disappear silently.


4. Review contrast, resize, and reflow. Do not communicate a contest status or error by color alone. Check that text, controls, and instructions remain usable when voters enlarge text or use a narrow mobile screen.


5. Exercise authentication and recovery. Voters should be able to use a password manager or paste a credential where appropriate. Do not make a visual puzzle the only path into the election, and test lockout and session-recovery instructions.


6. Test the configured ballot. Candidate names, translations, multi-seat contests, ranked choices, amendments, and write-in rules can introduce barriers that a generic demonstration ballot never reveals.


7. Verify review, submission, and confirmation. Confirm that a voter can understand selections, return to an unanswered contest, submit only when intended, and receive an accessible indication of the next step.


8. Confirm the support route. Publish a reachable, accessible way to report a barrier during the voting window. Train support staff to help with access without asking voters to reveal selections.

Automated tools help locate code-level issues, but they do not prove that a voter understands a ranked ballot, can recover from a timed-out session, or knows whether a ballot was accepted. Treat scan results as evidence, not a release decision.

Test the ballot voters will actually see

A clean platform demo is not a final accessibility test. The risk arrives when election-specific material is added: a long office title, an uploaded candidate statement, a translated notice, a delegate-only contest, or a late ballot correction. Test the version that voters will use, with realistic voter tasks.

For example, ask a keyboard-only tester to open the notice, sign in, select and revise a choice, find the review screen, and submit. Ask a screen-reader user to locate a named contest, confirm the selected candidate, resolve an error, and reach support. Repeat the essentials on a mobile device and at increased zoom. When possible, include people who use the assistive technologies being evaluated. Their experience can reveal confusing language and workflow dead ends that an internal reviewer misses.

Also test privacy and independence. An accommodation process is not equivalent if the only option requires a voter to read choices aloud to a staff member. Support should remove the barrier while preserving the voter’s control of the ballot. That is why accessibility, authentication, voter support, and ballot secrecy must be tested together.

Votem’s online voting platform supports online, IVR, and mail workflows, but every election still needs a review of its own ballot, communications, and support plan.

Fix, retest, and keep a defensible record

When a barrier appears, capture enough detail for another person to reproduce it: the voter task, date, device or assistive technology, steps taken, expected result, actual result, severity, owner, fix date, and retest result. Save the election version that was tested. A brief record is more useful than a vague note saying that accessibility was reviewed.

Prioritize defects that prevent private, independent participation. A keyboard trap, an inaccessible sign-in step, an unlabeled selection state, or a confirmation screen that does not communicate whether a ballot was accepted deserves immediate attention. Lower-severity improvements matter too, but do not let them obscure a barrier that blocks the vote.

Set a change freeze before launch. If a candidate name, ballot question, notice, or login flow changes after the review, retest the affected journey. Keep test notes, remediation decisions, voter-support tickets, and final approvals with the election file after certification. This discipline makes the process easier to explain to a board, member, examiner, or counsel later.

For teams that need help coordinating configuration, voter support, monitoring, and the final record, Votem’s election operations services place those activities in one managed launch process.

Frequently Asked Questions

What does WCAG 2.1 Level AA mean for an election website?

It means the web content and functions meet the applicable Level A and AA success criteria in WCAG 2.1. For an election, the review should include notices, forms, authentication, ballot interactions, confirmations, and support paths, not just general information pages.

Is an automated accessibility scan enough for an online election?

No. Automated scans are useful for finding common errors, but they cannot reliably judge focus order, screen-reader clarity, cognitive load, ballot logic, or whether a voter can complete the full workflow independently.

When should an election website accessibility review happen?

Start during configuration and repeat the review after the final ballot and voter communications are loaded. Retest any material change to content, credentials, instructions, or voter flow before polls open.

How should a voter report an accessibility barrier?

Give voters a clear, accessible support route in the notice and on the election site. The team should document the report, respond promptly, protect ballot secrecy, and record any remediation or alternate access provided.

The Bottom Line

A WCAG compliance checklist for election websites is most useful when it follows a real voter from notice to confirmation. Test the configured election, correct the barriers that matter most, retest every material change, and retain the evidence with the election record.

If you are preparing an election and need an accessibility review that fits your ballot, timeline, and voter-support model, talk with Votem’s election compliance team before you finalize the launch calendar.