Thoughts on accessibility

Recently, I have been thinking about website accessibility (a11y) even more than usual. I always have accessibility in mind but I only occasionally focus on it specifically. For example, a few months ago I reviewed our use of icon images on the website and hid them from screen readers.

On 23rd September 2020 all public websites in the UK will need to meet certain accessibility requirements and provide an accessibility statement. Over the next 6 months I’ll be focusing on a few specific areas of accessibility. My main concerns with our site, as it currently stands, are URL formatting and colour contrast.

Our site runs on WordPress and I am huge opponent of plugin bloat. The more plugins you have, the more potential attack vectors there are. I see countless 404 errors from malware scripts looking for (presumably) compromised plugin files. On that basis, anything I can do myself, I want to do myself. Therefore, I am definitely not a fan of these huge accessibility plugins that promise everything and the kitchen sink.

It’s also important to be aware that web browsers will take accessibility hints from the operating system. Remember that ,before a user with a visual impairment arrives at your website, they must already have their OS and browser configured in a way that facilitates that. The first step is to respect your users’ existing configurations.

One of the lowest hanging fruit, in this regard, is dark mode. Until recently, dark mode was only found in some mobile apps, usually those for reading. When everyone started  freaking out about “blue light,” night mode – warmer, less blue colorisation – was introduced at the OS level. Now dark mode is also readily available at the OS level too. I personally prefer dark mode on my portable devices and dark mode is an easy win for users with light sensitivity.

Into the dark

I’ve just completed a fairly length “feature sprint” where I added a whole bunch of new functionality to the site. While testing it on my iOS device I decided to switch on Dark Mode in Firefox OS. I was pleasantly surprised! Overall, it looked OK.

The immediate and obvious problem was our logo. Obviously our logo was designed with print in mind (we didn’t design it) so it looks best on a light background. In dark mode I could barely see it on the page.

Fortunately we have been supplied with “rev” versions that work on dark backgrounds too. With that hurdle cleared, how to find out when we’re in dark mode? Fortunately, “the internet” is way ahead of me, and prefers-color-scheme already exists.

prefers-color-scheme is a CSS media feature, so pretty easy to implement. This is a good introduction.

So, I added an “alternate logo” to our WordPress theme, added a new div containing the new brand image (our theme is bootstrap based), and set up the CSS media queries to alter the display property (this is not usually good practice).

I work with Firefox, and (to my knowledge) there is no dark mode on desktop without a plugin, so I went to my iOS device. I opened the page in Firefox and switched to dark mode and “boom,” there was my alt logo. Awesome. I turned off dark mode and… the “normal” logo didn’t come back. Huh. Obviously I started checking the code. It looked fine.

I decide to try and check it in Windows 10. Windows has had a “proper” dark mode since 2018. It worked fine. As I turned dark mode on and off in the Settings, Firefox swapped the logo back and forth. Perfect. So, why wasn’t it working on iOS?

TL;DR

Well, all the evidence was right in front of me.

prefers-color-scheme gets the color-scheme from the OS. On my iOS device, I had the OS itself in dark mode already when I tested the new logo. This is what actually caused the alternate logo to appear. Dark mode in Firefox itself can’t “toggle” prefers-color-scheme. Toggling the iOS dark mode on an off worked exactly as in Windows 10.

But…

This leaves a horribly fractured landscape. The Firefox iOS browser, has a dark mode that swaps out the pallette of the page for darker colours, but respects (as it should) the iOS color scheme preference. A user that has dark mode enabled in one place but not the other is going to have a poor experience.

This makes Firefox’s built-in dark mode next to useless. I’ll need to code up alternate CSS rules that respect prefers-color-scheme.

Dark mode, not such a low hanging fruit after all.

You’ve probably all seen this joke before. This tweet is the earliest mention I can find but please do correct me in the comments if you have an original source!

He’s making a list
And checking it twice
Gonna find out who’s naughty & nice
Santa Claus is… in breach of the Data Protection Act (1998)

— Larry the Cat (@Number10cat) December 22, 2016

There have been a few “take downs” of this joke but this one is probably the most thorough.

My take is that whether you are naughty or nice might be considered special category data and he needs specific consent to process that. He’s presumably collecting the naughty/nice data from elsewhere too, and doesn’t appear to notify anyone that he has obtained it. And I am sure he is making decisions using automated processing to which you haven’t been able to object.

But that is not why I am here today.

I am not a data protection “expert” but I reckon I know more than most. In the UK, the Information Commissioners Office (ICO) is responsible for enforcing the data protection rules. However, there must be thousands of insignificant breaches of the DPA everyday that the ICO will never hear about, let alone touch.

Personally, it makes me VERY cross when people misuse my data. I can’t take any legal action against them but I can name and shame them. So I am going to.

We have a lot of side responsibilities at the small NFP I work for. You know when you’re the only person that is good at doing something so you do it even if it’s not technically your job? That kind of thing.

I do a lot of the maintenance and “fiddling” with our WordPress website. I quite like it. Recently I have hit upon an extremely therapeutic activity: managed 404s.

We have a plugin to manage redirections for missing pages. I don’t exactly want to get to zero 404s but I do want to catch and redirect those I can to meaningful places. Even if it is a 410 response.

The really fun part is the plugin supports regular expressions. When I first started working with the plugin my efforts were limited to basic wildcard matches. Now I have even started with optional groups and substitutions. I’m by no means an expert but it is a great learning enviroment.

Today I have come up with a solution I am quite proud of. For some reason, our developer set the versions on our CSS and JS files to randomise occasionally. I assume this is for some sort of caching purposes. Anyway, this can generate some harmless 404s that I don’t want to be logged.

Using the regular expression 101 website I created this solution. Not much point explaining it here as the site does that very well. Any 404 that matches this pattern is excluded from the 404 logs, which helps me spot meaningful 404s much quicker.

Very pleased