Getting Real About Accessibility
A lot of accessibility talk sounds like marketing fluff. But the heart of the matter is pretty clear: accessibility (or a11y, if you want to save your keyboard) is about knocking down unnecessary barriers. It means people of all abilities—no matter if the difference is lifelong or just for the day—can show up, interact, and actually get something from your site.
The World Wide Web Consortium didn’t list accessibility as a “nice to have.” It’s central to the web’s original promise. The web is supposed to be for everyone.
In practical terms, that means users should be able to find your content, navigate your interface, understand what they’re looking at, and do all that with whatever device or assistive technology works for them. When you skip out on these principles, you’ll see the failures up close. Menus that don’t work without a mouse. Pages that confuse screen readers. The cracks appear fast.
Why “Edge Cases” Are a Myth
People still say, “Accessibility only impacts a small group.” That’s outdated, and honestly, it’s just wrong.
Sure—accessibility is fundamental for those with permanent disabilities. But it also matters for tons of other situations no one thinks about. Bright sunlight on a phone can make your low-contrast design unreadable. Someone juggling a coffee and a stroller may need to navigate with one hand on their phone. Slow connections and old devices force you to rethink bloated, complex interactions. Suddenly, accessibility is at the center—for everyone.
So stop treating accessibility as something “nice for special cases.” See it for what it really is: building sites that work even when everything isn’t perfect.
HTML: Still the MVP
Modern web development loves abstraction. Frameworks, components, clever state management—great tools, but too often people lose sight of the basics. Semantic HTML never stopped being powerful. It’s fast, reliable, easy to maintain, and it’s the secret to accessibility that doesn’t need special plugins. It just needs you to slow down and think.
Take a simple button, for example. You can use a styled <div> to fake it, but only an actual <button> is accessible out of the box—meaning it works right with keyboard and screen readers.
<div class="button" onclick="submitForm()">Submit</div>
<button type="submit">Submit</button>Replace <h1> headings with pretty <div>s, and you strip away the structure that helps people with assistive tech jump right to the important content.
It’s not about being fancy. It’s about being intentional—and disciplined enough not to over-engineer the basics.
<h1>Welcome to our site</h1>Images: Meaning Over Mechanics
Adding images isn’t hard. Making them accessible takes more than filling in a blank “alt” field. Too many developers drop in alt="image" and move on as if the job’s done. It’s not.
<img src="team.jpg" alt="image">The real question: what does this image do for the user? Does it show the team at work? Spell it out in the alt text—“Marketing team collaborating around a table with laptops and notes.” That lets users who can’t see the image understand what’s happening.
<img src="team.jpg" alt="The marketing team collaborating around a table with laptops and notes">But don’t get carried away. Decorative images—the ones that just provide a visual break—don’t need alt text at all. Give them an empty alt attribute (alt=""). That way, you’re not making users of screen readers listen to unhelpful noise.
It’s a subtle balance, but it changes how people experience your site.
<img src="divider.png" alt="">Keyboard Navigation: The Basic Test Most Sites Fail
Want a fast accessibility gut check? Put your mouse aside for five minutes and navigate your site with only the keyboard.
Can you reach every interactive element? Do you know where the focus is? Too often, focus outlines—the little boxes or lines that show where you are—have been removed for that slick “minimalist” look. It’s a visual upgrade for some, but a practical disaster for anyone using a keyboard.
The fix is simple: upgrade the visual style of focus indicators, but don’t remove them. Give them clear color and offset. Now users know exactly where they are as they move through your site.
:focus {
outline: none;
}Go further: dropdowns, pop-ups, custom controls—these all need to be fully operable by keyboard. Until they are, they’re just broken for a chunk of your audience.
:focus {
outline: 2px solid #005fcc;
outline-offset: 2px;
}ARIA: Supplement, Don’t Substitute
ARIA (Accessible Rich Internet Applications) attributes can be a lifesaver, but too many teams use them as a shortcut instead of a safety net. Here’s the rule—use plain HTML for structure and interaction first. Only reach for ARIA if you’re doing something truly custom that built-in elements can’t cover.
Example: A toggle button’s state. Sure, you could use aria-pressed to help screen readers understand what’s happening, but build your logic on top of an actual <button>. Don’t try to fake it with a div and a mish-mash of ARIA roles.
Overusing ARIA actually causes confusion. Stick to HTML for as long as you can—save ARIA for edge cases.
<button aria-pressed="false" onclick="toggle(this)">
Toggle menu
</button>
<script>
function toggle(button) {
const pressed = button.getAttribute("aria-pressed") === "true";
button.setAttribute("aria-pressed", !pressed);
}
</script>Building Accessible Umbraco 17 Projects
When you’re working in Umbraco, accessibility isn’t just a technical job. It’s about structuring content as well. You need to bake accessibility into your templates and components—don’t make it an afterthought.
Require editors to provide alt text for images. Build validation into the CMS. That way, mistakes are less likely to slip through the cracks.
Structure the content model so it’s not a free-for-all. Give editors blocks and tools that naturally produce organized, semantic content (clear headings, lists, etc.). It keeps things consistent, even as projects grow or new people join the team.
The more accessible components you create early, the less you’ll need to rebuild later. A tested, accessible module can power dozens of pages and features—saving you time and hassle down the road.
<img src="@Model.Value<IPublishedContent>("heroImage")?.Url()"
alt="@Model.Value<string>("heroImageAltText")" />Testing: Don’t Treat It As a Once-Over
Think of accessibility like security or performance: you’re never really “done.” Run automated tools—they’re handy for catching the low-hanging fruit—but don’t rely on them alone. Manual tests, especially keyboard checks and basic runs with screen readers, tell you what it actually feels like to use your site.
Even small manual tests often uncover weird issues: hidden navigation problems, confusing labels, unexpected behavior in dynamic widgets.
Constant iteration is the name of the game. Accessibility isn’t “done,” it’s always improving, sprint by sprint.
Retrofitting: The Hidden Budget Killer
Some teams punt accessibility until the last minute, thinking, “We’ll patch it in later.” That’s a fantasy.
Retrofitting is usually a disaster for the budget and timeline. You’ll slam into expensive rewrites, reconsider component structure, and wrestle with content workarounds. Stuff that would’ve taken five minutes early on snowballs into massive refactors later.
This is especially true in CMS-driven development. Early decisions stick around. If you set things up thoughtfully, you’ll save yourself countless reworks and lost time.
Wrapping It All Up
Here’s the simplest truth: accessibility isn’t just another box to tick. It’s a real test of whether your site can stand up in the real world. Accessible sites are more rugged, easier to update, and just plain nicer to use—for everyone.
Umbraco 17 puts a lot of power in your hands. The question isn’t whether the platform supports what you need—it does—but whether you treat accessibility as a core ingredient from the moment you get started.
If you do, you don’t just have an accessible site. You build something resilient, flexible, and future-proof—just like the web was always meant to be.