Dev.to

Develop Webapps for Everyone: A Guide to Web Accessibility

Introduction We all heard the term Web Accessibility when we started frontend development, but we often forgot to consider this while developing large scale apps. In this blog, let's talk about something that should be on all our radars but often gets pushed to the backburner: web accessibility. Why Accessibility Matters We've all been there—racing to meet deadlines, juggling feature requests, and trying to keep up with the latest framework updates. In that rush, accessibility can feel like "just another requirement" on a long checklist. But here's the truth: when we build sites that only work for people without disabilities, we're literally locking people out of the digital world we create. And the best part? Making your sites accessible isn't rocket science—it just requires a bit of intention and awareness. Let's Compare: The Good, The Bad, and The Inaccessible Example 1: Login Forms Here's what most developers do: Submit Looks fine visually, right? But imagine trying to use this with a screen reader. You'd hear something like "edit text... edit text... button." Not exactly helpful! Plus, once you start typing, those placeholder hints vanish into thin air. Here's how to make it work for everyone: Username Your unique login ID. Password Must be at least 8 characters. Log In What makes this better? Real labels that stick around, proper form semantics, and descriptive text for assistive technology users. Oh, and it still looks great for everyone! Example 2: Modal Dialogs That Don't Trap Users Modals are notoriously difficult to get right for keyboard users. Here's how to nail it: Subscribe to Newsletter Enter your email below to get updates. Email address Subscribe Close This modal: Announces itself as a dialog to screen readers Clearly describes its purpose Can be properly navigated with keyboard controls Maintains visual appeal with clean Tailwind styling (Pro tip: Don't forget to add JavaScript to trap focus inside the modal when it's open!) Example 3: Error Messages That Actually Help We've all been frustrated by vague error messages. Now imagine dealing with that while also using assistive technology: Email Please enter a valid email address. Here, we're not just showing an error—we're ensuring assistive technologies announce it properly. The role="alert" tells screen readers "hey, this is important!" while aria-invalid marks the field as problematic. Your Accessibility Toolbox Here are some ARIA attributes that'll make you look like an accessibility wizard: Attribute When to Use It role="button" When a div or span needs to act like a button aria-expanded="true/false" For dropdowns and accordions aria-live="polite" For content that updates dynamically aria-hidden="true" For purely decorative elements tabindex="0" To make non-interactive elements focusable tabindex="-1" For programmatic focus (like in modals) Test Your Work! Before you ship, take a few minutes to: Run Lighthouse in Chrome DevTools Install the axe DevTools extension Try navigating your site with just your keyboard Turn on VoiceOver (Mac) or NVDA (Windows) and see how it sounds Conclusion Here's the thing about accessibility: it's not extra work, it's just good development. When we build with everyone in mind from the start, we create better experiences for all users. The next time you're spinning up a new component, take a moment to add those semantic elements and ARIA attributes. If you like this blog and want to learn more about Frontend Development and Software Engineering, you can follow me on Dev.to.

Mar 30, 2025 - 18:17
 0
Develop Webapps for Everyone: A Guide to Web Accessibility

Introduction

We all heard the term Web Accessibility when we started frontend development, but we often forgot to consider this while developing large scale apps. In this blog, let's talk about something that should be on all our radars but often gets pushed to the backburner: web accessibility.

Why Accessibility Matters

We've all been there—racing to meet deadlines, juggling feature requests, and trying to keep up with the latest framework updates. In that rush, accessibility can feel like "just another requirement" on a long checklist.

But here's the truth: when we build sites that only work for people without disabilities, we're literally locking people out of the digital world we create. And the best part? Making your sites accessible isn't rocket science—it just requires a bit of intention and awareness.

Let's Compare: The Good, The Bad, and The Inaccessible

Example 1: Login Forms

Here's what most developers do:

 class="p-4 max-w-md mx-auto bg-white shadow-md rounded">
   type="text" placeholder="Username" class="block w-full mb-4 px-4 py-2 border rounded">
   type="password" placeholder="Password" class="block w-full mb-4 px-4 py-2 border rounded">
   class="bg-blue-500 text-white px-4 py-2 rounded">Submit

Looks fine visually, right? But imagine trying to use this with a screen reader. You'd hear something like "edit text... edit text... button." Not exactly helpful! Plus, once you start typing, those placeholder hints vanish into thin air.

Here's how to make it work for everyone:

 aria-label="Login Form" class="p-6 max-w-md mx-auto bg-white shadow-md rounded space-y-4" novalidate>
  

     for="username" class="block text-sm font-medium text-gray-700">Username
    
      id="username"
      name="username"
      type="text"
      required
      aria-required="true"
      aria-describedby="usernameHelp"
      class="mt-1 block w-full px-4 py-2 border border-gray-300 rounded focus:outline-none focus:ring-2 focus:ring-blue-500"
    >
     id="usernameHelp" class="mt-1 text-sm text-gray-500">Your unique login ID.
  


  

     for="password" class="block text-sm font-medium text-gray-700">Password
    
      id="password"
      name="password"
      type="password"
      required
      aria-required="true"
      aria-describedby="passwordHelp"
      class="mt-1 block w-full px-4 py-2 border border-gray-300 rounded focus:outline-none focus:ring-2 focus:ring-blue-500"
    >
     id="passwordHelp" class="mt-1 text-sm text-gray-500">Must be at least 8 characters.
  


  
    type="submit"
    aria-label="Log in to your account"
    class="w-full bg-blue-600 hover:bg-blue-700 text-white font-semibold py-2 px-4 rounded"
  >
    Log In

What makes this better? Real labels that stick around, proper form semantics, and descriptive text for assistive technology users. Oh, and it still looks great for everyone!

Example 2: Modal Dialogs That Don't Trap Users

Modals are notoriously difficult to get right for keyboard users. Here's how to nail it:


  role="dialog"
  aria-modal="true"
  aria-labelledby="modalTitle"
  aria-describedby="modalDesc"
  tabindex="-1"
  class="fixed inset-0 bg-black bg-opacity-50 flex items-center justify-center z-50"
>
   class="bg-white rounded-xl shadow-xl max-w-md w-full p-6">
     id="modalTitle" class="text-xl font-bold text-gray-800">Subscribe to Newsletter
     id="modalDesc" class="mt-2 text-gray-600">Enter your email below to get updates.

     for="email" class="block mt-4 text-sm font-medium text-gray-700">Email address
    
      id="email"
      type="email"
      class="mt-1 w-full px-4 py-2 border border-gray-300 rounded focus:outline-none focus:ring-2 focus:ring-blue-500"
    >

     class="flex justify-end gap-2 mt-6">
       class="bg-blue-600 text-white px-4 py-2 rounded hover:bg-blue-700">Subscribe
       aria-label="Close modal" class="text-gray-600 hover:underline">Close