Accessibility

Accessibility defines the baseline requirements for designing and building NayaOne applications that can be used by people of all abilities.

This page outlines the principles, standards, and practical guidelines that must be followed to ensure accessibility is considered by default — across UI components, layouts, content, and interactions.

Tip

While design system components include built-in accessibility support, accessibility is a shared responsibility and must be validated at the application and feature level.

WCAG compliance

NayaOne applications and design system components are required to conform to the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA.

WCAG defines testable success criteria for making web content more accessible to people with disabilities. Conformance at Level AA addresses the most common barriers related to vision, hearing, mobility, and cognition, and is widely recognized as the standard level for production web applications.

Accessibility conformance must be ensured across all supported devices, browsers, and assistive technologies.

References

• WCAG 2.1 Overview (W3C)

• WCAG 2.1 Quick Reference (W3C)

• Understanding Conformance (W3C)

Accessibility principles

The following principles define how accessibility must be applied when designing and building user interfaces in NayaOne applications.
They are aligned with WCAG guidance and established accessibility best practices.

Build consistent experiences

User interfaces must behave in a predictable and consistent manner across devices, platforms, and assistive technologies.

• Use design system components as the primary building blocks
• Apply the same components, patterns, and interactions for the same use cases
• Avoid introducing custom UI when an existing, accessible solution is available

Consistency reduces cognitive load and supports users who rely on learned interaction patterns.

References

• Consistency and standards — Nielsen Norman Group

• WCAG 3.2 — Predictable

Keep experiences and language simple

Interfaces and content must be clear, concise, and easy to understand.

• Avoid unnecessary steps, complex flows, and excessive interaction
• Reuse familiar patterns and layouts
• Use plain language and short sentences
• Target a reading level suitable for ages 12–14

Clear communication supports users with cognitive disabilities and improves usability for all users.

References

• Readable content — WCAG 3.1

Be inclusive

Accessible design must not assume user abilities, context, or background.

• Use inclusive and neutral language
• Avoid assumptions about vision, hearing, motor skills, or cognitive ability
• Avoid jargon, idioms, metaphors, and non-literal expressions where possible

Inclusive language and design reduce barriers for a wide range of users.

References

• Inclusive language guidelines (Microsoft)

Give users control

Users must be able to adjust the interface to suit their needs and preferences.

• Support content reflow across screen sizes and orientations
• Allow text resizing and browser zoom without loss of functionality
• Respect user system preferences, including reduced motion
• Inform users before high-impact or irreversible actions

Providing control supports accessibility across permanent, temporary, and situational disabilities.

References

• Reflow — WCAG 1.4.10

• prefers-reduced-motion (MDN)

Provide text alternatives

All non-text content must have a text alternative that serves an equivalent purpose.

• Provide visible and programmatically associated labels
• Write meaningful and descriptive alternative (alt) text for images and icons
• Provide captions and transcripts for audio and video content

Text alternatives enable access through screen readers, braille displays, and text-to-speech tools.

References

• Non-text content — WCAG 1.1.1

• Alt text guidance (WebAIM)

Ensure color is accessible

Color must not be used as the sole means of conveying information.

• Do not rely on color alone to communicate status or meaning
• Maintain minimum contrast ratios:
  • 4.5:1 for normal text
  • 3:1 for large text and UI components
• Use additional indicators such as text, icons, or patterns

Accessible color usage supports users with color vision deficiencies and low vision.

References

• Contrast minimum — WCAG 1.4.3

• Use of color — WCAG 1.4.1

Use semantic HTML

Semantic HTML must be used to provide meaning and structure to assistive technologies.

• Use native semantic elements such as header, nav, main, footer, button, and label
• Do not replace semantic elements with div or span
• Use ARIA only when native HTML does not provide the required semantics

Semantic markup improves compatibility with screen readers and other assistive technologies.

References

• Semantic HTML (MDN)

What to consider when building accessible apps

Users may experience permanent, temporary, or situational disabilities.
Applications must be designed to support a wide range of needs without optimizing for a single disability type.

Visual disabilities

Applications must support users with limited or no vision.

• Provide meaningful alternative text and semantic structure
• Ensure sufficient color contrast
• Avoid relying solely on visual cues

Examples

• Permanent: Blind
• Temporary: Migraine
• Situational: Lost glasses

Auditory disabilities

Information must not be conveyed through audio alone.

• Provide captions for video content
• Provide transcripts for audio content
• Avoid sound-only notifications

Examples

• Permanent: Deaf
• Temporary: Ear infection
• Situational: Noisy environment

References

• Audio and video accessibility (W3C)

Limited mobility

Applications must be operable without requiring precise or complex motor actions.

• Ensure full keyboard accessibility
• Provide sufficiently large interactive targets
• Use correct semantic controls for all interactions

Examples

• Permanent: Cerebral palsy
• Temporary: Broken wrist
• Situational: Holding an object

References

• Keyboard accessibility — WCAG 2.1.1

• Target size — WCAG 2.5.5

Cognitive disabilities

Interfaces must minimize cognitive load and support comprehension.

• Use plain, predictable language
• Structure content using headings, lists, and short paragraphs
• Keep navigation and flows simple and consistent

Examples

• Permanent: Dyslexia
• Temporary: Anxiety
• Situational: High cognitive load environment

References

• Cognitive accessibility (W3C)

• Minimizing cognitive load (NN/g)

Testing accessibility

Accessibility must be validated throughout the development lifecycle.

• Use automated accessibility testing tools
• Perform manual keyboard and screen reader testing
• Test across devices, browsers, and assistive technologies

Recommended tools

• axe-core

• Screen reader testing (WebAIM)