Any ideas? https://t.co/rhScGtLkmh
He also has his name on his uniform… https://t.co/oLcGX9FvFz
@ernest_marcinko just found that more than one instance of ASP on a page generates <polygon> with duplicate id “x-mark-icon”
Having said that, @twitter blue is worse than both…
Turns out that “Healthwatch pink” (hex E73E97) has a contrast ratio of 3.79:1 on a white background… I guess the company they paid for the branding didn’t have that in mind. Healthwatch green is even worse #a11y
In thrilling anticipation of September 23, today I have been looking at colour contrast on our website. All in all, was pretty good but there were a few surprises! #a11y
Wow. Barcelona has declared a climate emergency that gets straight to the point: "The current economic model is based on endless growth, consumption & a permanent race for profit. This economic system threatens the ecological balance of our planet & has multiplied inequalities."
Finally got the structured data on our website recognised by Google. Our average ratings and number of reviews are now showing in search results!
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. @media/prefers-color-scheme">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?
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.
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
Dark mode, not such a low hanging fruit after all.