Accessibility in UI Design — Palash Sarkar's Inclusive Design Approach

Palash Sarkar treats accessibility as a design requirement from the first wireframe, not an audit performed after a product is already built. That timing difference changes almost everything about how accessible the final product actually ends up being.

Contrast and Legibility as Non-Negotiables

Every text and interactive element gets checked against WCAG contrast standards during design, not left to be flagged in a post-launch audit. Palash Sarkar has found that designing with contrast requirements in mind from the start rarely constrains a design meaningfully — it mostly just prevents a category of avoidable failures from ever existing.

Designing for Keyboard and Screen Reader Navigation

A visually polished interface that can't be navigated without a mouse, or that a screen reader can't interpret coherently, excludes real users. Palash Sarkar considers logical tab order, meaningful alt text, and clear focus states as part of the actual interface design — not a separate technical implementation detail handled entirely by developers after design is finished.

Accessible Design Tends to Be Better Design for Everyone

Larger touch targets help users with motor impairments and also help anyone using a phone one-handed on a moving bus. Clear, high-contrast text helps users with low vision and also helps everyone reading a screen in bright sunlight. Palash Sarkar frames accessibility less as a special accommodation and more as good design discipline that happens to have specific, measurable standards.

Key Takeaways

Accessibility built in from the first wireframe costs far less — in both effort and quality tradeoffs — than accessibility retrofitted after launch. Palash Sarkar's approach treats inclusive design as core craft, not a compliance checkbox handled separately from the "real" design work.