I've done a lot of tinkering and attempts at optimization on https://Brennan.day, and one of the foundational principles of the project was to be accessible from the start—making an accommodating website was not going to be an afterthought.

But what does that mean, exactly? I think it's good to actually write a blog post explaining that. An accessible starting point, if you will. Web accessibility (sometimes shortened to a11y^[1]) is "the practice of making your websites usable by as many people as possible." There is a wide range to consider here: visual impairments, hearing impairments, mobility impairments, cognitive impairments, and more.

I'll start off, though, with some of the most important things that I think beginner web developers don't hear enough.

Designing for Disability Means Designing for Everyone

Anytime you develop with accessibility in mind, or improve a product for someone with a disability, you're actually improving it for everyone. This is called the curb cut effect.

In the 1970s, disability activists in Berkeley, California, pushed for small ramps to be cut into sidewalk corners so that wheelchair users could move through their communities without being stopped every block by a four-inch drop. The ramps got built. And then? It turned out the curb cut helped everyone: Parents with hefty strollers. Delivery workers hauling hand trucks. Skateboarders. Tourists dragging rolling luggage through unfamiliar cities. A solution designed for a specific need became universal.

The same thing happens in digital design:

• Closed captions were created for people who are deaf or hard-of-hearing, and they're wonderful for anyone watching video on a crowded commute, in a noisy café, or late at night beside a sleeping partner.
• High-contrast text, originally designed to help people with low vision, makes your website more readable in bright sunlight.
• Voice controls, built for people with motor impairments, became the hands-free layer underneath Siri and smart speakers. Text-to-speech turned out to be useful for driving, for cooking, for holding a baby while you need both hands and still want to hear what's next.

The reason we audit our websites for how much contrast there is between text and background, or add ARIA landmarks, or ensure there's full keyboard navigation access, isn't to satisfy a checklist and be done with it. It isn't compliance theatre. It's about making it more readable for someone on a cracked phone screen, for someone borrowing a laptop without a mouse, for someone who just got their pupils dilated at the optometrist and is trying to read something waiting for the blur to clear.

This is about understanding how to make your words and work better understood by everyone, not just the able-bodied population. This is about meeting people where they are, no matter what.

Really, this is about connecting to humanity.

If you want to better understand disability and people with disabilities, I would recommend subscribing to Chris Ulmer's channel, Special Books for Special Kids. In addition to being one of the greatest YouTube channels around, SBSK is dedicated to "creating a more inclusive world" by interviewing people with disabilities from around the world "of all ages and diagnoses".

Disability Is More Normal Than You Think

If you wear glasses, you have impaired vision. That's a disability, and that's okay! The reason we rarely think of it that way is because the support infrastructure is widespread and robust. There's an optometrist in every city and frames at every drugstore for nine dollars.

Think about the accommodations that haven't been normalized yet. In web design, that's screens that can't be navigated without a mouse, or forms with no label text. The video with no captions. The button that's a styled <div> with no keyboard event, invisible to screen readers.

These are day-to-day encounters on the web for millions of people. Low-grade friction that compounds over every session, every tab, every attempt to participate in digital life.

According to the WHO, an estimated 1.3 billion people, roughly 1 in 6 of us, experience significant disability. In the United States, the CDC puts the figure at around 26% of adults. This is a growing number driven by aging populations and the rise of noncommunicable disease.

These are your readers, your users, the people who found your site from a search or a shared link and arrived hoping to read something you made.

Disability is also not always permanent, either. A broken arm means weeks without reliable fine motor control. Migraines with light sensitivity can make light, small text unbearable. Similarly, burnout and grief and exhaustion from long work shifts all can make dense, unstructured text become difficult to parse. Anybody, and most everyone, will eventually move through the world with reduced capacity in some domain.

My Own Website

I want to stress I'm certainly not an a11y expert, or someone with a major impairment myself (you can look at my disability page to get a better understanding of that). I am just someone who wants to create a more inclusive Internet for everyone. With that in mind, here's a look at what brennan.day actually does:

I use semantic HTML5 elements (<header>, <main>, <nav>, <footer>) to give my site a skeleton that screen readers can navigate. There's a "Skip to main content" link at the top of each page so keyboard users don't have to tab through the navigation every single time. Headings follow a logical hierarchy from h1 down to ensure the heading tree isn't a scattered field. ARIA landmarks identify the major page regions. Focus states are visible and styled. All text meets or exceeds WCAG 2.1 AA contrast ratios (4.5:1 for normal text, 3:1 for large text).

The site was tested using the WAVE Web Accessibility Evaluation Tool, and as of the most recent audit, it scores a 9.8 out of 10 on the AIM index, with zero errors and zero contrast errors. I resolved a longstanding issue where post graph links were generating "empty link" errors by adding aria-label attributes throughout. The scroll-to-top button was restyled for better visibility across both light and dark mode.

The Accessibility Issues That Must Not Be Named

There's a blog post on AppleVis which goes over the "Issues That Must Not Be Named," which go over other accessibility issues and the disability tax of common web design. One of these he calls Complexifuscation, when a page technically passes every accessibility checks but is still exhausting to use because it's built with so many nested elements and decorative wrappers and interstitial <div>s serving no semantic purpose, that screen reader navigation is frustrating.

Facebook, in his example, requires nine VO+Right Arrow keystrokes to get from a post heading to the actual text of the post.

Another pattern he describes is Screen Reader Agnosia, where developers who are unfamiliar with how screen reader software works then go ahead and build custom accessibility shortcuts, duplicating the already-existing native functionality. The result is more things to memorize and more deviation from the muscle memory that screen reader users have spent years building.

This is what automated tools aren't designed to map. Audits like WAVE are starting points, not ending points.

For beginner webdevs, there's visual feedback when you style with CSS that you don't when learning things like semantic HTML. Styling a <div> to look like a button seems completely innocent at first, for instance. Or when you remove a default focus outline because you haven't been informed it's the only way a keyboard user knows where they are on the page. Or when you pick an aesthetic colour palette that's cute, but low-contrast and difficult to read.

According to the 2025 WebAIM Million report, fixing these six categories of errors would resolve 96% of all accessibility errors across the web:

• low contrast text
• missing alt text
• missing form labels
• empty links
• empty buttons
• and missing document language

Inaccessibility and the Olympics

Bruce Maguire, a blind Australian, filed a complaint with the Human Rights and Equal Opportunity Commission arguing that the Sydney Olympic Games organizing committee violated Australia's Disability Discrimination Act of 1992 in three ways:

• by not providing ticketing information in braille,
• by not providing a braille souvenir programme,
• and by failing to maintain an accessible website.

Regarding the website complaint, the committee ordered to add alt text to images and image map links, fix the schedule navigation, and ensure results tables would be accessible during the Games themselves. SOCOG largely didn't comply, and the commissioner found in Maguire's favour. SOCOG was ordered to pay $20,000 AUD in compensation.

This happened in 2000. The W3C's Web Content Accessibility Guidelines were just a year old.

Twenty-six years later, WebAIM's annual survey of the top one million websites consistently finds that more than 95% of home pages have detectable WCAG failures.

What You Can Do

• Talk to people with disabilities and have them use your site. Automated tools can only catch so much. Real human beings can actually tell you what the experience of using your site is like.
• Run WAVE on every page of your site. Zero errors should be the start, not the end of your audit. Check every image for meaningful alt text. Check every form input for an associated label. Check every link for descriptive text. "Click here" tells a screen reader user nothing but "read my essay on web accessibility" tells them where they're going.
• Put your mouse away and navigate with only your keyboard. Tab through your whole site. Can you reach everything? Can you tell where you are? Is the focus indicator visible? Does anything trap you, like a dropdown you can enter but can't leave, or a modal with no keyboard-accessible close button?
• Use semantic HTML. A <button> is not the same as a styled <div onclick>. A <nav> is not the same as a <div class="nav">. Semantic elements carry meaning that assistive technologies can use and styled divs carry only visual appearance. Use headings in order, use lists for lists, etc.
• Check your contrast. The Colour Contrast Analyser and WebAIM's contrast checker are both great to use. The WCAG minimum is 4.5:1 for body text.
• Caption your media. If you embed video, caption it. If you embed audio, provide a transcript.

The W3C Web Accessibility Initiative maintains the authoritative documentation, and the A11y Project is a community-maintained, more approachable reference.

There is already so much of the world that isn't accommodating, whether that's public infrastructure and architecture, or product design, or the many hundreds of other things able-bodied people take for granted. Changing those things, if possible at all, takes years of advocacy and legislation and bureaucratic friction and money and people who are willing to be loud about it for a long time.

But your website? The one you own and run? That is something that can be made more accessible by you. You can take the time to learn and implement good practices that will make what you create more easily understood and shared to all. That's the whole point, isn't it?