Introduction to Web Accessibility

Kapitan HeneralKapitan Heneral
6 min read

I recently watched the introductory video from the accessibility course on Frontend Masters by Jon Kuperman, and one point really stuck with me: the web is one of the most open platforms we’ve ever created. I agree, the browser we're using right now interprets and renders content through open standards—HTML and CSS, maintained by the W3C, and JavaScript, standardized by TC39. The frameworks we rely on to build rich, interactive experiences—whether it’s Vue, React, Astro, or Laravel—are all open source, maintained by passionate communities who care about improving the web.

When websites and web tools are properly designed and coded, people with disabilities can use them. However, currently many sites and tools are developed with accessibility barriers that make them difficult or impossible for some people to use. Making the web accessible benefits individuals, businesses, and society. International web standards define what is needed for accessibility.

https://www.w3.org/WAI/fundamentals/accessibility-intro/

This quote from the W3C is a powerful reminder that openness alone isn’t enough. The web may be built on open technologies, but if we don’t design and code with care, we unintentionally close the door on millions of users. Accessibility isn’t just about making things usable for a few—it’s about fulfilling the promise of the web as a platform for everyone.

What is accessibility?

Accessibility, often written as a11y (with “11” representing the letters between "a" and "y"), is the practice of making websites usable for as many people as possible—especially those with disabilities. It ensures that people can perceive, understand, navigate, and interact with the web regardless of their abilities, devices, or environments. Disabilities can be permanent (like blindness or paralysis), temporary (such as a broken arm or recovering from eye surgery), or situational (like trying to read a screen in bright sunlight or holding a baby with one hand). Accessibility is about designing with all of these real-life situations in mind, so everyone can have equal access to content and functionality.

For example, a screen reader-friendly website helps someone who is blind (permanent) but also benefits a sighted user trying to listen to content while driving (situational). Keyboard-accessible navigation supports users with motor impairments (permanent) and someone whose trackpad just stopped working (temporary). Video captions are essential for deaf users (permanent), useful for someone recovering from an ear infection (temporary), and helpful for people watching a video in a noisy café (situational). These examples show that accessibility isn't just for a specific group—it’s for all of us, in different moments of our lives.

Who benefits from accessibility?

One interesting takeaway from Jon’s lesson is how accessibility benefits far more people than I initially realized. I used to think it was only for those with permanent disabilities—but now I understand it actually helps everyone, including people in temporary or even situational circumstances.

I learned that accessibility practices support four major categories: mobility and physical impairments, cognitive and neurological challenges, visual impairments, and hearing impairments. And what really clicked for me is how each of these categories includes people with permanent, temporary, and situational conditions. That blew my mind a little—because I realized I’ve been in some of these “situational” categories myself without even thinking of them as accessibility issues.

Mobility and Physical Impairments

I never really considered how difficult using a mouse or touchscreen could be for some people. I learned that this includes not just people with long-term conditions like cerebral palsy, but also someone who just had hand surgery or even someone like me, holding a coffee in one hand and trying to scroll with the other.

I now understand why component libraries like Radix UI, Reka UI, or Headless UI prioritize accessible tab ordering and ARIA roles out of the box—helping users who can’t or don’t use a mouse still navigate interfaces smoothly.

Cognitive and Neurological Challenges

Accessibility here isn’t just about readable fonts or clean design—it’s also about making the experience manageable for people who process information differently. I realized how hard it must be for someone with ADHD, dyslexia, epilepsy, autism, or even someone who’s just tired or overwhelmed.

What really stood out to me is how predictable layouts, clear labels, and the ability to pause or reduce animation can make a huge difference. For example, libraries like motion.js or auto-animate.js support the prefers-reduced-motion media query—which means if a user’s system is set to reduce motion (often to avoid dizziness, distraction, or seizures), the animations automatically tone down or disable themselves. No extra effort needed from the user or the developer.

This kind of support helps reduce cognitive load and sensory overwhelm—giving users more control and making digital spaces feel calmer, clearer, and safer to use.

Visual Impairments

I remember the day back in my college years when I proudly checked my first publicly published website. I was outside, squinting at the screen in bright sunlight—and guess what? I’ll be honest, I struggled to read the content because of the poor contrast.

Popular component libraries like Headless UI or Radix UI often come with built-in support for ARIA attributes and focus management. Components like modals, dropdowns, and tabs already include roles, labels, and keyboard navigation—all of which are critical for screen reader users who rely on structure and context, not just visuals, to understand what’s on the page.

This reminds me that accessibility for visual impairments isn’t just about making things “look” better—it’s about making content perceivable through multiple channels, whether that’s through contrast, semantic structure, or assistive technology.

Hearing Impairments

Honestly, I never used to think much about how a video without captions or a podcast without a transcript could completely exclude someone. I’ve definitely watched videos on mute during a commute or in a noisy environment—but for someone who’s Deaf or hard of hearing, missing captions isn’t just inconvenient; it’s a total barrier to understanding.

This made me realize that audio content should always be paired with text alternatives. Captions, transcripts, and visual cues aren’t just nice-to-haves—they’re essential for accessibility. Fortunately, powerful platforms are now helping us do better by default. For instance, YouTube and Loom offer auto-generated captions.

Accessibility isn’t just about compliance—it’s about communication. Everyone deserves to be included in the conversation.

Accessibility is Part of a Bigger Picture

One of the lessons Jon shared with us is that accessibility doesn’t live in isolation—it actually overlaps with a lot of other disciplines we already care about. When we build with empathy and intention, accessibility becomes a natural part of good web design.

  • Web Performance : A slow site isn’t just annoying—it can be outright inaccessible. Optimizing for speed helps everyone, especially users on slower networks, older devices.

  • Internationalization: People around the world access the web in different languages, reading directions, and cultural contexts.

  • UI/UX Design: Clean, consistent design isn’t just aesthetic—it reduces friction. For example, if a user with dyslexia tries to fill out a cluttered, poorly labeled form, they might get overwhelmed or frustrated and give up entirely but if that same form is well-structured, uses readable fonts, clear instructions, and helpful error messages, they’re more likely to get through it successfully—with less stress or confusion.

Takeaway

Honestly, even this early part of learning about accessibility has already made it feel so much more real and human to me. It’s no longer just about ticking boxes or coding to meet standards—it’s about designing with real people in mind, in real situations. That shift in perspective has completely changed how I think about the work I do.

The more I dive into this space, the more I realize how many barriers I had unknowingly created—and how many tools, patterns, and standards already exist to help us do better. These resources were built with empathy, inclusion, and long-term progress in mind (it’s not something you implement overnight.)

When we think about accessibility early and often, we don’t just make the web better for some—we make it better for everyone. Just like Jon said: the web is meant for everyone—so let’s make sure we build it that way. Start with empathy. Stay curious. Keep learning.

Sources

0
Subscribe to my newsletter

Read articles from Kapitan Heneral directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Kapitan Heneral
Kapitan Heneral

I am a front-end developer from the Philippines who loves to do open-source projects and engage with a community that also loves web development. I enjoy reading blogs and books to keep my knowledge up-to-date.