Tags

I love dark mode, but it mustn’t be the only option. For a lot of people, white text upon a dark background is illegible.

Common eye conditions like astigmatism, myopia, and presbyopia can make content look foggy, become hard to focus on, and cause eye strain.

The above effect is especially exacerbated by strong contrast, like pure white on pure black. However, different conditions benefit from different levels of contrast. For example, people with conditions such as cataracts, aniridia, and achromatopsia can benefit from low-contrast visuals. The prefers-contrast CSS media feature is fantastic for tailoring to your user’s needs.

As a general rule, I don’t follow accounts or share content that neglect alt text. If someone seems open to growth, I usually try to contact them politely to explain the importance of alt text for accessibility.

I get varied responses. Some people thank me for cluing them in and make a change, and some people say they want to provide alt text but don’t know how (a good approach is to write like you’re describing something over the phone). Other people make the argument that people with disabilities don’t view their work, which is a common, lazy, ableist, and flawed claim made by people who don’t care about accessibility.

One argument that I adamantly dislike is: ‘I don’t put alt text on photos because it helps companies train AI’. At the core of this argument is prioritising inconveniencing AI companies over helping fellow humans – an ineffective attempt at sabotaging AI training by harming real people while doing virtually nothing to hinder AI corporations.

If training is your worry, consider that by omitting alt text, or worse, providing garbage, you are teaching AI systems and other people that alt text isn’t necessary and can be abused. Surely, at the end of the day, making things better for fellow humans is more important than making things insignificantly worse for AI systems?

Also, why risk publishing anything on the web if it is vulnerable to scraping? And why, specifically, draw the line at assistive technologies?

> Post about how bad accessibility overlays are on LinkedIn
> Get message notification
> ‘I saw your recent post, but our overlay is different. Check it out!’

🫥

Also, pro tip, if you’re trying to shill your overlay and prove that you’re different, don’t use the term ‘handicapped’.

Even pro-er tip: Just stop with the accessibility overlays. There is something seriously wrong with you if you think exploiting or jeopardising people with disabilities is an opportunity to make a quick buck.

Working on an article about accessibility overlays. Holy shit, fuck these companies and their deceit. I’m trawling through the waist-deep sludge that is their websites, and everything has this film of slime over it.

I knew they were bad, but I’d never looked that deeply into their marketing. Yuck.

I’m not usually this incensed, but accessibility overlay companies make my blood boil. How low do you have to be to go out of your way to exploit people with disabilities? Not only that, but to sabotage attempts to improve digital accessibility for all. Bottom-dwelling scabs.

I have a rouge instance of NVDA running somewhere because I continue to hear the dulcet tones of Windows OneCore whispering little somethings to me.

Can’t wait till one of those accessibility overlay providers decides to pivot to eugenics in their ever continuing effort to ‘fix’ accessibility without actually helping people with disabilities.

I see people say frequently that they don’t need to support older browsers because ‘everything auto-updates now’. This is a flawed assumption.

There are many reasons why someone might not have up-to-date browsers:

• Their device is too old. This is especially a problem with Apple devices, where the version of Safari is largely tied to the version of the OS.
• They never use their device long enough to trigger an update. I’ve previously had elderly tech-support clients who only used their computer sporadically for emails and banking and therefore didn’t receive updates because they weren’t using their computer long enough for new versions to install.
• They’re using a browser in an embedded context or on a ‘smart’ device, where there is no newer version available.
• Enterprise policies or restrictions don’t yet permit them to update their browser.
• They’re using a browser fork which lags behind in releases.
• They’re on slow/metered connections and have disabled background downloads to save money or bandwidth.
• Assistive technologies they require either lag behind in updates or aren’t supported in newer versions entirely.
• They’ve purposely disabled auto-updates for reasons of security.
• Interventions or censorship prevent them from reaching update servers.
• Their device doesn’t have the necessary storage capacity to perform an update.
• A device in a shared space like a library or school which doesn’t have the budget or capability to keep devices up-to-date.
• They’re running a portable browser from a USB or the like, which must be manually updated.
• They rely on a proxy-based browser which is outdated on the server-side.

You don’t need to support every browser version in perpetuity, but you should take a moment to consider that there are plenty of legitimate reasons folks won’t have the latest and greatest.

If you can, embrace progressive enhancement and graceful degradation.

Oh, making an accessible website is too complex for you to bother? Sounds like you aren’t very good at your job then, eh?

For as silly as I think it is, I think we should support people embracing accessibility technologies for the sake of AI agents by pointing them to the correct resources rather than pushing them away wholesale.

This is a chance to make a more accessible web, even if motivations are misguided.

I’d like to thank my superannuation fund for sending me an email full of images which all have the alt text ‘alt_text’.

Fun fact: If you write proper semantic code and don’t abstract everything with bloated frameworks, you don’t have to spend as much time faffing around with ARIA.

I find a significant observational correlation between people who post about AI and people who post without alt text.

Perhaps the real buttons are the divs we made along the way.

Just because ‘a picture means a thousand words’ doesn’t mean your alt text needs to be a thousand words long.

I see many social media posts including emojis and hashtags in sentences. This is inaccessible!

Screen readers read things out, and that includes your emojis.

For example, ‘I drink tea 🍵 from my teapot 🫖 to relax.’ might be read aloud as ‘I drink tea teacup without handle emoji from my teapot teapot emoji to relax.’

That is confusing and difficult to understand.

Instead, keep emojis to the start or end of your sentences. Like this: ‘I drink tea from my teapot to relax. 🫖’

Remember, the more accessible your posts are, the more people they can reach, which helps growth.

Hashtags are treated similarly but are also generally distracting mid-sentence. They’re best put at the end of posts.

If you can’t be bothered to write alt text for it, then it must not be worth posting in the first place.

I am unfortunately seeing a lot of stylised text on social media. They are horribly inaccessible. Don’t use them!

These aren’t actual fonts, merely a collection of Unicode characters.

For example, a screen reader will read 𝐁𝐨𝐥𝐝 𝐓𝐞𝐱𝐭 as: ‘Mathematical Bold Capital B Mathematical Bold Small O Mathematical Bold Small L Mathematical Bold Small D Mathematical Bold Capital T Mathematical Bold Small E Mathematical Bold Small X Mathematical Bold Small T’.

This isn’t an issue with screen readers – they’re performing exactly as they should. This is an issue with people misusing these characters.

If you need it phrased in a business sense, by excluding so many people who are trying to read what you’re writing, you’re limiting your reach and hurting your growth.

I think it is important that you make sure everything you publish on the web is equally accessible to all.

Thus, my content is unusable no matter your abilities. In fact, you might be better off with a screen reader because then at least you don’t have to look at it. Shit’s fucked.

I’ll be interested to see if there is a statistically notable uptick in clients reporting prefers-reduced-transparency as a result of Liquid Glass once iOS 26 releases.

Oh, look. Accessibility horrors beyond comprehension from Apple. A company with so much money the human mind boggles to comprehend it.

Accessibility horrors so blatant it takes one glance to identify many of the more offensive failings.

Accessibility horrors that are so inaccessible that even the completely able struggle.

Accessibility horrors that are covered in the very first class of any UI/UX design or front-end development education.

Accessibility horrors that you have to force through because even the worst testers are screaming at you.

Run this simple Vim substitute command to instantly improve your website’s codebase:

:%s/button/div/g

Carousels are a web staple. Websites use them, and thus people do in turn. They’ve garnered a lot of hate over the years, primarily due to being largely inaccessible and poor ways of presenting information, yet still they persist. So, if you can’t beat ‘em, join ‘em.

The Chrome team put together Carousels with CSS which Sara Soueidan has examined in extreme depth. My main takeaway from the main article and Sara’s analysis is that while this is a vague step in the correct direction, it doesn’t address any of the core issues like accessibility and introduces new ones. I was disappointed to see the approach taken in regard to addressing those issues and think Eric Eggert hit the nail on the head.

It completely fails with regard to separation of concerns by using CSS for structure, rather than HTML. I don’t know how to address that other than asking why? I’ve noticed a lot of new CSS features, especially ones with the Chrome team’s influence, are getting a little too markup-y for my liking. David Bushell has covered this and the over reliance of pseudo-elements with touchings on the carousel kerfuffle.

HTML is for structure, CSS is for styling, JS is for anything that can’t be achieved with HTML/CSS, and accessibility isn’t omittable. We should be striving to build a web that is both functional and inclusive. Respect the web; respect users.

As developers, our goal is to build something to be used. Part of this is ensuring it can be used by anyone and caters to everyone.

Accessibility isn’t a separate concept or goal. Making something more accessible for some people makes it better for all people, and that is our greater intent.

I found a website on the ground and completely inaccessible. Next to it? A bottle of ARIA. It must have taken too much and overdosed.

Kids, always use ARIA in moderation, and never ARIA on an empty semantic.

Sometimes I find myself wanting (or needing) to write about accessibility, but I shy away from it.

The negative impact of giving incorrect advice scares me away from giving any advice at all. I fear doing more harm than good.

If you ever feel useless, just be glad you aren’t the HTML title attribute as handled in accessibility contexts.

ARIA sure you need those roles and attributes?