Typography for the web #6: Design with accessibility in mind
Accessibility means being able to say, “Yes, everyone can access my content.” It not only has to do with users with visual disabilities but also with users whose needs we touched on above: those with small or huge screens, those who prefer a certain text size, etc.
Legibility: Your typography should be legible. That means body text that is generously-sized, line-height that strikes a balance between the length of the line (horizontal) and the length of the text (vertical), and a font-choice that has a bias towards a sans serif.
Accommodating resizing: Some users will want to resize your text, usually to make it larger. If you haven’t built your text blocks to handle resizing—if your text overruns, overlaps, or does nothing at all—you’re not doing right by your user.
So as we discussed above:
- Set min and max widths for your
divs, and try to set a comfortable measure, around 66 characters per line
- Set your text styles to relative measures like ems or %
- In your headers, pay attention to lesser-used CSS elements such as
word-spacingin order to space things comfortably
Accommodating hard-copy printing: But don’t forget to create a separate print style sheet, one that, in contrast to your master style sheet, strictly sets the sizes for your text. When you create print.css, every text element should be sized in points (pt).
You want to keep two things in mind when choosing a color for your typeface.
First, always have sufficient contrast. Black type on a white background is as contrasty as you can get, but while there’s no magic formula for measuring good contrast among the thousands of colors available, you can always print out your website (print the screen image, that is) on any black-and-white printer and see if it’s comfortable to read. W3.org suggests it this way:
To test whether color contrast is sufficient to be read by people with color deficiencies or by those with low resolution monitors, print pages on a black and white printer (with backgrounds and colors appearing in grayscale). Also try taking the printout and copying it for two or three generations to see how it degrades. This will show you where you need to add redundant cues (example: hyperlinks are usually underlined on Web pages), or whether the cues are too small or indistinct to hold up well.
Second, remember that all colors on a computer screen are being radiated. In print, black text absorbs light while the paper reflects it, but on a screen, every color is shooting photons at the user. And these colors are being radiated differently depending on the monitor. So a red background can not only be intense on the eyes but it might show up as orange or pink to some users depending on how their monitor is calibrated. So, remember that your dark gray text on a light blue background ultimately might not have enough contrast when it comes out of a monitor rendering them as medium gray text on a medium blue background.
Again, concentrate on the user’s needs—you can even go as far as to make a second stylesheet that the user can opt for, for example if you sense a 50/50 split among your users’ preferences for light text on a dark background vs. the opposite.
Colorblindness: Around 8% of the male population suffers from some level of color-blindness. (Through a genetic quirk, colorblindness is significantly lower among women). So when you choose colors for your type and background, consider using a tool like Adobe’s Color Scheme Designer, which has a feature to help you see what a colorblind user sees. While there’s no magic formula for what colors work best, you always want to know what your site would look like to someone who isn’t seeing it as intended.
We’ve talked this one to death, but to reiterate: different users have different screen sizes and different preferences for width. For your main blocks of text, always set a max and a min width, either in ems or &.
One option I haven’t spoken about is SIFr (and similar options like FLIR and Typeface.js). For our purposes, they’re complicated to discuss, but here’s the background for SIFr and when you might use it.
SIFr stands for Scalable Inman Flash Replacement (Shaun Inman being the guy who came up with it), and it does what it says: it replaces each letter in a block of text with a Flash equivalent, using any typeface of the designer’s choosing. So if I have a heading that reads “Typography for the Web” but want it to be displayed with the typeface Meta, SIFr will use Flash to overlay the letters T, y, p, o and so on, in Meta, over top of those same letters in a traditional web-friendly typeface.
The benefits are twofold: you can use any typeface you want, and screenreaders (for blind users) and search engines can still read the content.
There are two drawbacks as well: it can be really difficult to implement, and because you’re using Flash or a script, it’s really only appropriate for headings—it would slow down the loading of body text to a point where the site is unpleasant to use.
Lastly, I want to mention the licensing of typefaces. When I asked a group of typographers what they want people to know about type on the web, every one of them said—yelled, really—”Everyone needs to know that typefaces aren’t free!”
We’re accustomed to thinking type is free only because it comes pre-installed on our computers. And we at MIT are culturally accustomed to sharing everything. But Microsoft and Apple have in fact paid a lot of money to have those half a dozen basic types on your computers.
Typefaces can be downloaded just like music files can—both legally and illegally. So know that if you ever stray away from those basic typefaces and want to take advantage of something like SIFr, be sure you have some money budgeted to buy a license to use those new types or be sure are prepared to risk running afoul of the law.