Design Practice
September 24, 2024 MyNaksh Editorial
Accessibility is frequently treated as the last step in a design process — the audit that happens after everything is built, when fixing problems is expensive and painful. This approach produces worse outcomes, higher costs, and products that exclude users who could otherwise benefit from them. The more effective model is to treat accessibility as a design constraint from the beginning, like color palette or typography.
Design tools have a significant role in how this plays out in practice. When accessibility features are integrated directly into the design environment — contrast checkers, semantic structure audits, focus order visualization — designers catch problems at the point where they are cheapest to fix: before a single line of code is written.
The most common accessibility workflow in digital product teams goes like this: design team finalizes mockups, developers build the product, QA runs an automated accessibility scan (typically using something like axe or Lighthouse), the scan returns a list of violations, and the team spends significant time backtracking to fix issues that should have been prevented in design. This cycle repeats on every release.
The problem isn't that QA accessibility checks are bad. They're necessary. The problem is that by the time automated scans run, many accessibility decisions have already been baked into the component library, the interaction patterns, and the information architecture. A scan can tell you that a button has insufficient color contrast, but it can't easily tell you that the navigation structure is cognitively overwhelming for users with attention or memory impairments, or that the touch targets on a mobile form are too small to use reliably with a tremor.
The Web Content Accessibility Guidelines (WCAG) 2.1 and 2.2 define success criteria at three levels — A, AA, and AAA. Most product teams target AA compliance, which covers the majority of issues that significantly impact usability for people with disabilities. But the 78 success criteria in WCAG span everything from color contrast ratios to keyboard navigation to cognitive load to time-limited interactions. Meeting them requires decisions that span design, development, and content strategy simultaneously.
Color contrast. WCAG 2.1 Success Criterion 1.4.3 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold) against its background. This seems straightforward until you start working with brand palettes designed for print or large-format display, where color relationships that look fine at poster scale fall below threshold on a mobile screen. Design tools that show contrast ratios in real time as you select colors prevent the downstream problem of a brand team delivering a palette with one or two colors that can't be used for body copy at accessible contrast levels.
Focus order and keyboard navigation. Approximately 26 million people in the United States have a disability that affects computer use. Many of these users navigate interfaces using keyboard alone, without a mouse or touchscreen. Focus order — the sequence in which interactive elements receive keyboard focus when the user presses Tab — is determined partly by the DOM order in the final code and partly by CSS positioning decisions that can disconnect visual order from logical order. Designers using tools that visualize focus order can identify problems (focus traps, illogical tab sequences, missing skip links) before they become implementation problems.
Touch target sizing. WCAG 2.5.5 (AAA) recommends minimum touch target sizes of 44x44 CSS pixels. WCAG 2.5.8 (AA in 2.2) requires minimum target spacing to prevent accidental activation. For mobile interfaces with dense information layouts, these requirements create real design tradeoffs that need to be resolved in design, not discovered during device testing.
Semantic structure. Headings, landmarks, lists, and form labels create the structural skeleton that screen readers use to navigate a page. A design that uses visual styling to convey hierarchy (large text for headings, spacing for sections, bold text for labels) without mapping to semantic HTML elements produces pages that are visually clear and structurally opaque to assistive technology. Design tools that support semantic annotation let designers communicate heading hierarchy and landmark regions to developers, reducing the gap between design intent and semantic implementation.
MyNaksh includes contrast ratio checking directly in the color picker — when you select a foreground color, the contrast ratio against the current background is displayed in real time, with pass/fail indicators for AA and AAA thresholds. When you select a text element, you can see at a glance whether the current color combination meets requirements for the current font size.
The platform's component library marks each component with its WCAG compliance status. Components that are conditionally compliant (pass at certain sizes or contrast settings, fail at others) display a warning indicator so designers know which configuration parameters matter for compliance. This prevents the common pattern of using a component in a technically non-compliant configuration without realizing it.
For teams doing detailed semantic annotation, MyNaksh supports design notes that export as structured metadata alongside design files. Developers receive landmark regions, heading levels, and ARIA attribute recommendations alongside the visual design, reducing interpretation ambiguity during implementation.
None of this replaces manual accessibility testing with real users who use assistive technology. Automated tools catch roughly 30-40% of WCAG violations, and design tool integration catches a subset of those at the design stage. The goal is to eliminate the entirely preventable violations — the contrast failures, the missing labels, the illogical focus sequences — so that manual testing time can be spent on the nuanced usability questions that tools can't evaluate.
Accessibility is frequently framed as a compliance requirement or ethical obligation. Both are valid reasons to prioritize it. But the business case is equally compelling and more persuasive in some organizational contexts. The population of users with disabilities is not small: the CDC estimates that 26% of US adults have some form of disability, and disability prevalence increases with age. Designing for accessibility extends the usable lifespan of digital products, particularly as the population ages.
Accessible design also tends to produce better design for everyone. Captions benefit people watching video in a noisy environment. High contrast benefits people using their phone in bright sunlight. Keyboard navigation benefits power users who prefer keyboard shortcuts. Touch target sizing benefits anyone using a phone one-handed on public transit. The improvements required for accessibility compliance overlap substantially with general usability improvements.
The earlier accessibility is addressed in the design process, the cheaper it is to get right. Research consistently shows that fixing an accessibility problem in design costs a fraction of fixing the same problem after development is complete, which in turn costs a fraction of fixing it in response to a legal complaint or regulatory audit. Design tools that make accessibility checking a natural part of the design workflow — not an external audit step — are investments in process efficiency as much as they are investments in inclusive design.