Show more

The challenges of implementing high contrast modes on the Web and in Drupal.
Pt 19

Problem is that the win is almost lost in the noise. The whole page takes 1.71s to load, and when I look at the the waterfall I see swathes of css files. 170 of them. Given that the page is simple, I assume all of the css files are being pulled in by that admin header.

But forgot password styling when there is only a log out option on screen (I'm logged in)?

Planning to investigate

The challenges of implementing high contrast modes on the Web and in Drupal.
Pt 18

I was worried that I was stopping Big Pipe from working by screwing up the outer static page wrapper. So I tested page load timings.

On a simple page with the admin toolbar is running, the difference between with Big Pipe and without for first load was around 8ms. 151ms compared to 159ms.

So whatever I'm doing to Big Pipe, I am still getting a win.

The challenges of implementing high contrast modes on the Web and in Drupal.
Pt 17

For those who haven't seen Big Pipe, it optimizes the assembly and load order to improve user perception of page load. It doesn't send the whole page in one go and that initial load is much smaller than it might otherwise be.

For my work, that means the initial <head> which won't cache well because of the programmatic css is small and the overhead caused by not caching is low.

The challenges of implementing high contrast modes on the Web and in Drupal.
Pt 16

Got great comments from @Kimitri, warning about the impact on downstream caching caused by how I render the page. Replying here to keep it in the numbered thread.

The comments made me think harder than I had about caching on Drupal with Big Pipe. There is a penalty in having each <head> made-to-order, but the impact on performance is likely to be mitigated by Big Pipe.

The challenges of implementing high contrast modes on the Web and in Drupal.
Pt 15

The disadvantage of my approach is that the contrast switch must be in the theme. There is no sensible way to have a module tweak a Twig template file.

The second disadvantage is having to maintain separate CSS files. I kind of prototype in style.css and export to the color files later but I have to have the discipline to do it.

On balance, I do find it worth the trouble.

The challenges of implementing high contrast modes on the Web and in Drupal.
Pt 14

The advantage of my approach is that I do maintain that Progressive Enhancement, and remove a dependency on JavaScript. This means that the worst thing that can happen is that the CSS arrives late but since that will cache it will only be the first page load of that contrast that pulls down a new CSS file. And that is a very small file with just color styling.

The challenges of implementing high contrast modes on the Web and in Drupal.
Pt 13

My approach is to define separate CSS files for each set of color options, say default, black on yellow, blue on cream.

Everything else is still in "style.css". I then use twig variables to pass the correct stylesheet selection to the html.html.twig template file. Those variables are created using PHP in my .theme file. So I'm choosing to make it part of my theme, not a module.

The challenges of implementing high contrast modes on the Web and in Drupal.
Pt 12

So, what to do?

One option is server side rendering, so that the correct CSS is applied To the DOM before being served to the browser but that's not where most web servers are just now.

My solution, and one I used on Drupal 7, is to emulate that server side behavior sufficiently that the site always gets the correct CSS on page load and does not rely on JavaScript at all.

The challenges of implementing high contrast modes on the Web and in Drupal.
Pt 11

To get that optimal first render, Big Pipe enforces Progressive Enhancement. Your site must both look good and operate correctly before the JavaScript is available. Chooing all of the colors on the page through JavaScript breaks that rule. In fact almost all of the features of Fluid UI's implementation break that rule.

Hence the flicker.

The challenges of implementing high contrast modes on the Web and in Drupal.
Pt 10

The flickering was one of the issues Mike's team tried to address, and Fluid UI was adjusted to try and mitigate the race Hazzard. Not eliminate but mitigate. Problem is that it can, and does, still flicker, especially if Big Pipe is enabled. Big Pipe optimzee page download to maximse the speed of page rendering and that demotes the loading of JavaScript.

m.facebook.com/notes/facebook-

The challenges of implementing high contrast modes on the Web and in Drupal.
Pt 9

Full disclosure: ithe Fluid UI module got its new Drupal maintainer and active state through one of my projects at CNIB.

I commissioned Open Concept, owned by Mike Gifford, the Drupal 8; accessibility maintainer, to get the module operating reliably in Drupal 8 with that work open sourced.

So my criticisms of it's implementation are ,technically, of my own promoted module.

The challenges of implementing high contrast modes on the Web and in Drupal.
Pt 8

I first noticed the problem on Fluid UI.

The Fluid Project originates from the Inclusive Design Research Centre here in Toronto and its goal is to provide a more inclusive web experience that considers a broader range of adaptation to user need than is usually found. Color contrast is one small part of that, and it is all based on adaptation by modifying the DOM through JavaScript.

The challenges of implementing high contrast modes on the Web and in Drupal.
Pt 7

The flicker occurs because it can take time for JavaScript to download and run so that the default CSS renders and displays first. How much this is a problem depends on the network, on caching, on how the JavaScript is associated with the page, and what external libraries the scripting relies upon and if you experience the problem, it appears to be amplified by use of Big Pipe.

The challenges of implementing high contrast modes on the Web and in Drupal.
Pt 6

That JavaScript solution is found in two Drupal modules that add contrast support to themes: accessibility toolkit, and Fluid UI (more of that module later).

Problem is that they both suffer from a fundamental flaw...there is a race hazzard between rendering of the regular colors and the JavaScript running AFTER A PAGE CHANGE OR RELOAD.

That race can cause a very nasty flicker.

The challenges of implementing high contrast modes on the Web and in Drupal.
Pt 5

The most common implementation of contrast switching on websites is using JavaScript to rip out backgrounds and alter colors.

There is a swatch or menu on the top line of every page, usually next to a text sizing option in what gets laughingly called the accessibility toolbar.

When the colour pairing selected, the script runs and a session cookie records the choice.

The challenges of implementing high contrast modes on the Web and in Drupal.
Pt 4

So, implementation. The first, hopefully obvious thing to say, is that if you need a particular color choice for a web page, then you also need it for the rest of your computer/phone UI. And this where the tool standards need to step in. Microsoft have had a fair stab with their high contrast mode but that's proprietary and doesn't work on mobile. So for now, web sites must step up.

The challenges of implementing high contrast modes on the Web and in Drupal.
Pt 3

We also think of WCAG success criteria as independent of each other. I'm not totally convinced that they are. For my MSc I studied the usage of cell phones by people with Multiple Sclerosis. These was back around 1998… and the most successful cellphone I tried had the smallest keys but backlit blue characters. Improving contrast appeared to improve kinaesthetic skills.

The challenges of implementing high contrast modes on the Web and in Drupal.
Pt 2

We also talk about high contrast as if it's something optional for our default colours. It's not. Think for a moment about where people access websites. Often it is on mobile devices that are being used in less than ideal lighting conditions. And the screens on cheaper devices are like the NTSC TV standard: never the same color twice.choose borderline AA and you fail in real life.

The challenges of implementing high contrast modes on the Web and in Drupal.
Pt 1

We talk about high contrast modes for websites and we probably shouldn't. What we usually mean is a range of color schemes to match user need and preference. And sometimes that's not the highest possible contrast (though still within WCAG AA requirements) Dark foreground + pastel background is often suggested for dyslexic users for example.

Visibility of skip-to-content links.

Is there any good reason for hiding this link unless it has focus? The sites I manage/influence always show it by default to support magnifier and head pointer users but I do realize I'm in the minority.

Show more
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either! We adhere to an adapted version of the TootCat Code of Conduct and have documented a list of blocked instances. Ash is the admin and is supported by Fuzzface, Brian!, and Daniel Glus as moderators. Hosting costs are largely covered by our generous supporters on Patreon – thanks for all the help!