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 :

I have extremely poor night vision (halos and starbursts around anything bright) so dark mode makes any interface that is primarily white on black unusable to me. So Dark Mode is "totally useless mode" for me.

— Laurie Voss (@seldo) April 15, 2019

‘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?

DRM and plastic knifes

I tried to do something I wasn't allowed to do but they refused to tell me what I'm not allowed to do.

I thought Digital Rights Management was dying when iTunes no longer required it. I was wrong. It’s sneaking into HTML, it’s in coffee machines, it’s being discussed for JPEG, it’s led to the introduction of boot lockers to prevent users from modifying the operating system on their machine.

So what? Surely copyright holders have the right to protect their content, no matter that the entire music industry could be bought out with Google or Apple’s spare change. Surely they need the money to support the poor struggling up and coming artists, who they can’t afford to pay from streaming revenues. Surely we should just let Hollywood have their way?

And anyway, doesn’t restricting operating systems and the software we can install protect us from the bad guys? Apple will keep us safe in their protected iOS and App Store, right?

When you restrict tools via drm, only the professionals can use the full tools, but where do the next professionals come from? We’re suffering from a shortage of people who want to learn to develop software, and we’re putting extra barriers in place, so that we need specialist devices for teaching development in the form of the Raspberry Pi and others, because the main machines we use are locked down and restricted.

Knives are dangerous and they can kill, so Scotland has restrictions on their sale and carrying them, but we still teach children to cook, sharp knives and tools for sharpening them are still widely available, and you don’t need to be a licenced chef to use a real knife.

If we can trust society enough that we don’t need plastic knives outside preschool, fast food vendors and cheap airlines, why can’t we trust them with access to a fully functional computer?

The Getting Better Moment

At the stroke of midnight, your code will turn into a pumpkin.

Inspired by The Getting Better Moment – You’ve Been Haacked , this is my story of my first job and a getting better moment.

During my summer break in university, back in 1999, my local council, who part funded my university education, back in the days before student loans, found me a placement at a local charity to develop a CPD database to track the exams their members took every year.

It was an Access database, installed on one machine on the network. With manual backups. It stored the pass/fail data in a set of bit fields in the database, requiring some complex sql to answer the common “who hasn’t done this course yet” mail merge query, it used VBA to parse those SQL queries into a screen full of check boxes to allow users to search.

None of that was my getting better moment though. I went from being a very shy geek at the start of the placement to a slightly less shy geek with a lot of confidence in my code. It was the first thing I’d written that was out in the real world and I was proud of it.

Until the first work day of 2000, when it stopped working. Despite the initial suspicions of the customer, it wasn’t a y2k bug. There was a bug in the end of year routine. What it was meant to do was create an empty exam results table for the new year, then rewrite the rest of the system to point to that table do that all the queries, screens and reports were up to date. It failed because it wasn’t properly tested. And I spent a whole day in their office, feeling sheepish, rebuilding the queries, screens and reports by hand to fix the mess.

But that wasn’t my big learning moment. That came exactly a year later, with another call, and another broken database. A lot of pressure now, trying to remember a fix from 12 months before on 18 month old code. It took longer than the first time, but I spent some time afterwards documenting the fix, testing the end of year rollover, and simplifying the code so I was capable of debugging it.

Luckily the customer was reasonably happy, as they didn’t run many exams in the first week of the year, and they understood you don’t get perfect solutions when you pay student placement wages, but I have tried hard since then to keep the customer happy and keep bugs that are fixed, fixed. All software has bugs in it, it’s how you deal with them, and the customer, that separates a professional from a beginner. The experience set me on the path towards TDD, open and honest communication, and not wanting to pick up support calls out of hours, which is a great motivator of quality. If you can lie on a beach, knowing you won’t get called because your code just broke, you’re doing it right.

What’s your getting better story?