•
•
Devly Team
Sustainable & accessible Web Development
Web accessibility means that every person can use your website, regardless of ability, disability, device, or situation. That includes someone using a screen reader, someone navigating with only a keyboard, someone with low vision, or someone in bright sunlight trying to read their phone.
It's not an extra feature you bolt on at the end. It's a fundamental part of how the web was designed to work in the first place. The inventor of the World Wide Web, Tim Berners-Lee, said it best:
The power of the Web is in its universality. Access by everyone, regardless of disability, is an essential aspect.
Most developers think of accessibility as helping "people with disabilities." But it's far broader than that.
WCAG stands for Web Content Accessibility Guidelines. It's the international standard for web accessibility, maintained by the World Wide Web Consortium (W3C). When someone says "accessible website," they almost always mean WCAG compliant.
WCAG is organized into three levels of conformance:
WCAG organizes all its guidelines around four core principles. Everything you'll ever do for accessibility traces back to one of these:
This is the single most important thing you can do for accessibility. Semantic HTML means using the right HTML elements for their intended purpose, instead of using generic elements like divs for everything.
<!-- Bad: No meaning, screen readers see nothing useful -->
<div class="header">
<div class="nav">
<div class="nav-link">Home</div>
<div class="nav-link">About</div>
</div>
</div>
<div class="main">
<div class="title">Welcome</div>
<div class="content">This is my website.</div>
</div>
<!-- Good: Every element tells assistive tech what it is -->
<header>
<nav>
<a href="/">Home</a>
<a href="/about">About</a>
</nav>
</header>
<main>
<h1>Welcome</h1>
<p>This is my website.</p>
</main>Here are the key semantic elements you should know:
Every single interactive element on your website must be reachable and usable with only a keyboard. Many users; whether due to motor disabilities, power users, or assistive technology; rely entirely on the keyboard.
<!-- Bad: Only works with a mouse click -->
<div class="btn" onclick="submitForm()">Submit</div>
<!-- Good: Keyboard accessible, correct semantics -->
<button type="submit">Submit</button>The key rules:
/* Bad: Removing focus styles entirely */
button:focus {
outline: none;
}
/* Good: Custom but visible focus indicator */
button:focus-visible {
outline: 2px solid #5de8e2;
outline-offset: 2px;
}Every image on your website needs an alt attribute. This is one of the most basic and most commonly violated accessibility rules.
Alt text serves two purposes: it describes the image to screen readers, and it displays as fallback text if the image fails to load.
<!-- Bad: No alt text at all -->
<img src="chart.png">
<!-- Bad: Meaningless alt text -->
<img src="chart.png" alt="image">
<img src="chart.png" alt="IMG_4732.png">
<!-- Good: Descriptive alt text -->
<img src="chart.png" alt="Bar chart showing website carbon emissions dropping 60% after optimization">
<!-- Good: Decorative images use empty alt -->
<img src="decorative-divider.png" alt="">Color contrast is the difference in brightness between text and its background. If the contrast is too low, text becomes hard or impossible to read, especially for people with low vision, color blindness, or anyone in a bright environment.
WCAG AA requires:
/* Bad: Low contrast — fails WCAG AA */
.text {
color: #777777; /* gray text */
background-color: #ffffff; /* white background */
}
/* Contrast ratio: 4.48:1 — just below the 4.5:1 requirement */
/* Good: Sufficient contrast — passes WCAG AA */
.text {
color: #595959;
background-color: #ffffff;
}
/* Contrast ratio: 7.0:1 — well above the requirement */Forms are one of the most common accessibility failure points on the web. A form that looks fine visually can be completely broken for assistive technology users.
Every input needs a proper label. Every error needs to be clearly communicated. Every required field needs to be marked.
<!-- Bad: No label, no error handling -->
<input type="email" placeholder="Enter your email">
<!-- Good: Proper label, error handling, required marking -->
<div>
<label for="email">
Email address
<span aria-label="required">*</span>
</label>
<input
type="email"
id="email"
name="email"
required
aria-required="true"
aria-describedby="email-error"
>
<p id="email-error" role="alert" aria-live="polite">
Please enter a valid email address.
</p>
</div>ARIA stands for Accessible Rich Internet Applications. It's a set of attributes you can add to HTML to give assistive technologies extra information about your content.
But here's the critical rule: use native HTML first. ARIA is a last resort.
<!-- Bad: Using ARIA when native HTML already works -->
<div role="button" tabindex="0" aria-pressed="false">
Submit
</div>
<!-- Good: Native HTML does this automatically -->
<button type="submit">Submit</button>
<!-- Good: ARIA used correctly — native HTML can't do this -->
<div
role="dialog"
aria-modal="true"
aria-label="Confirm deletion"
>
<p>Are you sure you want to delete this item?</p>
<button>Cancel</button>
<button>Delete</button>
</div>You cannot rely on visual inspection alone to find accessibility issues. You need a combination of automated tools and manual testing.
Whether you're just starting to think about sustainability and accessibility or you're ready to overhaul your entire stack, there's a place for you here.
No spam. Unsubscribe anytime. Join 300+ developers.