Accessible design fundamentals
This article was also published in UX Planet
Accessibility is an important topic for every designer to learn about, but sometimes it gets shrouded in a mystique of “important but complicated”.
Here’s some common framing about how contributions which originate from accessibility initiatives end up benefit everyone:
On the other hand, not taking accessibility into consideration can lead to disastrous outcomes, such as:
I’ve seen a lot of talks about accessibility that sort of advocate for it without providing too many practical steps to take, so I wanted to take a stab at writing up some information that I’ve found helpful to learn.
Most of this information comes from a handful of sources:
Additional resources can be found here:
Making text readable
The most common accessibility issue is unreadable elements in a design.
Text and typography can seem like an overwhelming world, where only experts with decades of experience know what’s going on.
In reality, understanding some best practices and typical values to use can get you very far.
Following these guidelines can help you catch a lot of low-hanging fruit early in a product’s design.
An aside:
WCAG’s requirements for typography seem a bit odd to me for a few reasons:
they don’t follow their own guidelines.
they recommend increasing letter spacing (tracking) by a huge amount, which I don’t understand. For body text, it’s more common to see letter spacing reduced by a very, very small amount, such as 0.01em.
spacing between paragraphs is more closely related to line height than font size. From WCAG 2.0 to 2.1, they changed their recommendation for paragraph spacing from being based on line height to being based on font size, which seems like an odd recommendation.
they make universal recommendations for type settings, which doesn’t take into account that different fonts will need different settings applied to achieve the same relative size, spacing, etc.
I wanted to make sure to call out WCAG’s guidelines for awareness, because a lot of what I’ve written below differs from WCAG’s guidelines.
Most of my recommendations for type are based on the book Web Typography by Richard Rutter, which in turn is based on The Elements of Typographic Style by Robert Bringhurst.
Font sizes
Font size for body text — which, loosely, can be thought of as any lengthy block of text, such as paragraphs — should not be below 16px on mobile, tablet, or desktop.
16px is a minimum. Body text can be larger than 16px.
On mobile, tablets, or desktop, font can be smaller than 16px, but only in situations where it is not body copy.
When it’s okay to use smaller font sizes
Some examples of text which is not body copy are elements like button labels, or labels for other interactive components on the page.
Making those elements have text smaller than body copy is done to create a hierarchy of text within the page.
This helps prevent things like labels for a text input field from being confused as body copy that might be placed near the field.
Even in these situations, font below 14px should be approached warily.
Why small font size can be a problem
Making text too small makes it difficult, or impossible, to read the words on the screen.
As devices get farther away from a person’s eyes, text appears smaller, and needs to be larger in order to be read.
This means that UI seen on a television — such as interfaces for smart devices, or paragraphs of text within video games — need to appear larger than the same design for a phone or tablet.
Line lengths
The ideal line length for body copy is about 70 characters long.
The specific number varies from font to font, but the “good number” range is somewhere between 50 characters to 75 characters. Anywhere in that range is pretty safe to use.
This issue mostly applies to devices such as laptops and desktops, where monitors can be ultra-wide, and unconstrained text can span the full width of a browser.
An example of a website designed in full width is https://en.wikipedia.org/wiki/Main_Page, which does not use any limits for line length.
On tablets and phones, there’s often not enough width on the device for a line to run longer than 70 characters, so capping line lengths is usually not an issue on smaller breakpoints.
Broadly, there are two ways to constrain line lengths:
Specify max-width for text
In HTML, a unit of size called “ch” exists. This can be used to specify the size of things according to how many characters it takes up.
A property called “max-width” also exists. This can be used to prevent something from growing larger than a specific dimension.
These elements can be defined, so that body text (which is likely anything with a <p> tag) is capped at 70ch.
This has the effect of preventing any line of a paragraph from being larger than 70 characters.
“rem” or “em” units can be used instead of “ch” for essentially the same effect.
Specify container size
Instead of specifying a specific width value to a paragraph, instead you might have the line run from start-to-end of a component which the text is contained inside of, such as a card.
In this case, the card would be a container for the text, and the text’s width would be determined by how large the card is designed.
Because of this, it’s important to size the container to have an appropriate width to prevent text from overflowing past a readable line length.
This is a slightly more complicated situation than specifying the width of the text itself, because the card will also have things like internal padding that will impact line length.
Some ways to handle this are by specifying specific container dimensions at different breakpoints. For example — on desktop, a card might have a width of 600px. On mobile, it might have a width of 200px.
Things like percentage units, which size things as a percentage of the space available, can also be used and cause containers or text to “flex” — which means shrink, or grow, or shift layout from side-by-side to stacked-on-top depending on space available.
There’s no one correct or best way of sizing things on the web. Being aware of these considerations, and testing designs on different device breakpoints, can help prevent unwanted issues.
Why long line lengths can be a problem
When humans read text, the eyes bounce along the line of text that they are reading. This is called a saccade.
The eye’s focus mostly bounces forward, progressing through the text, but it also bounces backwards to re-read pieces its already read. These eye movements on unconscious, and are not noticed by most people as they do it.
When people get to a new line of text, the eye moves from one end of the text block all the way back to the other side.
Long lines of text create extra movement that eye needs to take. This can make it difficult to keep track of what line of text someone just finished reading, and make it difficult to find the next line of text to read.
A long line length can mean that the person reading the text will accidentally re-read text they’ve already read, or skip over the line that they meant to read next.
These problems are exacerbated for people who have dyslexia, which is about 20% of the US population according to the NIH.
Placing reasonable constraints on line length help reduce these problems.
Line height
Line height determines the spacing between lines of text, and is usually represented as either a multiple or percentage of font size.
For body copy, ideal numbers for line height are typically 1.2 to 1.5 times font size, or 120% to 150% of font size.
The specific values to use will vary from font to font, but anywhere within this range is typically safe. This is also a fairly easy setting to adjust in HTML/CSS, so it’s something simple to iterate on as needed.
Products where the primary purpose is for people to read articles, such as blogs or newspapers, will tend to use the larger range of those ideal values.
For example, www.nytimes.com uses 150% for their line height, and www.medium.com goes a step further than the typical range by using 160% for their line height. Both examples are based on their desktop breakpoints — they may use different line heights on different devices.
Larger font sizes need smaller line heights
Larger text, such as headings, will need to use shorter line heights. Because line heights are a multiple of font size, this means that as text grows larger, line heights grow larger as well.
For something like a 48px heading, a line height sized to 150% will create so much space that each line of the heading will appear disconnected from the line above it.
In these cases, line heights of about 80% to 120% are safe to play around with. The specific number to use will depend on the font.
An appropriate setting should make headlines that span 2 or 3 lines appear connected, without creating any overlapping letters between the lines.
One specific element to pay attention to is how ascenders (such as the top pieces of the letters “b” and “h”) interact with descenders (such as the bottom pieces of the letters “y” and “p”). Typically, if these overlap between lines, then line-height should be increased.
Why small line height can be a problem
Similar to line length, a small line height can make readers lose their place when their eyes shift from one edge of the text to the other.
Additionally, a small line height can make it difficult to focus on any one specific line of text. This can cause the reader to mistakenly read letters from a line above or below the line of text that they are trying to focus on.
These problems are exacerbated for people who have dyslexia, which is about 20% of the US population according to the NIH.
Using reasonable values for line height help reduce these problems.
Paragraph spacing
Paragraph spacing is the distance from the bottom of one paragraph to the top of the next paragraph.
Safe values to use as a distance between paragraphs are:
half the line height for tighter spacing
equal to line height for larger spacing
up to 200% line height for extra large spacing
In HTML/CSS, paragraphs pacing will usually be done with the “margin-bottom” property assigned to paragraphs (elements using the <p> tag), or with a combination of “margin-top” and “margin-bottom” properties.
By default, most browsers will set paragraphs to have a bottom and top margin of 1em (which will likely be 16px) already added to the paragraph. This means that there will be a 32px gap between paragraphs, which may be larger than ideal.
Depending on the tool used to create the design, these default values may not be applied.
One example where this issue can occur is when designing things using the no-code web design tool Framer. In that tool, some extra effort is required to control space between paragraphs.
Another example is when working in Figma. Figma uses an abstraction called “Paragraph spacing” to control this property. There is not an equivalent property in HTML/CSS. The actual web version will likely use top and bottom margin properties instead of Figma’s “Paragraph spacing”.
As a sidenote regarding Figma, paragraph spacing values assigned to text will not appear as a value in the Inspect tool. These values need to be annotated for developers to be able to see it.
Why poor paragraph spacing can be a problem
Similar to line height, paragraphs spaced too close together can make it difficult to separate one paragraph from the next. It can make users feel “claustrophobic”, or feel overwhelmed by the amount of text on a page.
Paragraphs too far apart can make it feel like paragraphs are disconnected to each other. This might also make it difficult to refer to a piece of information that’s contained in one paragraph alongside a piece of information from the paragraph above or below it.
Paragraphs placed very, very far apart can cause someone to think they’ve reached the end of an article when more content exists on the page. This can occur if elements like images or video fail to load in, because of either internet connection issues, content blockers, or some other reason.
Color contrast
Text color has two elements — the color of the background that the text is set on, and the color of the text itself.
White text on a white background, or black text on a black background, will make the text appear invisible and impossible to read.
So that text will appear visible and readable, light text should always be set against on a dark background, and dark text should always be set against a light background.
The amount of difference between a text’s lightness or darkness and a background’s lightness or darkness is called “contrast”.
Black text on a white background, or white text on a black background, is the highest level of contrast possible.
There are tools created for measuring how much a text and its background contrast with each other. One of the most popular tools is https://webaim.org/resources/contrastchecker/ , and a Figma plugin which does the same thing is the A11y - Color Contrast Checker https://www.figma.com/community/plugin/733159460536249875 .
For AA accessibility, normal text such as paragraphs or body text requires a contrast ratio of at least 4.5:1 , and large text such as headlines requires a contrast ratio of 3:1.
How to control contrast
One way to intentionally control contrast between colors is by designing using the HSL (hue, saturation, lightness) or HSB (hue, saturation, brightness) color models.
Both of these models have an explicit value (Lightness for HSL, or Brightness for HSB) that can be raised or lowered to make a color lighter or darker.
Using HSL or HSB to raise or lower the Lightness or Brightness of colors can simplify the work of creating contrast between elements.
Anecdotally, HSL seems to be the more common model of the two options, and I find Figma’s implementation of HSL easier to work with than HSB.
HSL in Figma basically uses Lightness as the Y-axis in the color picker, and Saturation as the X-axis, which gives the color picker a predictability that I don’t think the other color models offer.
HSB in Figma has Brightness cross both the X and Y axis of the color picker, which I find more confusing to work with.
Do not rely solely on contrast checkers
Sometimes, the tools can fail.
In some situations, contrast checkers will provide a passing grade for text that obviously is not readable. For information about why this happens, see Henrique Gusso’s talk from Config Europe 2020 or Lisa Charlotte Muth’s article about color contrast.
Upcoming changes to WCAG will change the color contrast algorithm to provide more accurate readings in situations where the current algorithm fails. However, that change is still a way off.
While the new model can be used today, its use is not very widespread, and even with the change, it’s still important to be aware that these tools can fail.
A good, simple safety check is to just look away from your design, and then look back at it. If things seem blended together, or you need to squint at all to read the text, then something should probably change to make the text more readable.
Why poor color contrast can be a problem
If users cannot see the content on your page, they cannot access it.
Using lighter-colored font is fine, and often necessary. Having text that is a little bit “greyed out” compared to the primary text color on the page is a great way to create hierarchy.
Some spots where lighter colored text might be used are for things like help-text in a form field, or other supporting text on a page.
However, even when intentionally de-emphasizing text, it still needs to pass accessibility guidelines. If users cannot read help-text for a form, then the help-text is not very helpful.
Making content understandable
The above information about typography is focused on foundational elements of a design that allow users to read without difficulty.
To make information understandable, the important piece is the actual words on the page.
Chunk up information with headings and sub-headings
Headings and subheadings are how all users scan through a page.
For users who interpret the page visually, headings allow them to see where each section begins or ends, and get an idea of the information contained in the different sections of a page.
Similarly, accessibility tools used by people with trouble seeing will use headings and subheadings to “announce” the different sections of the page.
Proper use of headings and subheadings
Headings are titles above sections of a page. Usually, there are multiple heading styles on a page. They’re often called named like H1, H2, H3, and so on.
Headings are both a design element and a web element.
In design, headings are larger pieces of text that help build a hierarchy for information. People can spot the big pieces of text, and then can read the normal-sized text below the heading to learn more about the topic.
On the web, headings are elements that help browsers and accessibility tools understand how to interpret the page.
Headings can have subheadings nested inside of them. This might be thought of sort of like indents in a bulleted list, or how things are stacked in a Russian nesting doll.
Proper use of headings will work something like this:
<H1>
<H2>
<H3>
<H2>
<H3>
<H4>
<H2>
In this example, bullets are used to show an example of nesting. An H4 is contained within an H3, an H3 is contained within an H2, and H2’s are contained within the page’s H1. Heading levels follow a predictable order, and there’s never a jump from something like an H1 to an H3, or an H2 to an H4.
This example does not indicate styling. Headings should not be indented like bullet points.
This type of nesting is helpful for visual readers, because it creates an intuitive sense of where to find different pieces of information as the page is scanned.
This type of nesting is also very helpful for readers using accessibility tools like screen readers. Those tools navigate the page by announcing headings and jumping between headings on the page.
In that case, having descriptive headlines and proper nesting of headings becomes incredibly important for someone to quickly scan through the page and find the information they are looking for.
An example with actual content might look like this:
Getting a driver’s license
Making an appointment
What to do if you can’t schedule an appointment
Requirements for driver’s license
Necessary documents
How to request missing documents
When you will receive your driver’s license
For additional information, see: https://readabilityguidelines.co.uk/content-design/headings-titles/
Use simple, clear language
When writing, it’s very easy to communicate with too many words (this page may be one example of that).
When creating content, it does not matter how accurate your content is if the audience that you are writing for cannot understand it.
To make sure that your ideas are being communicated as effectively as possible, there’s a few standard guidelines to follow:
Paragraphs should not be longer than 2 or 3 sentences
Break up big ideas into separate, smaller, digestible pieces
Use the simplest, most common words possible
When writing anything, it’s good to think about this fact from https://readabilityguidelines.co.uk/clear-language/low-literacy-users/
In America, 43% of the population has low literacy as defined by the US Department of Education's National Assessment of Adult Literacy.
When writing content for the web, you should plan for it to be consumed by both experts and amateurs, people who grew up with books in their homes and people who grew up with fewer opportunities to read, and by people who are native speakers as well as people who have learned the language later in life.
Simplify as much as possible, eliminate any unnecessary information, and reduce messages to the main idea you’re trying to tell the user.
For additional information, see: https://readabilityguidelines.co.uk/clear-language/
Use alt-text, captioning, and transcripts
When displaying images, audio, or video, always provide an alternative method of providing the same information for people who cannot access the image/audio/video.
This does not only help people who have difficulty seeing. Google uses this information when ranking SEO, so taking the time to add this content also helps the business by increasing the number of people accessing pages and decreasing things like calls to support staff.
Things like transcripts also allows users do precise searches in their browser, through hotkeys like cmd+F or ctrl+F, to find specific information.
For example, Kristina Halverson’s The Content Strategy Podcast includes transcripts for every episode of the podcast. Because of this, it’s simple for any user to quickly find any episode that mentions specific topics, such as content audits, design maturity, or other methods and strategies.
Writing alt-text
The normal question to ask after learning about alt-text is “What makes good alt-text?”
View Haben Girma’s presentation at Axe-Con 2021 to hear someone who relies on alt-text and transcripts to interpret the web talk about the types of descriptions they like to have in alt-text.
In her presentation, she asks for alt-text to be as descriptive as necessary to give the same information that a sighted individual would receive from a photo.
This means sometimes adding descriptions about lighting, color, background details, and other information used in photography when the purpose of the photograph is to create emotional impact.
Test designs with users from all backgrounds
Testing designs will all types of users is the main takeaway from the book Building for Everyone by Annie Jean-Baptiste.
In any design, we’re making assumptions. Testing designs with users is a way to learn which assumptions are wrong.
We can make some educated guesses about what pieces of a design might benefit from testing with a broad range of users, or which pieces might be okay to test with users of a more narrow background. But those guesses are, in themselves, assumptions that we’re making.
The main argument from the book is to include people from minority or traditionally ignored backgrounds regularly in all phases of research.
It does not need to be the focus of every research project — it could be just one or two people of a 5 to 7 person study — but even that small amount of deliberate effort to have diversity in recruited participants can have a huge impact in improving designs for all users.
This allows you to learn more information about the context people might use your designs, how your designs might be interpreted or misinterpreted, find errors or design flaws as early as possible, and make informed decisions every step of the way along the design process.
Thanks for reading!
Hopefully this was helpful!
The top of this page has links to additional resources for learning more about inclusive design and accessibility.
If you want to get in touch to talk about design, feel free to send an email to joey.pearlman@gmail.com .
Accessible design fundamentals
This article was also published in UX Planet
Accessibility is an important topic for every designer to learn about, but sometimes it gets shrouded in a mystique of “important but complicated”.
Here’s some common framing about how contributions which originate from accessibility initiatives end up benefit everyone:
On the other hand, not taking accessibility into consideration can lead to disastrous outcomes, such as:
I’ve seen a lot of talks about accessibility that sort of advocate for it without providing too many practical steps to take, so I wanted to take a stab at writing up some information that I’ve found helpful to learn.
Most of this information comes from a handful of sources:
Additional resources can be found here:
Making text readable
The most common accessibility issue is unreadable elements in a design.
Text and typography can seem like an overwhelming world, where only experts with decades of experience know what’s going on.
In reality, understanding some best practices and typical values to use can get you very far.
Following these guidelines can help you catch a lot of low-hanging fruit early in a product’s design.
An aside:
WCAG’s requirements for typography seem a bit odd to me for a few reasons:
they don’t follow their own guidelines.
they recommend increasing letter spacing (tracking) by a huge amount, which I don’t understand. For body text, it’s more common to see letter spacing reduced by a very, very small amount, such as 0.01em.
spacing between paragraphs is more closely related to line height than font size. From WCAG 2.0 to 2.1, they changed their recommendation for paragraph spacing from being based on line height to being based on font size, which seems like an odd recommendation.
they make universal recommendations for type settings, which doesn’t take into account that different fonts will need different settings applied to achieve the same relative size, spacing, etc.
I wanted to make sure to call out WCAG’s guidelines for awareness, because a lot of what I’ve written below differs from WCAG’s guidelines.
Most of my recommendations for type are based on the book Web Typography by Richard Rutter, which in turn is based on The Elements of Typographic Style by Robert Bringhurst.
Font sizes
Font size for body text — which, loosely, can be thought of as any lengthy block of text, such as paragraphs — should not be below 16px on mobile, tablet, or desktop.
16px is a minimum. Body text can be larger than 16px.
On mobile, tablets, or desktop, font can be smaller than 16px, but only in situations where it is not body copy.
When it’s okay to use smaller font sizes
Some examples of text which is not body copy are elements like button labels, or labels for other interactive components on the page.
Making those elements have text smaller than body copy is done to create a hierarchy of text within the page.
This helps prevent things like labels for a text input field from being confused as body copy that might be placed near the field.
Even in these situations, font below 14px should be approached warily.
Why small font size can be a problem
Making text too small makes it difficult, or impossible, to read the words on the screen.
As devices get farther away from a person’s eyes, text appears smaller, and needs to be larger in order to be read.
This means that UI seen on a television — such as interfaces for smart devices, or paragraphs of text within video games — need to appear larger than the same design for a phone or tablet.
Line lengths
The ideal line length for body copy is about 70 characters long.
The specific number varies from font to font, but the “good number” range is somewhere between 50 characters to 75 characters. Anywhere in that range is pretty safe to use.
This issue mostly applies to devices such as laptops and desktops, where monitors can be ultra-wide, and unconstrained text can span the full width of a browser.
An example of a website designed in full width is https://en.wikipedia.org/wiki/Main_Page, which does not use any limits for line length.
On tablets and phones, there’s often not enough width on the device for a line to run longer than 70 characters, so capping line lengths is usually not an issue on smaller breakpoints.
Broadly, there are two ways to constrain line lengths:
Specify max-width for text
In HTML, a unit of size called “ch” exists. This can be used to specify the size of things according to how many characters it takes up.
A property called “max-width” also exists. This can be used to prevent something from growing larger than a specific dimension.
These elements can be defined, so that body text (which is likely anything with a <p> tag) is capped at 70ch.
This has the effect of preventing any line of a paragraph from being larger than 70 characters.
“rem” or “em” units can be used instead of “ch” for essentially the same effect.
Specify container size
Instead of specifying a specific width value to a paragraph, instead you might have the line run from start-to-end of a component which the text is contained inside of, such as a card.
In this case, the card would be a container for the text, and the text’s width would be determined by how large the card is designed.
Because of this, it’s important to size the container to have an appropriate width to prevent text from overflowing past a readable line length.
This is a slightly more complicated situation than specifying the width of the text itself, because the card will also have things like internal padding that will impact line length.
Some ways to handle this are by specifying specific container dimensions at different breakpoints. For example — on desktop, a card might have a width of 600px. On mobile, it might have a width of 200px.
Things like percentage units, which size things as a percentage of the space available, can also be used and cause containers or text to “flex” — which means shrink, or grow, or shift layout from side-by-side to stacked-on-top depending on space available.
There’s no one correct or best way of sizing things on the web. Being aware of these considerations, and testing designs on different device breakpoints, can help prevent unwanted issues.
Why long line lengths can be a problem
When humans read text, the eyes bounce along the line of text that they are reading. This is called a saccade.
The eye’s focus mostly bounces forward, progressing through the text, but it also bounces backwards to re-read pieces its already read. These eye movements on unconscious, and are not noticed by most people as they do it.
When people get to a new line of text, the eye moves from one end of the text block all the way back to the other side.
Long lines of text create extra movement that eye needs to take. This can make it difficult to keep track of what line of text someone just finished reading, and make it difficult to find the next line of text to read.
A long line length can mean that the person reading the text will accidentally re-read text they’ve already read, or skip over the line that they meant to read next.
These problems are exacerbated for people who have dyslexia, which is about 20% of the US population according to the NIH.
Placing reasonable constraints on line length help reduce these problems.
Line height
Line height determines the spacing between lines of text, and is usually represented as either a multiple or percentage of font size.
For body copy, ideal numbers for line height are typically 1.2 to 1.5 times font size, or 120% to 150% of font size.
The specific values to use will vary from font to font, but anywhere within this range is typically safe. This is also a fairly easy setting to adjust in HTML/CSS, so it’s something simple to iterate on as needed.
Products where the primary purpose is for people to read articles, such as blogs or newspapers, will tend to use the larger range of those ideal values.
For example, www.nytimes.com uses 150% for their line height, and www.medium.com goes a step further than the typical range by using 160% for their line height. Both examples are based on their desktop breakpoints — they may use different line heights on different devices.
Larger font sizes need smaller line heights
Larger text, such as headings, will need to use shorter line heights. Because line heights are a multiple of font size, this means that as text grows larger, line heights grow larger as well.
For something like a 48px heading, a line height sized to 150% will create so much space that each line of the heading will appear disconnected from the line above it.
In these cases, line heights of about 80% to 120% are safe to play around with. The specific number to use will depend on the font.
An appropriate setting should make headlines that span 2 or 3 lines appear connected, without creating any overlapping letters between the lines.
One specific element to pay attention to is how ascenders (such as the top pieces of the letters “b” and “h”) interact with descenders (such as the bottom pieces of the letters “y” and “p”). Typically, if these overlap between lines, then line-height should be increased.
Why small line height can be a problem
Similar to line length, a small line height can make readers lose their place when their eyes shift from one edge of the text to the other.
Additionally, a small line height can make it difficult to focus on any one specific line of text. This can cause the reader to mistakenly read letters from a line above or below the line of text that they are trying to focus on.
These problems are exacerbated for people who have dyslexia, which is about 20% of the US population according to the NIH.
Using reasonable values for line height help reduce these problems.
Paragraph spacing
Paragraph spacing is the distance from the bottom of one paragraph to the top of the next paragraph.
Safe values to use as a distance between paragraphs are:
half the line height for tighter spacing
equal to line height for larger spacing
up to 200% line height for extra large spacing
In HTML/CSS, paragraphs pacing will usually be done with the “margin-bottom” property assigned to paragraphs (elements using the <p> tag), or with a combination of “margin-top” and “margin-bottom” properties.
By default, most browsers will set paragraphs to have a bottom and top margin of 1em (which will likely be 16px) already added to the paragraph. This means that there will be a 32px gap between paragraphs, which may be larger than ideal.
Depending on the tool used to create the design, these default values may not be applied.
One example where this issue can occur is when designing things using the no-code web design tool Framer. In that tool, some extra effort is required to control space between paragraphs.
Another example is when working in Figma. Figma uses an abstraction called “Paragraph spacing” to control this property. There is not an equivalent property in HTML/CSS. The actual web version will likely use top and bottom margin properties instead of Figma’s “Paragraph spacing”.
As a sidenote regarding Figma, paragraph spacing values assigned to text will not appear as a value in the Inspect tool. These values need to be annotated for developers to be able to see it.
Why poor paragraph spacing can be a problem
Similar to line height, paragraphs spaced too close together can make it difficult to separate one paragraph from the next. It can make users feel “claustrophobic”, or feel overwhelmed by the amount of text on a page.
Paragraphs too far apart can make it feel like paragraphs are disconnected to each other. This might also make it difficult to refer to a piece of information that’s contained in one paragraph alongside a piece of information from the paragraph above or below it.
Paragraphs placed very, very far apart can cause someone to think they’ve reached the end of an article when more content exists on the page. This can occur if elements like images or video fail to load in, because of either internet connection issues, content blockers, or some other reason.
Color contrast
Text color has two elements — the color of the background that the text is set on, and the color of the text itself.
White text on a white background, or black text on a black background, will make the text appear invisible and impossible to read.
So that text will appear visible and readable, light text should always be set against on a dark background, and dark text should always be set against a light background.
The amount of difference between a text’s lightness or darkness and a background’s lightness or darkness is called “contrast”.
Black text on a white background, or white text on a black background, is the highest level of contrast possible.
There are tools created for measuring how much a text and its background contrast with each other. One of the most popular tools is https://webaim.org/resources/contrastchecker/ , and a Figma plugin which does the same thing is the A11y - Color Contrast Checker https://www.figma.com/community/plugin/733159460536249875 .
For AA accessibility, normal text such as paragraphs or body text requires a contrast ratio of at least 4.5:1 , and large text such as headlines requires a contrast ratio of 3:1.
How to control contrast
One way to intentionally control contrast between colors is by designing using the HSL (hue, saturation, lightness) or HSB (hue, saturation, brightness) color models.
Both of these models have an explicit value (Lightness for HSL, or Brightness for HSB) that can be raised or lowered to make a color lighter or darker.
Using HSL or HSB to raise or lower the Lightness or Brightness of colors can simplify the work of creating contrast between elements.
Anecdotally, HSL seems to be the more common model of the two options, and I find Figma’s implementation of HSL easier to work with than HSB.
HSL in Figma basically uses Lightness as the Y-axis in the color picker, and Saturation as the X-axis, which gives the color picker a predictability that I don’t think the other color models offer.
HSB in Figma has Brightness cross both the X and Y axis of the color picker, which I find more confusing to work with.
Do not rely solely on contrast checkers
Sometimes, the tools can fail.
In some situations, contrast checkers will provide a passing grade for text that obviously is not readable. For information about why this happens, see Henrique Gusso’s talk from Config Europe 2020 or Lisa Charlotte Muth’s article about color contrast.
Upcoming changes to WCAG will change the color contrast algorithm to provide more accurate readings in situations where the current algorithm fails. However, that change is still a way off.
While the new model can be used today, its use is not very widespread, and even with the change, it’s still important to be aware that these tools can fail.
A good, simple safety check is to just look away from your design, and then look back at it. If things seem blended together, or you need to squint at all to read the text, then something should probably change to make the text more readable.
Why poor color contrast can be a problem
If users cannot see the content on your page, they cannot access it.
Using lighter-colored font is fine, and often necessary. Having text that is a little bit “greyed out” compared to the primary text color on the page is a great way to create hierarchy.
Some spots where lighter colored text might be used are for things like help-text in a form field, or other supporting text on a page.
However, even when intentionally de-emphasizing text, it still needs to pass accessibility guidelines. If users cannot read help-text for a form, then the help-text is not very helpful.
Making content understandable
The above information about typography is focused on foundational elements of a design that allow users to read without difficulty.
To make information understandable, the important piece is the actual words on the page.
Chunk up information with headings and sub-headings
Headings and subheadings are how all users scan through a page.
For users who interpret the page visually, headings allow them to see where each section begins or ends, and get an idea of the information contained in the different sections of a page.
Similarly, accessibility tools used by people with trouble seeing will use headings and subheadings to “announce” the different sections of the page.
Proper use of headings and subheadings
Headings are titles above sections of a page. Usually, there are multiple heading styles on a page. They’re often called named like H1, H2, H3, and so on.
Headings are both a design element and a web element.
In design, headings are larger pieces of text that help build a hierarchy for information. People can spot the big pieces of text, and then can read the normal-sized text below the heading to learn more about the topic.
On the web, headings are elements that help browsers and accessibility tools understand how to interpret the page.
Headings can have subheadings nested inside of them. This might be thought of sort of like indents in a bulleted list, or how things are stacked in a Russian nesting doll.
Proper use of headings will work something like this:
<H1>
<H2>
<H3>
<H2>
<H3>
<H4>
<H2>
In this example, bullets are used to show an example of nesting. An H4 is contained within an H3, an H3 is contained within an H2, and H2’s are contained within the page’s H1. Heading levels follow a predictable order, and there’s never a jump from something like an H1 to an H3, or an H2 to an H4.
This example does not indicate styling. Headings should not be indented like bullet points.
This type of nesting is helpful for visual readers, because it creates an intuitive sense of where to find different pieces of information as the page is scanned.
This type of nesting is also very helpful for readers using accessibility tools like screen readers. Those tools navigate the page by announcing headings and jumping between headings on the page.
In that case, having descriptive headlines and proper nesting of headings becomes incredibly important for someone to quickly scan through the page and find the information they are looking for.
An example with actual content might look like this:
Getting a driver’s license
Making an appointment
What to do if you can’t schedule an appointment
Requirements for driver’s license
Necessary documents
How to request missing documents
When you will receive your driver’s license
For additional information, see: https://readabilityguidelines.co.uk/content-design/headings-titles/
Use simple, clear language
When writing, it’s very easy to communicate with too many words (this page may be one example of that).
When creating content, it does not matter how accurate your content is if the audience that you are writing for cannot understand it.
To make sure that your ideas are being communicated as effectively as possible, there’s a few standard guidelines to follow:
Paragraphs should not be longer than 2 or 3 sentences
Break up big ideas into separate, smaller, digestible pieces
Use the simplest, most common words possible
When writing anything, it’s good to think about this fact from https://readabilityguidelines.co.uk/clear-language/low-literacy-users/
In America, 43% of the population has low literacy as defined by the US Department of Education's National Assessment of Adult Literacy.
When writing content for the web, you should plan for it to be consumed by both experts and amateurs, people who grew up with books in their homes and people who grew up with fewer opportunities to read, and by people who are native speakers as well as people who have learned the language later in life.
Simplify as much as possible, eliminate any unnecessary information, and reduce messages to the main idea you’re trying to tell the user.
For additional information, see: https://readabilityguidelines.co.uk/clear-language/
Use alt-text, captioning, and transcripts
When displaying images, audio, or video, always provide an alternative method of providing the same information for people who cannot access the image/audio/video.
This does not only help people who have difficulty seeing. Google uses this information when ranking SEO, so taking the time to add this content also helps the business by increasing the number of people accessing pages and decreasing things like calls to support staff.
Things like transcripts also allows users do precise searches in their browser, through hotkeys like cmd+F or ctrl+F, to find specific information.
For example, Kristina Halverson’s The Content Strategy Podcast includes transcripts for every episode of the podcast. Because of this, it’s simple for any user to quickly find any episode that mentions specific topics, such as content audits, design maturity, or other methods and strategies.
Writing alt-text
The normal question to ask after learning about alt-text is “What makes good alt-text?”
View Haben Girma’s presentation at Axe-Con 2021 to hear someone who relies on alt-text and transcripts to interpret the web talk about the types of descriptions they like to have in alt-text.
In her presentation, she asks for alt-text to be as descriptive as necessary to give the same information that a sighted individual would receive from a photo.
This means sometimes adding descriptions about lighting, color, background details, and other information used in photography when the purpose of the photograph is to create emotional impact.
Test designs with users from all backgrounds
Testing designs will all types of users is the main takeaway from the book Building for Everyone by Annie Jean-Baptiste.
In any design, we’re making assumptions. Testing designs with users is a way to learn which assumptions are wrong.
We can make some educated guesses about what pieces of a design might benefit from testing with a broad range of users, or which pieces might be okay to test with users of a more narrow background. But those guesses are, in themselves, assumptions that we’re making.
The main argument from the book is to include people from minority or traditionally ignored backgrounds regularly in all phases of research.
It does not need to be the focus of every research project — it could be just one or two people of a 5 to 7 person study — but even that small amount of deliberate effort to have diversity in recruited participants can have a huge impact in improving designs for all users.
This allows you to learn more information about the context people might use your designs, how your designs might be interpreted or misinterpreted, find errors or design flaws as early as possible, and make informed decisions every step of the way along the design process.
Thanks for reading!
Hopefully this was helpful!
The top of this page has links to additional resources for learning more about inclusive design and accessibility.
If you want to get in touch to talk about design, feel free to send an email to joey.pearlman@gmail.com .
Accessible design fundamentals
This article was also published in UX Planet
Accessibility is an important topic for every designer to learn about, but sometimes it gets shrouded in a mystique of “important but complicated”.
Here’s some common framing about how contributions which originate from accessibility initiatives end up benefit everyone:
On the other hand, not taking accessibility into consideration can lead to disastrous outcomes, such as:
I’ve seen a lot of talks about accessibility that sort of advocate for it without providing too many practical steps to take, so I wanted to take a stab at writing up some information that I’ve found helpful to learn.
Most of this information comes from a handful of sources:
Additional resources can be found here:
Making text readable
The most common accessibility issue is unreadable elements in a design.
Text and typography can seem like an overwhelming world, where only experts with decades of experience know what’s going on.
In reality, understanding some best practices and typical values to use can get you very far.
Following these guidelines can help you catch a lot of low-hanging fruit early in a product’s design.
An aside:
WCAG’s requirements for typography seem a bit odd to me for a few reasons:
they don’t follow their own guidelines.
they recommend increasing letter spacing (tracking) by a huge amount, which I don’t understand. For body text, it’s more common to see letter spacing reduced by a very, very small amount, such as 0.01em.
spacing between paragraphs is more closely related to line height than font size. From WCAG 2.0 to 2.1, they changed their recommendation for paragraph spacing from being based on line height to being based on font size, which seems like an odd recommendation.
they make universal recommendations for type settings, which doesn’t take into account that different fonts will need different settings applied to achieve the same relative size, spacing, etc.
I wanted to make sure to call out WCAG’s guidelines for awareness, because a lot of what I’ve written below differs from WCAG’s guidelines.
Most of my recommendations for type are based on the book Web Typography by Richard Rutter, which in turn is based on The Elements of Typographic Style by Robert Bringhurst.
Font sizes
Font size for body text — which, loosely, can be thought of as any lengthy block of text, such as paragraphs — should not be below 16px on mobile, tablet, or desktop.
16px is a minimum. Body text can be larger than 16px.
On mobile, tablets, or desktop, font can be smaller than 16px, but only in situations where it is not body copy.
When it’s okay to use smaller font sizes
Some examples of text which is not body copy are elements like button labels, or labels for other interactive components on the page.
Making those elements have text smaller than body copy is done to create a hierarchy of text within the page.
This helps prevent things like labels for a text input field from being confused as body copy that might be placed near the field.
Even in these situations, font below 14px should be approached warily.
Why small font size can be a problem
Making text too small makes it difficult, or impossible, to read the words on the screen.
As devices get farther away from a person’s eyes, text appears smaller, and needs to be larger in order to be read.
This means that UI seen on a television — such as interfaces for smart devices, or paragraphs of text within video games — need to appear larger than the same design for a phone or tablet.
Line lengths
The ideal line length for body copy is about 70 characters long.
The specific number varies from font to font, but the “good number” range is somewhere between 50 characters to 75 characters. Anywhere in that range is pretty safe to use.
This issue mostly applies to devices such as laptops and desktops, where monitors can be ultra-wide, and unconstrained text can span the full width of a browser.
An example of a website designed in full width is https://en.wikipedia.org/wiki/Main_Page, which does not use any limits for line length.
On tablets and phones, there’s often not enough width on the device for a line to run longer than 70 characters, so capping line lengths is usually not an issue on smaller breakpoints.
Broadly, there are two ways to constrain line lengths:
Specify max-width for text
In HTML, a unit of size called “ch” exists. This can be used to specify the size of things according to how many characters it takes up.
A property called “max-width” also exists. This can be used to prevent something from growing larger than a specific dimension.
These elements can be defined, so that body text (which is likely anything with a <p> tag) is capped at 70ch.
This has the effect of preventing any line of a paragraph from being larger than 70 characters.
“rem” or “em” units can be used instead of “ch” for essentially the same effect.
Specify container size
Instead of specifying a specific width value to a paragraph, instead you might have the line run from start-to-end of a component which the text is contained inside of, such as a card.
In this case, the card would be a container for the text, and the text’s width would be determined by how large the card is designed.
Because of this, it’s important to size the container to have an appropriate width to prevent text from overflowing past a readable line length.
This is a slightly more complicated situation than specifying the width of the text itself, because the card will also have things like internal padding that will impact line length.
Some ways to handle this are by specifying specific container dimensions at different breakpoints. For example — on desktop, a card might have a width of 600px. On mobile, it might have a width of 200px.
Things like percentage units, which size things as a percentage of the space available, can also be used and cause containers or text to “flex” — which means shrink, or grow, or shift layout from side-by-side to stacked-on-top depending on space available.
There’s no one correct or best way of sizing things on the web. Being aware of these considerations, and testing designs on different device breakpoints, can help prevent unwanted issues.
Why long line lengths can be a problem
When humans read text, the eyes bounce along the line of text that they are reading. This is called a saccade.
The eye’s focus mostly bounces forward, progressing through the text, but it also bounces backwards to re-read pieces its already read. These eye movements on unconscious, and are not noticed by most people as they do it.
When people get to a new line of text, the eye moves from one end of the text block all the way back to the other side.
Long lines of text create extra movement that eye needs to take. This can make it difficult to keep track of what line of text someone just finished reading, and make it difficult to find the next line of text to read.
A long line length can mean that the person reading the text will accidentally re-read text they’ve already read, or skip over the line that they meant to read next.
These problems are exacerbated for people who have dyslexia, which is about 20% of the US population according to the NIH.
Placing reasonable constraints on line length help reduce these problems.
Line height
Line height determines the spacing between lines of text, and is usually represented as either a multiple or percentage of font size.
For body copy, ideal numbers for line height are typically 1.2 to 1.5 times font size, or 120% to 150% of font size.
The specific values to use will vary from font to font, but anywhere within this range is typically safe. This is also a fairly easy setting to adjust in HTML/CSS, so it’s something simple to iterate on as needed.
Products where the primary purpose is for people to read articles, such as blogs or newspapers, will tend to use the larger range of those ideal values.
For example, www.nytimes.com uses 150% for their line height, and www.medium.com goes a step further than the typical range by using 160% for their line height. Both examples are based on their desktop breakpoints — they may use different line heights on different devices.
Larger font sizes need smaller line heights
Larger text, such as headings, will need to use shorter line heights. Because line heights are a multiple of font size, this means that as text grows larger, line heights grow larger as well.
For something like a 48px heading, a line height sized to 150% will create so much space that each line of the heading will appear disconnected from the line above it.
In these cases, line heights of about 80% to 120% are safe to play around with. The specific number to use will depend on the font.
An appropriate setting should make headlines that span 2 or 3 lines appear connected, without creating any overlapping letters between the lines.
One specific element to pay attention to is how ascenders (such as the top pieces of the letters “b” and “h”) interact with descenders (such as the bottom pieces of the letters “y” and “p”). Typically, if these overlap between lines, then line-height should be increased.
Why small line height can be a problem
Similar to line length, a small line height can make readers lose their place when their eyes shift from one edge of the text to the other.
Additionally, a small line height can make it difficult to focus on any one specific line of text. This can cause the reader to mistakenly read letters from a line above or below the line of text that they are trying to focus on.
These problems are exacerbated for people who have dyslexia, which is about 20% of the US population according to the NIH.
Using reasonable values for line height help reduce these problems.
Paragraph spacing
Paragraph spacing is the distance from the bottom of one paragraph to the top of the next paragraph.
Safe values to use as a distance between paragraphs are:
half the line height for tighter spacing
equal to line height for larger spacing
up to 200% line height for extra large spacing
In HTML/CSS, paragraphs pacing will usually be done with the “margin-bottom” property assigned to paragraphs (elements using the <p> tag), or with a combination of “margin-top” and “margin-bottom” properties.
By default, most browsers will set paragraphs to have a bottom and top margin of 1em (which will likely be 16px) already added to the paragraph. This means that there will be a 32px gap between paragraphs, which may be larger than ideal.
Depending on the tool used to create the design, these default values may not be applied.
One example where this issue can occur is when designing things using the no-code web design tool Framer. In that tool, some extra effort is required to control space between paragraphs.
Another example is when working in Figma. Figma uses an abstraction called “Paragraph spacing” to control this property. There is not an equivalent property in HTML/CSS. The actual web version will likely use top and bottom margin properties instead of Figma’s “Paragraph spacing”.
As a sidenote regarding Figma, paragraph spacing values assigned to text will not appear as a value in the Inspect tool. These values need to be annotated for developers to be able to see it.
Why poor paragraph spacing can be a problem
Similar to line height, paragraphs spaced too close together can make it difficult to separate one paragraph from the next. It can make users feel “claustrophobic”, or feel overwhelmed by the amount of text on a page.
Paragraphs too far apart can make it feel like paragraphs are disconnected to each other. This might also make it difficult to refer to a piece of information that’s contained in one paragraph alongside a piece of information from the paragraph above or below it.
Paragraphs placed very, very far apart can cause someone to think they’ve reached the end of an article when more content exists on the page. This can occur if elements like images or video fail to load in, because of either internet connection issues, content blockers, or some other reason.
Color contrast
Text color has two elements — the color of the background that the text is set on, and the color of the text itself.
White text on a white background, or black text on a black background, will make the text appear invisible and impossible to read.
So that text will appear visible and readable, light text should always be set against on a dark background, and dark text should always be set against a light background.
The amount of difference between a text’s lightness or darkness and a background’s lightness or darkness is called “contrast”.
Black text on a white background, or white text on a black background, is the highest level of contrast possible.
There are tools created for measuring how much a text and its background contrast with each other. One of the most popular tools is https://webaim.org/resources/contrastchecker/ , and a Figma plugin which does the same thing is the A11y - Color Contrast Checker https://www.figma.com/community/plugin/733159460536249875 .
For AA accessibility, normal text such as paragraphs or body text requires a contrast ratio of at least 4.5:1 , and large text such as headlines requires a contrast ratio of 3:1.
How to control contrast
One way to intentionally control contrast between colors is by designing using the HSL (hue, saturation, lightness) or HSB (hue, saturation, brightness) color models.
Both of these models have an explicit value (Lightness for HSL, or Brightness for HSB) that can be raised or lowered to make a color lighter or darker.
Using HSL or HSB to raise or lower the Lightness or Brightness of colors can simplify the work of creating contrast between elements.
Anecdotally, HSL seems to be the more common model of the two options, and I find Figma’s implementation of HSL easier to work with than HSB.
HSL in Figma basically uses Lightness as the Y-axis in the color picker, and Saturation as the X-axis, which gives the color picker a predictability that I don’t think the other color models offer.
HSB in Figma has Brightness cross both the X and Y axis of the color picker, which I find more confusing to work with.
Do not rely solely on contrast checkers
Sometimes, the tools can fail.
In some situations, contrast checkers will provide a passing grade for text that obviously is not readable. For information about why this happens, see Henrique Gusso’s talk from Config Europe 2020 or Lisa Charlotte Muth’s article about color contrast.
Upcoming changes to WCAG will change the color contrast algorithm to provide more accurate readings in situations where the current algorithm fails. However, that change is still a way off.
While the new model can be used today, its use is not very widespread, and even with the change, it’s still important to be aware that these tools can fail.
A good, simple safety check is to just look away from your design, and then look back at it. If things seem blended together, or you need to squint at all to read the text, then something should probably change to make the text more readable.
Why poor color contrast can be a problem
If users cannot see the content on your page, they cannot access it.
Using lighter-colored font is fine, and often necessary. Having text that is a little bit “greyed out” compared to the primary text color on the page is a great way to create hierarchy.
Some spots where lighter colored text might be used are for things like help-text in a form field, or other supporting text on a page.
However, even when intentionally de-emphasizing text, it still needs to pass accessibility guidelines. If users cannot read help-text for a form, then the help-text is not very helpful.
Making content understandable
The above information about typography is focused on foundational elements of a design that allow users to read without difficulty.
To make information understandable, the important piece is the actual words on the page.
Chunk up information with headings and sub-headings
Headings and subheadings are how all users scan through a page.
For users who interpret the page visually, headings allow them to see where each section begins or ends, and get an idea of the information contained in the different sections of a page.
Similarly, accessibility tools used by people with trouble seeing will use headings and subheadings to “announce” the different sections of the page.
Proper use of headings and subheadings
Headings are titles above sections of a page. Usually, there are multiple heading styles on a page. They’re often called named like H1, H2, H3, and so on.
Headings are both a design element and a web element.
In design, headings are larger pieces of text that help build a hierarchy for information. People can spot the big pieces of text, and then can read the normal-sized text below the heading to learn more about the topic.
On the web, headings are elements that help browsers and accessibility tools understand how to interpret the page.
Headings can have subheadings nested inside of them. This might be thought of sort of like indents in a bulleted list, or how things are stacked in a Russian nesting doll.
Proper use of headings will work something like this:
<H1>
<H2>
<H3>
<H2>
<H3>
<H4>
<H2>
In this example, bullets are used to show an example of nesting. An H4 is contained within an H3, an H3 is contained within an H2, and H2’s are contained within the page’s H1. Heading levels follow a predictable order, and there’s never a jump from something like an H1 to an H3, or an H2 to an H4.
This example does not indicate styling. Headings should not be indented like bullet points.
This type of nesting is helpful for visual readers, because it creates an intuitive sense of where to find different pieces of information as the page is scanned.
This type of nesting is also very helpful for readers using accessibility tools like screen readers. Those tools navigate the page by announcing headings and jumping between headings on the page.
In that case, having descriptive headlines and proper nesting of headings becomes incredibly important for someone to quickly scan through the page and find the information they are looking for.
An example with actual content might look like this:
Getting a driver’s license
Making an appointment
What to do if you can’t schedule an appointment
Requirements for driver’s license
Necessary documents
How to request missing documents
When you will receive your driver’s license
For additional information, see: https://readabilityguidelines.co.uk/content-design/headings-titles/
Use simple, clear language
When writing, it’s very easy to communicate with too many words (this page may be one example of that).
When creating content, it does not matter how accurate your content is if the audience that you are writing for cannot understand it.
To make sure that your ideas are being communicated as effectively as possible, there’s a few standard guidelines to follow:
Paragraphs should not be longer than 2 or 3 sentences
Break up big ideas into separate, smaller, digestible pieces
Use the simplest, most common words possible
When writing anything, it’s good to think about this fact from https://readabilityguidelines.co.uk/clear-language/low-literacy-users/
In America, 43% of the population has low literacy as defined by the US Department of Education's National Assessment of Adult Literacy.
When writing content for the web, you should plan for it to be consumed by both experts and amateurs, people who grew up with books in their homes and people who grew up with fewer opportunities to read, and by people who are native speakers as well as people who have learned the language later in life.
Simplify as much as possible, eliminate any unnecessary information, and reduce messages to the main idea you’re trying to tell the user.
For additional information, see: https://readabilityguidelines.co.uk/clear-language/
Use alt-text, captioning, and transcripts
When displaying images, audio, or video, always provide an alternative method of providing the same information for people who cannot access the image/audio/video.
This does not only help people who have difficulty seeing. Google uses this information when ranking SEO, so taking the time to add this content also helps the business by increasing the number of people accessing pages and decreasing things like calls to support staff.
Things like transcripts also allows users do precise searches in their browser, through hotkeys like cmd+F or ctrl+F, to find specific information.
For example, Kristina Halverson’s The Content Strategy Podcast includes transcripts for every episode of the podcast. Because of this, it’s simple for any user to quickly find any episode that mentions specific topics, such as content audits, design maturity, or other methods and strategies.
Writing alt-text
The normal question to ask after learning about alt-text is “What makes good alt-text?”
View Haben Girma’s presentation at Axe-Con 2021 to hear someone who relies on alt-text and transcripts to interpret the web talk about the types of descriptions they like to have in alt-text.
In her presentation, she asks for alt-text to be as descriptive as necessary to give the same information that a sighted individual would receive from a photo.
This means sometimes adding descriptions about lighting, color, background details, and other information used in photography when the purpose of the photograph is to create emotional impact.
Test designs with users from all backgrounds
Testing designs will all types of users is the main takeaway from the book Building for Everyone by Annie Jean-Baptiste.
In any design, we’re making assumptions. Testing designs with users is a way to learn which assumptions are wrong.
We can make some educated guesses about what pieces of a design might benefit from testing with a broad range of users, or which pieces might be okay to test with users of a more narrow background. But those guesses are, in themselves, assumptions that we’re making.
The main argument from the book is to include people from minority or traditionally ignored backgrounds regularly in all phases of research.
It does not need to be the focus of every research project — it could be just one or two people of a 5 to 7 person study — but even that small amount of deliberate effort to have diversity in recruited participants can have a huge impact in improving designs for all users.
This allows you to learn more information about the context people might use your designs, how your designs might be interpreted or misinterpreted, find errors or design flaws as early as possible, and make informed decisions every step of the way along the design process.
Thanks for reading!
Hopefully this was helpful!
The top of this page has links to additional resources for learning more about inclusive design and accessibility.
If you want to get in touch to talk about design, feel free to send an email to joey.pearlman@gmail.com .