If you’ve ever worked on an application based on a design from a creative team, there’s a good chance that you’ve found a request to use fonts that aren’t system fonts. And if the application was designed to run on multiple platforms but the client wanted a consistent look, then you’ve almost certainly had to use something other than system fonts. In my experience, even when explicitly told to only use system fonts, the creative teams I work with manage to sneak in extra fonts without saying anything. Normally it’s because they’re used to designing for the web, not because they’re just trying to be contrary.

Now, technically it isn’t hard to use these fonts. Yes, you have to embed them in the application which increases the size of the executable and slows down load time. If it’s just a few fonts, that’s usually not a big deal.* Except that there are other possible consequences to be taken into consideration.

Do you have licensing for these fonts? And no, downloading them off them web from a free fonts website isn’t sufficient. And no, having a license to use the fonts on a web site doesn’t automatically allow you to use them in a mobile application. And based on a recent experience (although not with a project I worked on personally)**, I can no longer accept a font from a creative team based on their assertion that it has been properly licensed. Instead, I will need to get documentation of the licensing that can be checked in with the source code. Ideally, it would also be included in the application, but I’ll settle for having it with the source code.

Fonts can be an integral part of an interface design, but don’t cheap out. Spend the money and get licensed fonts. Think of it as an investment in getting great new fonts and having fewer possible legal questions in the future.

 

*My rule of thumb is that if they were told to only use system fonts and I find something else in the design, I bring it up explicitly in the review to push back. If the design has more than four fonts that need to be embedded, I get a little less polite. Also, don’t forget that every font variant (bold, italic, condensed, etc.) is a separate font.

**When you create applications on a work-for-hire basis, the client owns the code, and when the project ends, for whatever reason, the client can request a copy of the source code. Once the source code leaves your control, it can get used in ways you never expected.

Don’t wait until the end of the design (or development!) process to think about accessibility issues. Accessibility is not just a buzzword. It’s not just a checkbox on your prepare for deployment list. It’s about making sure there are as few barriers as possible for all your users. And no, I’m not talking about capturing a few extra folks who might be sight or hearing impaired. I’m talking about the larger (and largely invisible) group of people who have various kinds of color blindness. I’m talking about making your app easy to use by people who are keeping track of kids while shopping for groceries, or students in a lecture, or people working in a poorly lit office or out in the sunshine at a soccer game.

Mobile devices are mobile and people take them everywhere. This is both a strength, because they tend to always have them available; and a weakness, because they take them into less than ideal situations and still expect to be able to use them. Accessibility features are for everyone, not just people you think of as being covered by (inadequate) ADA laws. And accessibility works best for everyone if it is part of the initial design decisions rather than being an after thought. Make it part of the design. Make it part of testing. If the team pushes back, come up with use cases for otherwise able people who would benefit. Can’t come up with an appropriate use case? Try harder.

Sometimes the pushback will come from the client. Be ready with your arguments. Implementing accessibility features up front tends to be cheaper (and more thorough and less likely to break things) than bolting it on at the end. You have to test accessibility features because, whether or not you intend them to be used, someone will eventually use them. Making sure accessibility features don’t break your app (even if your app doesn’t make full use of them) can save you losing that customer plus all the friends they tell about the problem. It’s cheaper to keep an existing user than to get new ones. Plus, it’s the right thing to do.