DEV Community

Cover image for Accessibility (a11y) in Modern Apps
AddWeb Solution Pvt Ltd profile image Vatsal Acharya
Vatsal Acharya for AddWeb Solution Pvt Ltd

Posted on

Accessibility (a11y) in Modern Apps

#a11y #react #frontend #webdev

“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.” - Tim Berners-Lee

Key Takeaways

  • Accessibility (a11y) ensures apps are usable by everyone, including people with disabilities
  • It improves UX, SEO, and performance, not just compliance
  • Modern apps must support keyboard navigation, screen readers, and visual adjustments
  • Ignoring accessibility leads to real business loss + legal risks
  • Accessibility is not a feature - it’s a foundation

Index

  1. What is Accessibility (a11y)?
  2. Why Accessibility Matters
  3. Types of Disabilities to Consider
  4. Core Principles (WCAG)
  5. Common Accessibility Mistakes
  6. Practical Implementation (Frontend + Backend)
  7. Tools for Testing Accessibility
  8. Real-World Examples
  9. Key Takeaways
  10. FAQs
  11. Conclusion

What is Accessibility (a11y)?

Accessibility (often shortened as a11y, because there are 11 letters between “a” and “y”) refers to designing applications that can be used by people with:

  • Visual impairments
  • Hearing impairments
  • Motor disabilities
  • Cognitive limitations

It ensures your app works with:

  • Screen readers
  • Keyboard-only navigation
  • Voice controls
  • Assistive technologies

Why Accessibility Matters

Most devs think: “My users don’t need this.”
That’s usually wrong.

1. Real Users Need It
Millions rely on assistive tech daily
Temporary disabilities (injuries, fatigue) also matter

2. Better UX for Everyone
Keyboard shortcuts = power users love it
Proper contrast = better readability for all

3. SEO Benefits
Semantic HTML improves indexing
Alt text improves image discoverability

4. Legal Compliance
Many countries enforce accessibility standards
Non-compliance can lead to lawsuits

Types of Disabilities to Consider

Visual

  • Blindness
  • Low vision
  • Color blindness

Hearing

  • Deafness
  • Hard of hearing

Motor

  • Limited hand movement
  • Cannot use a mouse

Cognitive

  • Dyslexia
  • ADHD
  • Memory issues

“The Web is fundamentally designed to work for all people, whatever their hardware, software, language, location, or ability.” - World Wide Web Consortium (W3C)

Core Principles (WCAG)

Accessibility is guided by WCAG (Web Content Accessibility Guidelines):

1. Perceivable

Users must be able to see/hear content
→ Example: Alt text for images

2. Operable

Users must be able to navigate
→ Example: Keyboard navigation

3. Understandable

Content must be clear and predictable

4. Robust

Works across devices and assistive tech

Common Accessibility Mistakes

  • Missing alt text on images
  • Using div instead of semantic tags (button, nav)
  • No keyboard navigation support
  • Poor color contrast
  • Forms without labels
  • Auto-playing videos without controls

Practical Implementation

1. Semantic HTML (Most Important)

<button>Submit</button> <!-- Correct -->
<div onclick="submit()">Submit</div> <!-- Wrong -->
Enter fullscreen mode Exit fullscreen mode

2. Alt Text for Images

<img src="product.jpg" alt="Red running shoes with white sole">
Enter fullscreen mode Exit fullscreen mode

3. Keyboard Accessibility
Ensure all interactive elements are reachable via Tab
Use :focus styles

button:focus {
outline: 2px solid blue;
}
Enter fullscreen mode Exit fullscreen mode

4. ARIA (Use Carefully)

<button aria-label="Close menu">X</button>
Enter fullscreen mode Exit fullscreen mode

Rule: Don’t use ARIA if native HTML can do the job

5. Forms Accessibility

<label for="email">Email</label>
<input id="email" type="email" />
Enter fullscreen mode Exit fullscreen mode

6. Color Contrast

  • Minimum ratio: 4.5:1
  • Avoid light gray text on white background

7. Screen Reader Support
Test using:

  • NVDA (Windows)
  • VoiceOver (Mac)

8. Accessibility in React

<button onClick={handleClick}>
 Submit
</button>
Enter fullscreen mode Exit fullscreen mode

Avoid:

<div onClick={handleClick}>
 Submit
</div>
Enter fullscreen mode Exit fullscreen mode

9. Accessibility in Laravel (Backend)

  • Validate meaningful error messages
  • Return proper status codes
  • Support localization (multi-language)

“Accessibility is not a feature, it is a social trend.” - Antonio Santos

Tools for Testing Accessibility

  • Lighthouse (Chrome DevTools)
  • axe DevTools
  • WAVE
  • Screen readers

Real-World Example

Imagine:

  • A user cannot use a mouse
  • Your app has no keyboard navigation

Your app is completely unusable
That’s not a “minor bug” - that’s total failure

Interesting Facts

  • Over 1 billion people live with some form of disability. Source
  • Accessibility improvements can increase conversion rates Source
  • Many accessibility fixes take less than 5 minutes
  • Around 40.9% of color combinations on major websites still fail WCAG contrast requirements. Source

FAQs

Q1: Is accessibility only for disabled users?
No - it improves usability for everyone.

Q2: Is ARIA enough?
No - proper HTML matters more.

Q3: Does accessibility slow development?
Initially yes, but saves time later.

“Designing for accessibility does not only benefit people with disabilities - it benefits everyone.” - Microsoft

Conclusion

Accessibility is not optional anymore.
Modern apps must be:

  • Inclusive
  • Usable
  • Compliant If your app isn’t accessible, it’s not truly “modern.”

About the Author:Vatsal is a web developer at AddWebSolution. Building web magic with Laravel, PHP, MySQL, Vue.js & more.

Top comments (0)