Experimenting with better legibility for dyslexics

This morning, Heydon Pickering posted a link to an article detailing how special typefaces for dyslexics basically don’t work as expected.

Intrigued by this, as I have seen a few of these special typefaces and always wondered how they would help people with dyslexia, I had to read on. What caught my eye next was the proposed alternative to relying on special typefaces alone.

Is there anything that can be done through type to make reading easier for dyslexics? Yes. Studies have shown that dyslexics read up to 27% faster when text lines are very short, up to 18 characters per line, compared to the 60-65 characters of standard text. Putting as much space as possible between letters helps dyslexics too.

Sounds simple enough. With a bit of extra styling, this could be done easily, provided your front end code is up to snuff. Your front end code is up to snuff, right?

Using my own journal as an experiment

This is precisely why I keep a journal online; doing cool experiments (besides incoherent rambling, of course). With a few quick additions to my stylesheets and some quick and dirty hacking with JavaScript, I managed to quickly deploy a solution for my experiment. As per the article’s suggestion, I wanted to do a few simple things:

  • Decrease line width (i.e. fewer characters per line)
  • Increase letter spacing
  • Increase line height
  • Slightly increased font size

As one would expect, this wouldn’t require more than a few lines of extra code in the stylesheets. In addition, I also added some JavaScript to enable users to toggle the functionality.

The code

The basic concept involves just setting a modifier class to the <body> element. This would increase font-size, line-height and letter-spacing. In addition, the container for my content, .landmark-content as it is called, would have its width reduced in order to provide shorter lines of text.

/**
 * Dyslexic mode toggle
 */
.dyslexic-mode {
  font-size: 1.4em;
  letter-spacing: .25em;
  line-height: 2;
}
.dyslexic-mode .landmark-content {
  max-width: 26em;
}

I also added some quick styling for a <button> to be placed inside my banner region, to allow toggling of my dyslexics mode.

/* Toggle button */
.toggle-dyslexic-mode {
  font-size: .65em;
  margin-top: 0;
  position: absolute;
  top: 1.5em;
  right: 0;
}

JavaScript certainly isn’t my strongest skill, but I manage to get by. All we need to do in order to toggle our dyslexics mode is to toggle the modifier class on the <body>. To get a little progressive enhancement into the mix, I also added the toggle button with JavaScript. This of course means that if JavaScript is not available to the user, they can’t toggle the dyslexics mode. Then again, we won’t have a silly button in the banner region that does nothing.

/**
 * Toggle dyslexic mode
 */
function dyslexicMode() {

  // Place button inside role="banner"
  var toggleContainer = document.querySelector('[role="banner"] .landmark-content');

  // Create toggle button
  toggleContainer.insertAdjacentHTML('beforeend', '<button type="button" class="toggle-dyslexic-mode" data-text-original="Enable dyslexic mode" data-text-swap="Disable dyslexic mode">Enable dyslexic mode</button>');

  // Cache button selector
  var dyslexicButton = document.querySelector('.toggle-dyslexic-mode');

  // Function to toggle class and swap text on button
  function toggleDyslexicMode() {
    // Toggle the clas on <body>
    document.body.classList.toggle('dyslexic-mode');

    // Swap text on <button>
    if (dyslexicButton.getAttribute("data-text-swap") == dyslexicButton.innerHTML) {
      dyslexicButton.innerHTML = dyslexicButton.getAttribute("data-text-original");
    } else {
      dyslexicButton.setAttribute("data-text-original", dyslexicButton.innerHTML);
      dyslexicButton.innerHTML = dyslexicButton.getAttribute("data-text-swap");
    }
  }

  // Swap class & text on click
  dyslexicButton.addEventListener("click", toggleDyslexicMode, false);
}

dyslexicMode();

Note that I chose to do this with vanilla JavaScript, without any jQuery, because I really need to kick that awful habit of mine. As I said, this is pretty quick and dirty, so browser support is basically Internet Explorer 10 and up. Doing this with jQuery would likely be a few less lines of code (but then you’d also need to pull in the library). Since I employ the mustard cutting method for my journal, this code would never be run in legacy browsers anyway.

Taking this experiment further

Right now, users would need to toggle the function on each page visit. Nothing is being remembered, even within the same session. Hey, it’s a beta. Also, I’ve eyeballed the typographic tweaks and would need feedback from real people with dyslexia, in order to improve this or to even validate that this is something viable.

If you wish to give me feedback on this, feel free to hit me up on Twitter!

Update (2016-02-10): I’ve added two screenshots to showcase the difference between the two modes, should you have any issues toggling the looks of my own journal.

Pictured above: frippz.se without dyslexic mode
Pictured above: frippz.se with dyslexic mode

Update (2016-02-11): Kseso did an alternative solution using only HTML and CSS. While my current solution does use modern DOM API:s, it can pretty easily be adapted to support legacy browsers as well. Kseso’s solution relies on the :checked pseudo class, which limits the implementation possibilities a bit and won’t work in IE8 and below. Depending on your particular situation, this isn’t necessarily a problem.

Update (2016-11-11): As per this post, I’ve now disabled the toggle button on my own site and will be updating with a separate lab page to showcase the functionality.

Fixing blurry text on hardware accelerated elements

A customer project I was working on had the need for animated bubbles with text in them. They were used as information overlays and needed to move around smoothly. To accomplish this, all you need to do is apply transform: translate3d(0,0,0); to the element in question to enable hardware acceleration in most modern browsers. This, however, caused another issue; blurry text.

Doing a little bit of research revealed that for example Chrome and Safari transforms vector based text into textures when you apply translate3d, which in turn risks causing blurry text on the elements in question. The fix seems suspiciously simple.

.element-with-blurry-text {
  filter: blur(0);
}

This has appeared to have worked nicely in at least Safari 9 and Chrome 48. Some people have recommended to also add transform: translateY(0); as well, but I have been unable to confirm that this has any effect whatsoever. Your mileage may vary.

Using Homebrew ZSH instead of the OS X system default

As of OS X Yosemite, the built-in version of ZSH is 5.0.5. If you’re, like me, a fan of the latest and greatest, you might be tempted to use the Homebrew version of ZSH instead of the default system one. As of the writing of this post, the latest version of ZSH is 5.1. Here’s how you install and set it as the default shell.

This very short guide assumes that you’re already familiar with Homebrew and have it installed. Once that’s sorted, install ZSH.

$ brew install zsh

Edit /etc/shells to add a new entry for the Homebrew ZSH.

$ sudo vim /etc/shells

At the end of the file add /usr/local/bin/zsh, which is the path to the Homebrew binary for ZSH. Your /etc/shells should look like this:

# List of acceptable shells for chpass(1).
# Ftpd will not allow users to connect who are not using
# one of these shells.

/bin/bash
/bin/csh
/bin/ksh
/bin/sh
/bin/tcsh
/bin/zsh
/usr/local/bin/zsh

Now we need to set our Homebrew ZSH as the default shell.

$ chsh -s /usr/local/bin/zsh

Now open up a new terminal, and we’re done! Welcome to the bleeding edge of ZSH!

Muddying the waters of progressive enhancement

I did some work on a project for a client yesterday, where I was working on some specific JavaScript based functionality. By some weird chance, the JavaScript didn’t execute due to some weird error and nothing was showing up in the browser console. Later on it was found to be Webpack that didn’t build the file, hence no JavaScript. Anyway, this little event prompted me to post the following on Twitter:

Apparently, this just rubbed some people the wrong way.

Which is absolutely correct, which Christian Heilmann has pointed out very well. But you can’t always get everything you want into 140 characters. Then came the tweet that set off about an hour’s worth of what I’ve come to loathe; arguing over Twitter:

Needless to say, I disagreed with this. Not in full, mind you. You certainly can and should apply progressive enhancement to your JavaScript as well, but I really see little point in drawing your line there and call it a day. What ensued was a discussion on what progressive enhancement should mean. Or rather, what we thought it meant.

Back in 2008, Aaron Gustafson wrote for A List Apart on progressive enhancement.

Getting into the progressive enhancement mindset is quite simple: just think from the content out. The content forms the solid base on which you layer your style and interactivity. If you’re a candy fan, think of it as a Peanut M&M:

Start with your content peanut, marked up in rich, semantic (X)HTML. Coat that content with a layer of rich, creamy CSS. Finally, add JavaScript as the hard candy shell to make a wonderfully tasty treat (and keep it from melting in your hands).

This is a great description of what progressive enhancement is, and even if this article is coming up on being seven years old, I see no reason why this definition should change. The key here is the rock solid foundation; the content. You can’t base this on JavaScript and call this your baseline. Take away the JavaScript (which still happens all the time), and you’re left with an empty page. Not very rock solid.

I do realise that we’re drifting into the deep waters of semantics and that while Anders do have a point of sorts, that progressive enhancement can certainly be applied to just JavaScript, the underlying idea of a rock solid foundation goes out the window. What’s worse to me is the confusion this causes.

Imagine the following scenario, if you will. Developers express an intention to develop a web site using progressive enhancement. Jubilations all around!

Developer 1: ”Alright! We’re going to start with a rock solid foundation of semantic HTML, then we’ll add styling using CSS to carefully…”

Developer 2: ”Uh…”

Developer 1: ”What?”

Developer 2: ”That’s not what progressive enhancement is. We need to require JavaScript for this.”

I don’t know. Maybe the core problem is the semantics and like Jason Garber says: maybe we should just call it Responsible Web Design. While I don’t feel that core functionality without JavaScript is some kind of ”baggage”, maybe there’s a point to it. I just don’t feel that it is very responsible to scrape the icing off the layer cake and ignore the rest of the layers.

Maybe some developers are just plain lazy

In the wake of the news that Facebook has put out a new product that allows iPhone users to read news articles without leaving Facebook, several prominent characters on the web have put in their two cents on the matter.

Peter-Paul Koch was, as always, spot on:

The movement toward toolchains and ever more libraries to do ever less useful things has become hysterical, and with every day that passes I’m more happy with my 2006 decision to ignore tools and just carry on. Tools don’t solve problems any more, they have become the problem. There’s just too many of them and they all include an incredible amount of features that you don’t use on your site — but that users are still required to download and execute.

The trend is hard to miss. There’s an insane amount of tools and frameworks out there and using them is more the rule than the exception. PPK asks himself the question of why this is:

Why all these tools? I see two related reasons: emulating native, and the fact that people with a server-side background coming to JavaScript development take existing tools because they do not have the training to recognise their drawbacks. Thus, the average web site has become way overtooled, which exacts a price when it comes to speed.

While I absolutely do not disagree with his conclusions, sometimes the answer seem to be even more simple, and depressing. Based on what I’ve seen throughout my career as a front end web developer, the reason often is that developers are just plain lazy. With the advent of libraries and frameworks such as jQuery, Twitter Bootstrap, and not to mention the torrent of CSS preprocessors such as LESS and SASS, developers have not only become disconnected from how to properly build something for the web on their own, some of them have also turned horribly lazy.

First of all, let’s be clear about a few things. Just because you use a framework such as jQuery does not automatically make you lazy. Neither does the use of even Twitter Bootstrap. They all have their uses, and when used properly, they can save a developer loads of time. The problems start to come when you as a developer start to default to dropping in whatever framework comes to mind just because you couldn’t be bothered to give the problem at hand a few extra rounds of brain time. I’ve seen projects where hapless developers have thrown in jQuery UI (and I really mean everything that said framework has to offer including the kitchen sink) just to get a few tabs in their UI.

The same can be said for something like the CSS preprocessor SASS. While I personally are not very interested in their use and fail to see what good they are, they can be used responsibly, which of course is close to impossible since they open up for misuse at every turn. In either case, they can save a developer a lot of time, but often that comes at the cost overly bloated code instead. Not always, but very often.

Now, a lot of developers would surely scream bloody murder at me calling them lazy, citing insane product owners, psychotic project managers and ultra-tight deadlines as reasons for their use of all these frameworks. Maybe, maybe not. I believe, that just as frameworks and preprocessor tools open up for way too many ways to bloat you product, so does the aforementioned circumstances. They are all a source of stress for us as developers and it makes it damn hard not to fall into that trap of throwing tools at the problem.

The very uncomfortable truth might just be that you just lack the proper knowledge to effectively solve the problem at hand. Guess what, that’s totally fine. It happens all the time to most developers. No one is perfect and what really makes you a professional is what you choose to do when faced with such problems. Maybe take a step back, admit that you don’t have the right tools for the problem and that you need to aquire them before continuing.

The thing is that the tools I’m talking about can’t be downloaded as a zip file from some web site.