CandyWrite
HomeBlogs
CandyWrite

An independent publishing platform for essays on technology, design, and creative work. Free to read, free to write.

Explore

  • Home
  • All Blogs
  • Most Read
  • Most Liked

Get Updates

© 2026 CandyWrite Media Inc. All rights reserved.

Privacy PolicyTerms of Service
  1. Home
  2. Blogs
  3. Design
  4. Accessibility Is a Rendering Requirement, Not a Review Step
Design

Accessibility Is a Rendering Requirement, Not a Review Step

Audits find issues after they ship. Building accessibility into the primitives means most of those issues never get written, which is the only approach that scales.

M
Muhammad Umer

10 August 2026•2 min read

0 views
Accessibility Is a Rendering Requirement, Not a Review Step

The standard accessibility process is a periodic audit that produces a spreadsheet of violations, a sprint of remediation, and a slow drift back to the previous state. It is expensive, demoralising, and repeats indefinitely, because it treats accessibility as a property to be inspected rather than a property to be constructed.

Push it down the stack

Nearly every common violation can be prevented at the component level. A button primitive that always renders a real button element, forwards focus correctly, and requires an accessible name cannot produce a keyboard trap. A dialog primitive that manages focus and restores it on close cannot produce the most common modal failure. A form field that couples label and input structurally makes the unlabelled input impossible to write.

Build these once, correctly, and the failure surface shrinks to the code that bypasses them, which is a small and reviewable set.

The four checks that catch most of it

  1. Keyboard only. Unplug the mouse and complete your primary flow. Where you get stuck is where your users get stuck.
  2. Zoom to two hundred percent. Fixed heights and absolute positioning fail here, and it maps closely to how many people actually browse.
  3. Contrast on real content. Not the palette in isolation, but text over your actual imagery and states.
  4. Screen reader on one flow. Ten minutes with a screen reader teaches more than a hundred lint warnings.

The parts automation cannot see

Automated checks catch missing attributes. They do not catch a heading structure that makes no sense, alt text that says "image", an error message announced somewhere the user is not, or an interaction that technically works but requires forty tab presses. Those need a human, once, per significant flow, and that is a much smaller ask than an audit of the whole product.

The goal is not to pass a checklist. It is that a person using assistive technology can finish the same task in a comparable amount of time.

Making it stick

Add the keyboard check to your definition of done for any interactive work. Add contrast tokens to your design system so an inaccessible pairing is not expressible. Add one screen reader pass to release testing for your primary flows. This is roughly a day of setup and a few minutes per feature, against the recurring cost of the audit cycle you are running now.

On this page
M

Written by Muhammad Umer

@umarrafique923

Author and writer at CandyWrite. Sharing knowledge, tutorials, and reflections on technology, design, and ideas.

Enjoyed this perspective?

Join 12,000+ readers getting our Saturday morning editorial dispatch with our top essays and reading recommendations.

Related articles

Design

12 Aug 2026•3 min read

Design Systems Became Governance. Act Accordingly.

Design

9 Aug 2026•3 min read

Dark Mode Is a Colour System Problem, Not a Theme Toggle

Design

7 Aug 2026•3 min read

Prototype in the Medium: Why Static Mockups Keep Lying to You

Design

13 Aug 2026•3 min read

Calm Interfaces: Designing for Attention You Did Not Earn

Discussion (0)

Real-time updates enabled

Join the conversation. Sign in to leave a response or reply to comments.

Sign InCreate Account
No responses yet. Be the first to share your thoughts!