Typography

Designing Accessible Content: Typography, Font Styling, and Structure

There are many design considerations for making your content more accessible to all. Some things to think about and build into your design workflow include:

  • Choose a common font that most users have encountered before.
  • The “serif vs. sans-serif debate” is not a huge deal if you choose a common font family or one that has unique characters.
  • Avoid specialty display fonts or font families that are not unique (ex. letters or numbers that could mirror each other).
  • Your fonts should have a minimum size of 14px (ideally more) and when coded should use relative values.
  • Pay attention to color and contrast! Use tools to check the ratio between the text and background and be wary of gray.
  • Don’t rely on color alone to signify information (ex. “click on the red button”).
  • Clearly define paragraph and letter spacing.
  • Do not let the overall width of the content exceed 80 characters (40 characters for logograms).
  • Avoid paragraph alignment (such as justified) which creates whitespace within the content.

Font style matcher

Image

This is pretty cool: you can use this to visually display the differences between two fonts - usually a fallback font and a web font - and adjust the various CSS font properties to match them as closely as possible to reduce the amount of page shifting that may occur when the web font loads. Also includes a longer paragraph at the bottom that can compare the two fonts either by overlaying them statically or by switching between them at a regular interval.

Using UI System Fonts

For perhaps the first time since the original Macintosh, we can get excited about using system UI fonts. They’re an interesting, fresh alternative to web typography — and one that doesn’t require a web-font delivery service or font files stored on your server. How do we use system UI fonts on a website, and what are the caveats? System UI fonts being amazing kind of snuck up on us. Google has been toiling away at Roboto with great success (including regular updates), Apple made a splash with San Francisco, and Mozilla asked renowned type designer Erik Spiekermann to create Fira Sans.

Code language: CSS

font-family:
/* 1 */ -apple-system, BlinkMacSystemFont,
/* 2 */ 'Segoe UI', 'Roboto', 'Oxygen', 'Ubuntu', 'Cantarell', 'Fira Sans', 'Droid Sans',
/* 3 */ 'Helvetica Neue', sans-serif;

The first grouping is CSS properties that map to the system’s UI font. That covers a lot of ground, and there is no chance that these fonts will be mistaken for something else:

  • -apple-system targets San Francisco in Safari on Mac OS X and iOS, and it targets Neue Helvetica and Lucida Grande on older versions of Mac OS X. It properly selects between San Francisco Text and San Francisco Display depending on the text’s size.
  • BlinkMacSystemFont is the equivalent for Chrome on Mac OS X.

The second grouping is for known system UI fonts:

  • Segoe UI targets Windows and Windows Phone.
  • Roboto targets Android and newer Chrome OS’. It is deliberately listed after Segoe UI so that if you’re an Android developer on Windows and have Roboto installed, Segoe UI will be used instead.
  • Oxygen targets KDE, Ubuntu targets… well, you can guess, and Cantarell targets GNOME. This is beginning to feel futile because some Linux distributions have many of these fonts.
  • Fira Sans targets Firefox OS.
  • Droid Sans targets older versions of Android.
  • Note that we don’t specify San Francisco by name. On both iOS and Mac OS X, San Francisco isn’t obviously accessible, but rather exists as a “hidden” font.
  • We also don’t specify San Francisco using .SFNSText-Regular, the internal PostScript name for San Francisco on Mac OS X. It only works in Chrome and is less versatile than BlinkMacSystemFont.

The third grouping is our fallback fonts:

  • Helvetica Neue targets pre-El Capitan versions of Mac OS X. It is listed close to the end because it’s a popular font on other non-El Capitan computers.
  • sans-serif is the default sans-serif fallback font.

Unicode characters in CSS generated content

I ran across an issue today where I had set some generated content to an unusual character (an open quotation mark), but the compiled and minified CSS served by Drupal was showing me the wrong characters. It was likely caused by character encoding getting screwed up somewhere along the line. The solution was to specify the Unicode character I wanted in the format seen in the code block below, as demonstrated in the source link below and this Stack Overflow answer.

Code language: CSS

p:before {
  content: "\201C";
}

Text stroke with CSS

Image

There is a non-standard way to stroke HTML text (SVG has a standard way). It’s not particularly new. There are -webkit- and -moz- prefixes for it. Jen Simmons recently posted about it, with an example:

Code language: CSS

span {
     -moz-text-fill-color: #fde;
  -webkit-text-fill-color: #fde;
     -moz-text-stroke-color: #666;
  -webkit-text-stroke-color: #666;
     -moz-text-stroke-width: 2px;  
  -webkit-text-stroke-width: 2px;
}

And she’s right:

This CSS isn’t fully-baked or fully-supported. But it’s good enough to be used today, especially since it’s simply offering a visual enhancement. It’s not mission critical to making a website usable.

I’d only perhaps add that if you were going to do something like add a stroke around white text, you could wrap it in a @supports to be extra sure it’ll be OK (just in case a browser exists that supports text-fill-color but not text-stroke-color) :

Code language: CSS

@supports 
  ((-webkit-text-stroke-color: #666)
  and
  (-webkit-text-fill-color: white))
  or
  ((-moz-text-stroke-color: #666)
  and
  (-moz-text-fill-color: white)) {
  span {
       -moz-text-fill-color: white;
    -webkit-text-fill-color: white;
       -moz-text-stroke-color: #666;
    -webkit-text-stroke-color: #666;
       -moz-text-stroke-width: 2px;  
    -webkit-text-stroke-width: 2px;
  }
}

See the link for more tricks, and the comments make a good point that you don’t have to use text-fill-color if you’re using @supports: just use color.

Dealing with long words in CSS

Code language: CSS

.hyphenate {
  overflow-wrap: break-word;
  word-wrap: break-word;
  -webkit-hyphens: auto;
  -ms-hyphens: auto;
  -moz-hyphens: auto;
  hyphens: auto;
}

This solution will show hyphens for every browser supporting it and will break lines in every other browser – perfect. [Although] I have tested this solution in 26 different browsers I am still not sure this will work 100% – if you find any edge case please let me know.

Tuna - Typeface

Image

Tuna is simply a contemporary body text font. It is contemporary, meaning the merge of charming broad-nibbed calligraphic style with optimized legibility on screen – showing that the roots of writing and typesetting are still in charge when reading “Anna Karenina” on a kindle till 4 o’clock in the morning.

Tuna has a natural fit for cross-media use because the design is based on forms characterized by different conditions of consistency, stability and good legibility. Well defined shapes and distinctive details only become apparent when used in larger sizes, making Tuna a true all-rounder.

With more than 700 glyphs in 10 styles created with a maximum of consideration, it has all the qualities of a modern OpenType font serving the needs of [today’s] communication.

Typefaces: NPM packages for Open Source typefaces - making it easier to self-host webfonts

Why

  • Self-hosting is significantly faster. Loading a typeface from Google Fonts or other hosted font service adds an extra (blocking) network request. In my testing, I’ve found replacing Google Fonts with a self-hosted font can improve a site’s speedindex by ~300 miliseconds on desktop and 1+ seconds on 3g. This is a big deal.
  • Your fonts load offline. It’s annoying to start working on a web project on the train or airplane and see your interface screwed up because you can’t access Google fonts. I remember once being in this situation and doing everything possible to avoid reloading a project as I knew I’d lose the fonts and be forced to stop working.
  • Go beyond Google Fonts. Some of my favorite typefaces aren’t on Google Fonts like Clear Sans, Cooper Hewitt, and Aleo.
  • All web(site|app) dependencies should be managed through NPM whenever possible. Tis the modern way.

What

Each typeface package ships with all the necessary font files and css to self-host an open source typeface.

All Google Fonts have been added as well as a small but growing list of other open source fonts. Open an issue if you want a font added!

How

Couldn’t be easier. This is how you’d add Open Sans.

npm install --save typeface-open-sans

Then in your app or site’s entry file.

require("typeface-open-sans")

And that’s it! You’re now self-hosting Open Sans!

It should take < 5 minutes to swap out Google Fonts.

Typeface assumes you’re using webpack with loaders setup for loading css and font files (you can use Typeface with other setups but webpack makes things really really simple). Assuming your webpack configuration is setup correctly you then just need to require the typeface in the entry file for your project.

Many tools built with webpack such as Gatsby and Create React App are already setup to work with Typefaces. Gatsby by default also embeds your CSS in your <head> for even faster loading.

If you’re not using webpack or equivalent tool that allows you to require css, then you’ll need to manually integrate the index.css and font files from the package into your build system.