Checkbox Redesign

Checkboxes may seem simple, but they’re a critical part of user interaction in everything from surveys to to-do lists to game settings. Their simplicity is precisely why they need to be inclusive - when a component is used everywhere, it must work for everyone.

Thus, I chose to investigate the humble checkbox as implemented across three platforms: Google Forms, Microsoft To-Do, and the Hades settings menu. Each application had distinct use cases, audiences, and input methods, but all three showed various gaps in usability and accessibility.

This component redesign centers users who are often marginalized by mainstream interfaces:

• Keyboard-only users: Rely on visible focus indicators and logical tab order for navigation.
• Low-vision or cognitively impaired users: Need strong visual contrast, clear feedback, and predictable interaction patterns.
• Mobile users: Require large tap targets and optimization for touch.
• Everyone: Because accessibility improvements make interfaces faster, clearer, and more intuitive for all users!

I chose to investigate three platforms for my case study - Google Forms, Microsoft To-Do, and the video game Hades. These checkboxes are used in different contexts, making them ideal for comparing usability. Each checkbox was evaluated against core usability principles - learnability, memorability, efficiency - and tested for accessibility concerns.

Note: Each diagram represents a typical user flow from unchecked to checked. For concision, unchecking is not shown—imagine the arrows reversed.

These diagrams give a high-level overview of what each checkbox looks like. But to truly evaluate usability, we need to look at how users interact with them.

Checkbox Input & Output Comparison

The table below breaks down each application’s checkbox behavior across input types: mouse, keyboard, and touch.

Application	Strengths	Weaknesses	Accessibility Notes
Google Forms	Label and box both toggle selection → efficient Simple layout supports focus traversal Screen reader announces label + initial state	Enter key does nothing Hover feedback faint; label hover inactive No visual focus for keyboard users Keyboard can't go backward easily	Moderately accessible: Clear structure and decent screen reader support, but visual feedback and keyboard navigation need work.
Microsoft To-Do	Can tab into checkbox and label Space/Enter both toggle selection Visual + audio confirmation when checked	Only checkbox is clickable Focus order breaks after task text Reordering tasks is mouse-only No keyboard access to right-click menu	Least accessible: Small tap targets and broken keyboard navigation harm usability for motor- and screen reader users.
Hades Settings	Label + box clickable Strong visual/audio cues on hover & toggle Tooltip explains label (learnability) Mobile haptics reinforce feedback	Inconsistent arrow key navigation No visible keyboard focus Screen reader cannot detect component	Most accessible in multimodal feedback, but keyboard & screen reader support remain weak.

To improve learnability, memorability, and efficiency for all users, I redesigned the hover/focus state for one component - the Google Forms checkbox - to highlight the entire clickable area (not just the checkbox, but the label too). The original checkbox gave visual cues only when hovering over a small box, while the entire row was clickable - a mismatch that created uncertainty and excluded keyboard users.

My redesign expands visual focus indicators to the entire label + box area. This small shift improves clarity, touch precision, and keyboard navigation. When iterating through design choices, however, I realized that different design choices have different tradeoffs: as annotated in the above figure, we may sacrifice learnability for efficiency, or benefit one user group for another.

As a product manager, I’m prone to prioritize the big picture, but this project reminded me that small design flaws can carry big consequences. Ultimately, I think creating these small changes is a chance to better empathize with users, ensuring that we build systems that include and not exclude. In the future, I will apply these patterns to more complex, dynamic components, and continue to advocate for accessibility as a foundation in all product decisions.