Categories
development ux

The Dark Mode of usability and accessibility

I saw an interesting thread by Laurie Voss where he takes issue with the universal shift to Dark Mode across apps and platforms as an option. I’m sure it’s mainly a weary jest about all the effort to make something not for him. (After all, I’ve heard similar takes from white men about why bother spending time and money catering for women or people of colour).

This tweet stood out though and me think about how I conceptualise usability and accessibility :

‘Dark Mode is “totally useless mode” for me.’

I like dark mode for many reasons, there’s a small nostalgia element, but I do get big problems with eye strain. I started programming when we didn’t hook computers up to monitors, we used TVs, and sitting arms length from a bright flickering CRT is no good for anyone’s eyes. Modern LCD and OLED screens are much better (and I particularly like how well my Sony phone handles direct sunlight), but even then, I can get sore eyes and headaches looking at something too bright for too long. Dark mode allows me to use a screen longer without losing contrast. Although I am now more wary of wrist strain.

That’s how I often think of interfaces, as something which makes things easier. Something that reduces strain. And I sometimes forget that the point of accessibility cues is to make things possible. It’s not so I can stare at the screen for longer, it’s so that Laurie Voss has a screen where he can see the words.

So yes, I tag my images in Twitter. I use colour schemes with high contrast. I use structured HTML that ties inputs to their labels so that the accessibility tools have the best possible chance of doing their job.

So today, take a step back and think about what would make it impossible for a potential user to access what you’re building. Be that user. What do you need to add for them? If you’re not sure, enable the screen reader on your device and turn the screen over or off. Grab a screenshot and add a color-blindness filter. Fill out a form by voice, or use your onscreen keyboard to simulate a switch input.

How are you going to walk your software in someone else’s shoes today?

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.