WCAG 2.2 Target Size for Online Election Ballot Controls

Small ballot controls cause a practical accessibility failure: a voter knows what they want to select but cannot activate it reliably. WCAG 2.2 Target Size gives election teams a concrete way to review touch and pointer controls before launch. This guide explains the rule, where ballot flows fail, and how to test the controls that matter most.

Target size is not a visual polish item. On a crowded phone screen, a too-small selection circle, edit link, or submit button can turn an independent vote into a frustrating series of missed taps. For an election, that is a participation and confidence problem.

Why Target Size Matters in an Election

Voters do not interact with a ballot under laboratory conditions. They may be using a phone on a commute, a trackpad, a stylus, screen magnification, or an alternative pointer. When interactive targets sit tightly together, an accidental choice is easy to make and hard to notice.

Election consequences amplify the ordinary web-design risk. A missed tap may select the wrong candidate, send a voter back to the wrong contest, or make the final submit action feel uncertain. The right question is not whether a control looks large enough on a designer’s monitor. It is whether a voter can reliably choose, change, review, and submit on the actual device and ballot configuration.

That is why a usable online election platform still needs a ballot-specific review. Candidate names, contest formats, translations, write-in fields, and response options change the spacing and interaction pattern. Test the ballot voters will receive, not a tidy demonstration screen.

What WCAG 2.2 Actually Requires

WCAG 2.2 Success Criterion 2.5.8, Target Size (Minimum), is a Level AA criterion. For pointer inputs, the target must be at least 24 by 24 CSS pixels, unless an exception applies. An undersized target can also meet the criterion when surrounding spacing is sufficient: an imaginary 24-CSS-pixel circle centered on the target cannot overlap the circle for another undersized target.

The criterion also has limited exceptions, including inline links in running text, unmodified browser controls, equivalent controls on the same page, and situations where a particular presentation is essential. A tightly packed group of selectable candidates is precisely where a voter needs a more forgiving interaction.

Twenty-four pixels is a compliance floor, not a design aspiration. W3C’s guidance notes that larger targets help more people, and its enhanced Level AAA criterion uses 44 by 44 CSS pixels. For ballot actions, aim for a large clickable area around the visible control, especially for candidate selections, review-screen edits, and the final cast-ballot action. Verify the legal or policy standard that applies to your organization with counsel; WCAG guidance does not replace that review.

The Ballot Controls to Test First

Start with the places where a voter must make a precise choice. A radio button can be visually small while its associated candidate label provides a larger clickable target. That can work well, but only if the full label is truly operable and does not create an adjacent-target conflict.

Run the test with the longest candidate names, translated strings, and the smallest supported viewport. A target that works in a short, single-race proof can fail when a real multi-contest ballot wraps labels or brings choices closer together. The U.S. Election Assistance Commission’s digital accessibility resources cover the surrounding information and voter journey, not only the ballot screen.

A Practical Target-Size Check Before Launch

Build target-size testing into the final proof process, after the ballot and voter-facing content are configured. Election staff should perform task testing as well as a technical review. The two checks answer different questions: one tests the criterion; the other tests whether a voter can complete the action without repeated, risky attempts.

1. List every pointer action. Include links in the notice, sign-in recovery, every ballot choice, write-in activation, review edits, help, and submission.


2. Identify the actual target. Confirm the click or tap area in the rendered ballot, not merely the icon or text that appears interactive.


3. Measure and inspect spacing. Flag controls below 24 by 24 CSS pixels and closely packed targets. Treat any exception as a documented decision, not an assumption.


4. Test realistic voter tasks. On a phone and a desktop, ask testers to select, change, clear, review, and submit without zooming solely to make controls usable.


5. Record fixes and retests. Save the ballot version, device, browser, task, issue, owner, correction, and final result with the election file.

Give this check an owner. A managed election operations process should connect platform testing, ballot proofing, voter support, and the release decision. If a late change alters a candidate list, ballot question, or review screen, retest the affected controls before polls open.

Frequently Asked Questions

Does WCAG 2.2 require every ballot target to be 44 by 44 pixels?

No. Success Criterion 2.5.8 at Level AA generally sets a 24-by-24-CSS-pixel minimum or allows adequate spacing for undersized targets. Forty-four by 44 CSS pixels is associated with the enhanced Level AAA target-size criterion, but it is a sensible usability goal for high-stakes ballot actions.

Can a small radio button pass if the candidate name is clickable?

It can, if the full associated label is genuinely operable and the resulting target and spacing meet the criterion. Test the rendered ballot on a touch device. A visual design that appears to offer a large click area may not behave that way in practice.

Do target-size rules apply only to mobile phones?

No. The criterion concerns pointer inputs, so it benefits mouse, trackpad, stylus, and touch users. Mobile testing is especially useful because a narrow screen exposes crowded ballot controls quickly, but desktop interactions should be tested too.

Are automated accessibility scans enough to check target size?

No. A scan can identify some coded dimensions, but it cannot fully judge the configured ballot’s wrapping labels, adjacent choices, voter tasks, or the clarity of a review flow. Combine inspection with manual testing of the election that will actually open.

The Bottom Line

Target size is a small measurement with a large effect on voter independence. Treat 24 by 24 CSS pixels as the WCAG 2.2 Level AA baseline where the criterion applies, design generously for important ballot actions, and test the configured election on real devices before launch.

If your team is finalizing an online ballot, talk with Votem’s election compliance team before the release calendar closes. A focused review of ballot controls, voter support, and the launch record can prevent an avoidable barrier when the election is live.