A framework to create an accessible & harmonious typography system for faster design-dev handoff

Published in

Prototypr

10 min readAug 15, 2017

Enabling design & development teams to use accessible and harmonious typography in a predictable way for improved readability and consistency in product

Here is a 10 step process of how I redefined the typographic system for Practice Fusion’s EHR (Electronic Health Record) product, making sure it is accessible and harmonious to a baseline grid. This new typographic system has just 6 unique type styles — a massive reduction from the 50+ type styles (which includes some color / font-weight variations too) in our old typographic system, making the usage rules very predictable for both designers and developers on team.

Old & new typography systems (Note that I kept color variations for 13/20 outside of the typography system definition. 13/20 takes black color for most everything except when used as links (blue), error text (red), placeholder text (gray). Headers do not take any other font-weight variation other than what has been specified.)

10 PRACTICAL STEPS

Steps 1 & 2 are relevant only if you are starting out with an existing typography system that needs to be redefined. If you are starting to build a typography system from the very beginning, start from step 3. Also, I have made an assumption here that you already know which typeface/s you need to use and so, I am not diving into how to choose typeface/s in this post.

Step 1: Audit product for semantic hierarchy

I installed WAVE Chrome plugin and inspected the DOM outline for different pages in a test account (populated with mock data) of our product. This is what I found — we had h5 as the topmost header for many pages, followed by h3s in most cases. At times, we had no topmost header and directly started with h3s. On one page, we even had table headers as h6s. h1 was practically never used. It was quickly evident that semantic hierarchy was not accurate. Ideally, h1s should be followed by h2s followed by h3s and so on, without skipping any levels.

WAVE tool exposes the DOM outline of pages from a test EHR account, populated with mock data.

Step 2: Inspect visual hierarchy

I wrote down in descending order all the existing type sizes & corresponding font-weights. I chose to ignore the assigned header levels so I could focus on just the visual hierarchy. I made the following observations.

Step 3: Determine base font-size for body text

I started with 13px body size because that’s what we currently have and it seemed to work well for our information dense EHR system. (Why change what works?) Font size can vary based on the font chosen, but 10 point is usually a minimum for accessibility. 10pt translates to 13px roughly.

Step 4: Determine line-height that works for body font-size (Goldilocks approach)

This is the phase where you will need to do lot of visual explorations. I started out with font-size: 13px and line-height: 16px (denoted in “font-size / line-height” format going forward) — because I wanted to see if I could use the popular 8pt baseline grid and choosing 16px as my line-height was one of the values that would allow me to use it. At this stage, line-height value as well as 8pt baseline grid are really hypotheses and through explorations, I can either refute or validate that it works.

16px line-height looked too tight. So I chose the next 8px increment and tested with line-height 24px. It looked too spaced out.

Explorations (with mock data) using 13/16 and 13/24 (font-size / line-height format)

That meant, I had to find a value between 16 and 24. I chose to look at just even values — 18, 20, 22, as only those values are divisible by many numbers — which could act as spacing intervals. If I go with 18, it meant I needed to adopt 6pt baseline grid (since 18 is divisible by 6 and to maintain good vertical rhythm, all spacing should be proportional to line-height). Increments of 6 made spacing look tight for our information dense layouts; and with 18px line-height, descenders of first line felt slightly closed in to ascenders of second line.

I tried 20px as line-height. It looked almost perfect. 20 is a multiple of 4. This meant I was adopting a 4pt baseline grid. (As you will see later, I chose to use mostly multiples of 8 wherever possible as those provided a visually discernible interval. So, though I had more choices due to the 4pt baseline grid, I adopted mostly values allowed by 8pt baseline grid.)

I ruled out 22px for line-height — as it is not divisible by many numbers (only 2 & 11). This way, I derived a line-height of 20px that worked with my base body text of 13px.

Explorations (with mock data) using 13/18 and 13/20 (font-size / line-height format)

This value of 13/20 was also perfectly aligning with one of the points stated in the WCAG Success Criterion 1.4.8:

Line spacing (leading) is at least space-and-a-half within paragraphs

which translates to the following:

body / base line-height = minimum 1.5 x body / base font-size

13/20 provides a good line-height ratio of 1.538.

Step 5: Pick a ratio for the modular scale such that you have enough number of harmonious usable values

In order to derive other font-size values that are harmonious to each other, I used Tim Brown’s Modular scale. The most important work here is to come up with a ratio that makes sense for your system. I used tips in this blog and started thinking about what was an important number that could guarantee a good vertical rhythm for all font-sizes? I thought line-height (20px) was a good starting point. Line-height ratio in my case was 20/13 = 1.538. I checked if scale with this ratio worked for me. The scale felt too spread out. I cannot possibly have type as big as 112px, 73px, 48px etc for headers in my information dense layouts.

I needed another ratio — a ratio which was much tighter, but which still had 20px on it. This would ensure vertical rhythm with my body line-height. I picked the major third ratio (1.25) and it gave me values which I could work with realistically. I rounded off font-size values to multiples of 4 where feasible — so it also seemed more predictable with my 4pt baseline grid. Thus, I derived following harmonious font-sizes which could work as my type scale: 40, 32, 24, 20, 16, 13, 11, 8px

Modular scale at Major Third ratio (1.25)

Step 6: Start with defining h1

To ensure accessibility compliance, always start with h1. Ideally, never skip h1. This is an interpretation of the guideline from WCAG’s G.141 technique.

This is again a phase of visual explorations across multiple screens.

For our EHR, it meant unifying what h1 meant across different pages. On few of our pages, header that was supposed to be h1 was at 16px regular (coded as span) and on other pages, it was 32px light (coded as h5). I explored if I could use a single value that could be used as a h1 consistently across all pages.

I began to experiment with values greater than base body font-size (40px, 32px, 24px, 20px, 16px) derived from the previous step of type scale — starting with the biggest font-size value from that set — 40px for h1. 40px as h1 looked too big for the name of the patient. I tried the next value in the set — 32px. Again, 32px seemed too big for the name of the patient. The next value I tried was 24px regular and it worked really well for both scenarios.

Making sure h1 looks the same all across the product

Step 7: Determine how many header levels you need and values for each

With h1 defined, the rest of the work becomes much easier. First, determine how many headers you need by inspecting different layouts in your product. For Practice Fusion’s EHR, I could see that most layouts needed maximum 3 headers, but there were 2 very information-dense layouts that needed 2 more headers. I confirmed that none of the layouts in our EHR system needed more than 5 headers.

Having determined the number of headers, I just went 1 value below in my defined typographic scale for each consecutive header. If you realize that your typographic scale does not give you as many values, try a different typographic scale-ratio altogether.

Note that my h5 is same as my label or fieldset legend or table caption or column headers. That is because typically all the UI components like input fields / radio button set / checkbox set in form, or lists or tables on any page, are at the end of the hierarchy (referred by me as “leaf node”) and hold content in them. All of these leaf nodes could use label-like header which makes it very clear to the user that its the end of the information hierarchy.

Defining all other header values using the Modular scale

Step 8: Define line-heights for all font-sizes

Line-heights across all font-sizes must be proportional to each other to create a good vertical rhythm. To accomplish this — one way is to use the same base line-height / base font-size ratio for deriving all other line-heights and use these calculated values as is (See step 2 below). The derived values, however, may not turn out to be multiples of the baseline grid number. This can make it hard to remember and deal with the line-height value while working on mock-ups. So the 2nd way to come up with line-heights is — to round of the derived line-heights to the nearest multiple of the baseline grid number. Wherever I saw 2 possible line-height values, I tested them out in multiple explorations to rule out 1 of the options.

Step 9: Determining font-weight for headers

Hierarchy can also be clarified using font-weight. For determining what font-weight works for each header, I did visual explorations of different font-weights for each header and compared the stroke thickness.

Example 1–16px regular (for h3) looked similar to 13px regular in stroke thickness, and was hard to discern as a header in information dense layouts. To make it look like a header, I tried 16px semibold and it looked much better and readable.

h1 as 24px light looked too unnoticeable and out of place from rest of the type hierarchy. h1 as 24px semibold looked too loud, placing too much importance on h1. h1 as 24px regular gave it equal stroke thickness as 20px Regular & 16px semibold, and looked just right, fitting in seamlessly with rest of hierarchy.

Step 10: Think about DOM outline (top-down approach) to apply entire type system to any page

DOM outline is critical for screen-readers to jump between content. Often when we have a secondary navigation system, the tabs act as headers for people who can see them. So, visually there is no need to have a separate header for the content of the tab. However, screen-readers do not treat navigation tab as a header and so explicitly specifying header in DOM makes sense.

Even if you are sure that none of your users use screen-reader, it is a good practice to have the DOM outline as meaningfully done as possible. And that is because, by writing the DOM outline, you are really applying header levels in a consistent top-down manner. Because of this approach, you are unlikely to skip any header levels and you end up following similar DOM outlining process across all pages in your product. This helps to bring visual consistency across entire product.

In the below example, by hiding h2 for Summary, Profile, Encounter (06/06/2017), I made sure that h2 still exists in DOM. Since h2 is hidden (by using CSS technique like pushing it out of viewport with huge margin), it does not show up in UI as it is not needed.

In conclusion

By following this process:

You can eliminate any redundant type styles you may have accumulated over time.
Designers on your team will just know which type style to use when. There will be no ambiguity or confusion about usage rules.
Design-dev handoffs will become much faster as the developers also know all the rules of application and they no longer need the designers to redline everything or spend time in inspecting mocks in other tools like Zeplin.
Your UI developers & QA engineers will thank you for making their life easier.
Since so much time is saved across design & development teams, these teams are now free to take on other additional projects. And that impacts the business bottomline. Make this case to your leadership to allow you to invest in creating such robust design systems.

What’s next?

Type sizes and line spacing is just one piece of the puzzle. But there is more to spacing than just line spacing. If you found this post helpful, read my post on how to design a Spacing system. In that post, I explain how you can handle other spacing needs in UI by coming up with predictable easy-to-remember rules for margin / padding spacing — which still work harmoniously with your type. After spacing, I will be diving into designing accessible color system as well.

You can also follow me on https://twitter.com/priyankagodbole. Thank you for taking the time to read this far!

Useful articles / video for reference: