Skip navigation

Re-Thinking the Accessibility Toolbar

Around 20 years ago, as my memory tells me, accessibility toolbars were all the rage. At the time, accessibility features in browsers were lacking, although I remember being very impressed with Opera Browser which could easily zoom a whole page in and out and recommended it to everyone who was vaguely interested.

Today, accessibility toolbars are frowned upon and rightly so. The traditional accessibility toolbar is used to switch on accessibility features, but shouldn’t accessibility be there by default? Yes it should. So how about we swap things around and have a toolbar that, instead of switching on necessary features, switches on nice-to-have-but-potentially-limiting features? Let’s give it a go...

Basic toolbar

First, let’s initiate a basic toolbar with JavaScript. It makes sense to do it this way so that we don’t have to worry about it not working if JavaScript is disabled. It would be particularly nice to have a single file that anyone could just plug in to his site and have it work so I’m going to set that as my goal. Of course, you could initiate the toolbar any number of ways, depending on what you’re most comfortable with. I’d rather keep my HTML and JavaScript separate, perhaps by using template literals, but I need to practice my JavaScript so I’m going to do it this way:

// Create an object to define the toolbar
const widgetToolbar = {
	font: {
		text: 'Toggle font'
	},
	contrast: {
		text: 'Toggle contrast'
	}
}

// create the toolbar wrapper
let toolbar = document.createElement('aside');
toolbar.setAttribute('id', 'acc-tools');

// Create a button from each object
for (let i in widgetToolbar) {
	let newItem = document.createElement('button');
	newItem.innerText = widgetToolbar[i].text;
	newItem.setAttribute('id', 'acc-' + i.toLowerCase());
	toolbar.append(newItem);
}

// Put the toolbar at the top of the page
document.body.prepend(toolbar);

I will leave you to style it how you like. Mine looks like this:

Horizontal toolbar with the two buttons described above

Font-switcher

For a long time it was thought that serif fonts are easier to read, but more recent studies indicate that sans-serif fonts are actually easier to read, especially for people with dyslexia. Personally, I much prefer serif fonts and remember Google’s switch away from a serif font in their logo. My gut reaction was that the new logo looked childish. This is why I usually default to Garamond or something similar - the current font-stack for this site is font-family: "Palatino Linotype", "Book Antiqua", Palatino, serif; - but my site is not for me alone, it’s for a world-wide audience, so I guess it is time to eat my own dog food and switch.

There, I did it! I’ve switched. Along with the accessibility defaults in my a-standard.css file I changed the font-stack to Verdana, Helvetica, sans-serif. Verdana is not a pretty font, but with the increased line-height, letter-spacing and word-spacing it’s no longer hideous. In fact I think it’s not at all bad. This serves as an acceptible and, importantly, accessible base design.

Now I want to be able to switch to a font that creates a better user experience for me personally. If you are better with fonts than I am and have a personal favourite Google Font, for example, then you could use that with the added benefit that your site has loaded much faster by using a system font by default.

/**
* Get button for switching fonts and add listener
*/
const fontButton = document.querySelector('#acc-font');
if (fontButton) {
	fontButton.addEventListener('click', () => {
		let font = '"Palatino Linotype", "Book Antiqua", Palatino, serif';
		if (document.body.style.fontFamily == font) {
			document.body.style.removeProperty('font-family');
		} else {
			document.body.style.fontFamily = font;
		}
	});
}

Et voilà! It works a treat. Next.

Colour & contrast

Contrast has always been a tricky issue. Firstly because we tend to find low-contrast more aesthetically pleasing, but it is usually a problem for accessibility. And secondly because each person’s needs are not only different but can even conflict with the next. Users with poor vision typically require high contrast, but this can be detrimental to users with Irlen syndrome for example, who may benefit from certain colours or colour combinations.

Now, we don’t want to give the user too much freedom to change the design of the page; this isn’t Myspace after all. So for this demo I’m just going to implement a dark theme.

Fortunately, I have already created a dark theme and put it in a prefers-color-scheme media query so I just need to make the contrast button toggle it on and off. Unfortunately, that cannot be toggled with JavaScript so I either have to duplicate the CSS or drop the media query if I don’t want this to get too complicated.

To clarify that: the default should be a high-contrast mode and the option will be to switch on a low-contrast dark mode. This is a bit of a risky move because I suspect web users might expect the dark mode to be the high contrast one, but I’m using the dark mode to double as a night-time mode where the user would be blinded by bright colours.

/**
* Get button for high contrast mode and add listener
*/
const contrastButton = document.querySelector('#acc-contrast');
if (contrastButton) {
	contrastButton.addEventListener('click', () => {
		document.body.classList.toggle('dark');
	});
}
body.dark {
	background-color: #001600;
	border-color: black;
	color: #090; }

.dark a {
	color: #ee0; }

.dark #logo {
	color: antiquewhite; }

/* etc. */

By dropping the media query and using the dark class, this works perfectly.

Informing users about their choices.

We could go on with other inventive features:

  1. a colour-picker for the background-color,
  2. sliders for a variable dyslexic font,
  3. and goodness knows what else,

but I think that’s enough for this demo. I’m sure you get the idea. Dark-themes have become very popular in recent years and, thanks to the prefers-color-scheme media query, we can help users have an experience more atuned to their preferences. But why not let the user decide? Personally, I prefer a light theme, but sometimes I find myself reading in a low light environment and then I change my mind.

Next steps

We could improve the user experience by using local storage to save the user’s preferences. And we really should track interactions with the toolbar and if it’s not used, throw it in the bin.