Heydon is a UX designer who prototypes and programs accessible interfaces. He has a love/hate relationship with CSS and a lust/indifference relationship with javascript. He's @heydonworks on Twitter.

Heydon's articles

  1. The Joy of Subsets: Crossbreeding Web Fonts

    95% of web design is typography. The remaining 5% is spent trying to fix infinite task runner recursion and swearing. However, when we say “web typography”, we rarely mean type design. Choosing, pairing and setting fonts are the more commonplace activities, with type design regarded as a more specialist and esoteric occupation.

    Accordingly, when I published my primer on “font hacking”, most of the interest was in the described way font subsets could be used in font stacks to mix and match character sets.

    [code language="css"]
    body {
    font-family: Punctuation Font, Alphanumeric Font, Fallback Font;
    }
    [/code]

    Unfortunately, actually ‘subsetting’ a font (reducing its intrinsic character set to just those characters you wish to render) requires the use of font design software that is one of eye-wateringly expensive, not available on your platform or liable to fill your swearing quota within moments of the wretched thing’s installation.

    Until now. Thanks to “one weird trick” I discovered using Google Fonts, I can now offer you a way to be inventive with subsets without the need to deconstruct those fonts manually. It’s all about Google Fonts’ URL text parameter.

    J A V A S C R I P T

    No, JavaScript is not required to achieve this (I wouldn’t do that to you). I’m talking about the string javascript. For the redesign of the Neontribe website, I decided to use the burgeoningly popular Ghost blogging platform, which is built on JavaScript. Since I’m a bit of a wag, I thought it would be fun to advertise this fact rendering the term ‘JavaScript’ in a ghoulish font. You see?

    Created by JavaScript written in a halloween font

    Now, I appreciate this isn’t a very good joke — if you can even call it a joke. What would make it even less funny, though, would be if I were to fetch a whole 150-or-more-characters font just for this discreet instance of typographical whimsy.

    Instead, I did this:

    [code language="html"]

    [/code]

    Note the aforementioned text parameter. This tells Google Fonts that you’re only interested in the supplied set of characters. It prompts Google to dynamically build a subsetted version of the Creepster font and send it to me. Note the kit parameter below.

  2. Learning to focus()

    Thanks to good fortune, I have a functional pair of eyes. When it comes to traversing web pages, this is something of a boon since shifting my focus from one part of the page to another requires nothing more than semi-consciously contracting my extraocular muscles and rotating my eyeballs a fraction of their circumference.

    Though my visual — and, therefore, cognitive — focus could now be said to have changed, the user interface itself does not know my attention has turned. At least, not until I begin to physically interact with the newly scrutinized region. To put it another way, rotating my eyeballs is an unrecorded event.

    Herein lies a very common but frequently unaddressed accessibility issue: If I’m not using my eyes (and my mouse hand to point), how do I ‘focus’ on something in order to then interact with it? The answer, as I’m sure you know, is via programmatic focus. It’s not as simple as just incorporating ‘focusable’ elements into our designs, however. Sometimes it is not the user but the interface on the user’s behalf that must move focus between different areas. This requires deliberate focus management on the part of the developer.

    For accessibility, managing focus is essential in many of even the simplest JavaScript-driven interactive widgets, but correct usage is almost impossible to test for with automated QA tools. That’s why I want to take you through a couple of simple examples today.

    ScrollTop Animation

    In this example, I invite you to imagine you have ‘enhanced’ a same-page navigation link so that, instead of jumping abruptly to the link’s target fragment (#section1, let’s say), you are ushered gently to this destination via a JavaScript scrollTop animation. The important thing to note regarding accessibility when using this technique is the necessity to override the default function of the <a> element.

    [code language="javascript"]
    event.preventDefault();
    [/code]

    By doing this you are telling the browser to avoid, at all costs, doing anything standard, expected or interoperable. You are telling the link not to link. In fact, the only way to make certain the link actually takes the user correctly to the page fragment is to turn JavaScript off. Well, then.

    By simply linking to a page fragment — as one would with JavaScript off — the browser essentially focuses this fragment. This is where screen reader output and keyboard interaction is now based. By animating the scrollTop, no such focusing action takes place, meaning screen reader output and keyboard interaction continues from the area of the page that is no longer in view. This is no good.