Using an accessible typeface in a mobile news app
Font of all wisdom (or not?)
When you’re a publicly-funded news organisation like NOS (Dutch Broadcasting Foundation), there’s no getting away from the fact that you have a broad audience. This affects not only editorial choices (what news do we report?), but also presentation and distribution (how do we report it?). Whether via TV or online, sites or apps, a broad audience means a diverse audience, and that means, among other things: making sure our apps and sites are accessible.
Over the past years, awareness of the importance of accessibility has grown a lot within NOS, not least because platform providers like Apple keep pushing to make it a standard part of everyone’s development process — and rightly so. In addition, we try to connect with different organisations to make sure we’re doing the right things.
And because we want to have fun while doing those, we also regularly run internal hackathons (which we call Lab Days — it still has to look like work, after all). Few things are as creatively stimulating as locking yourself up with a mad idea, an exciting new technology, and a couple of enthusiastic co-conspirators to try to come up with the next killer app by day 3. The only hard rule: add demonstrable value for our users.
One idea that was launched during a recent hackathon was to use a special font to improve readability for people that are to some degree affected by symptoms of dyslexia. The specially designed ‘Dyslexie’ font offered the promise of ease-of-readability and better reading comprehension that sounded ideally suited to the job. According to the designer, by ignoring the standard rules of typography (already aimed at clear legibility in most cases, interestingly), he had been able to create something that took his own experience struggling with dyslexia as a starting point.
What is dyslexia?
The DSM-5 diagnostic manual describes dyslexia as a “specific learning disability with impairment in reading”. And also: “Dyslexia is an alternative term used to refer to a pattern of learning difficulties characterised by problems with accurate or fluent word recognition, poor decoding, and poor spelling abilities.” At the time of writing, the Wikipedia entry starts out with “Dyslexia, previously known as word blindness, is a learning disability that affects either reading or writing. Different people are affected to different degrees.” The Encyclopaedia Britannica adds: “Primary symptoms include (…) a tendency to read and write words and letters in reversed sequences, similar reversals of words and letters in the person’s speech, and illegible handwriting.”
Unfortunately, the idea that a special font can be used to improve reading ability does not appear to be supported by much research. Nevertheless, within NOS we wanted to give our users the option to decide for themselves what works and what doesn’t.
Meeting the designer
For a quick proof of concept, we were able to use the font as a drop-in replacement for the default font in our Android app, and had the new version running within the space of an hour. This looked promising enough to convince our stakeholders.
Creating a viable product, of course, is always more work than you think. To make sure that our feature would win over our users we contacted the font designer and asked him for input. It turned out he had designed his font mostly for print purposes, so when we showed him our concept implementation he immediately started pointing out things to tweak. It became clear that just replacing the system font wouldn’t do. If we really wanted to improve readability, we’d have to consider offering:
- a wider, more fine-grained range of font sizes
- greater line spacing
- smaller and all-caps subheadings
- narrower text columns
- narrower table columns
- reducing the number of distracting page elements like red bullet points in live blogs
- dark colour scheme: e.g. dark blue text on light yellow background
- and even (my favourite): optimising line breaks semantically, for instance after commas, or before definite or indefinite articles
A rude awakening, to say the least. In addition to which, our own app-styling system didn’t map trivially to the ‘Dyslexie’ font sizes and weights.
Another issue, beyond our direct influence, was video: our apps have a lot of it, and a lot of our video is subtitled for those hard of hearing or for muted playback. Since subtitles are (currently) burned in, their font and layout cannot be changed from within the app.
In the end, mostly due to pressures of development time and resources (and the FIFA World Cup looming ahead) we decided to go for the simplest solution: mapping the system font weight ‘regular’ to ‘Dyslexie-Regular’, and everything heavier to ‘Dyslexie-Bold’. (Luckily our app doesn’t use anything lighter.) The font sizes were reduced by 1 or 2 points, or slightly more in the case of headings. A toggle in the appearance settings allows the user to turn it on or off.
Meeting the typeface
The Dyslexie font was designed by Christian Boer. He found that, when reading, the way individual letters turned and mirrored for him had much in common with movements in 3D space. His design focused on reducing these movements, by employing:
- heavier bottoms for the glyphs
- forms that make it easier to distinguish between letters
- looser spacings
- bold capitals
- a number of other changes that violate regular typeface rules, but improve legibility
The result looks far from elegant, with letters that sometimes seem to be too far apart, with irregular heights, and misaligned punctuation marks. But elegance was never the goal. Dyslexie looks like a case study in thinking outside of the box, or more accurately, colouring outside of the lines. The purpose of the font is making text more readable, and what better way to get your texts read than removing as many barriers to reading them as possible?
A viable product
After upgrading our style system to allow for the extra functionality, we added the most important dyslexia optimisations. About a month of digging later, with some stuff remaining on the backlog, we had our first release candidate.
Reception among the general public was mostly favourable, with reactions ranging from “Yay, I can finally read the articles”, through “For those among us with dyslexia, this is a fantastic update”, down to “Why has the font been changed to some kind of Comic Sans?” We have even had fan requests for the font to appear in our Jeugdjournaal (news for kids) app.
So does this actually help people with reading comprehension issues? Honestly, evidence remains anecdotal. Everyone is different, and one person’s elegant calligraphy may be another’s illegible scribble. But in our efforts to improve our apps’ accessibility for as wide a range of users as possible, this certainly is a step forward.
In-depth: confronting reality
The two app platforms we support have very different approaches to styling, which called for different ways of making the font available.
iOS
Even though our iOS app has always offered a variety of font sizes, it was never designed to support dynamic typeface selection. Apart from very occasional third-party branding in case of special events, we use only one custom font for headings, in addition to the system font which does duty as our workhorse typeface. So while it was easy to perform a search-and-replace and declare the concept ‘proven’, integrating the font into our styling system required more effort.
We seized upon this opportunity to improve our design system, modernising it and making it more orthogonal, using pluggable Typography and FontProvider objects. Unfortunately there were two additional levels of legacy we had to deal with, inherited from years of interface revamping by different UX designers. But we were able to use the occasion to clean up the things that needed cleaning.
So how did we do that? When we first (re)built our iOS app (just after the introduction of Swift about eighty years ago), our main styling mechanism used a Theme object to propagate various user-interface traits (e.g. dark mode, size class) throughout the view hierarchy. Every view could query this theme for context-specific styles containing fonts, colours, margins etc. Over time, as the need to be more flexible with respect to branding grew (mainly involving pages for special sports events), styles became more closely associated with views, and styles themselves became themed, although our typography remained fixed.
In order to allow different typefaces to be selected, we introduced dynamic typographies and font providers, so each view could be reconfigured with different text styles for any font family we care to support. The theme is usually set app-wide (the NOSTheme), but can be different for a special feature section (e.g. the SpecialTheme).
A theme contains a typography object, which defines a number of semantic text styles. Each text style has attributes such as leading, scaling, line height, alignment, colour, and other properties. This allows our UX designer to define a system of styles which they can use in designing new content pages for the app. It also allows us to inject a different typography when switching to ‘dyslexia mode’, with slightly different leading, scaling etc.
Every typography also has a font provider, which handles the actual font selection for different weights and header sizes. Keeping this loosely coupled is important because not every desired variant may be available, and other options may need to be provided. For instance, in the default typography we always use a custom display font instead of the system font for certain header styles; however, all styles should always use the Dyslexie font in dyslexia mode. Also, as mentioned above, the Dyslexie font only offers two weights, while our design system uses five.
ANDROID
To make the font work in our Android app, we used themes overlay, a technique to customise existing styles without the need to completely overhaul them. This works by defining a theme containing just the attributes that should be different, and adding it to the root of the subtree in the view hierarchy that needs to have its styles modified. The theme is overlaid onto all descendant nodes in the tree, overriding global style attributes with the more local ones, and even adding attributes when specified. The overlaid theme propagates into tooltips and other Android components as well.
Using colours as an example:
We defined a new theme attribute isDyslexiaOptimised to determine whether the current theme is overlaid with the dyslexia theme. If it is, the value of the fontFamily attribute will be replaced by the Dyslexie font family.
<style name="ThemeOverlay.Dyslexia" parent="">
<item name="isDyslexiaOptimised">true</item>
<item name="fontFamily">@font/dyslexie</item>
...
</style><?xml version="1.0" encoding="utf-8"?>
<font-family
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
tools:targetApi="o">
<font
app:fontStyle="normal"
app:fontWeight="@integer/regular"
app:font="@font/dyslexie_regular" />
<font
app:fontStyle="normal"
app:fontWeight="@integer/bold"
app:font="@font/dyslexie_bold" />
</font-family>When the user chooses to select the dyslexia-optimised style setting, a call to setTheme on Activity level installs the theme overlay.
Summary
Optimising for dyslexia was an interesting project, and a nice example of how a simple idea can lead to a meaningful addition in user experience, as well as enhancements in app architecture. We involved both our own UX designer and the font’s creator to help us improve an important accessibility aspect of our apps: readability. Even though we weren’t able to implement everything we wanted, we certainly made a good start.
This is a topic we will never be done with or get tired of, and we’re looking forward to continue making our apps valuable to as many people as possible.
