“An accessible website won’t be beautiful”… really?!

Fortunately, accessibility has been discussed a lot lately, but evidently, some biases and myths are still to be debunked.

Chiara Cielo Longobardi (she/her)
10 min readNov 27, 2023

This article was translated with the help of ChatGPT 3.5. See the original in italian →

I heard the phrase ‘An accessible website won’t be beautiful’ in person. In 2023. During a meeting. With consultants. Designers.

I hope that the person who said it only meant to clarify that there wouldn’t be proposals for vibrant color palettes, non-standard elements, excessive animations, and interactions, etc. However, the approving nods of some people in the meeting still sent a shiver down my spine, and the awareness that sharing some reflections could only be a good thing.

Let’s start with some (theoretically useless) premises:

1- A website is accessible not only because those with some form of visual limitation can use it without issues*. Those in need of an accessible site may have hearing impairments, be unable to perform certain movements or actions, or may have cognitive disabilities. Accessibility is thus provided through subtitles, audio transcriptions, adequate time for completing an action, clear and explanatory texts with short sentences with no technical jargon, the ability for users to control animations, the presence of feedback for actions, and many other details that have little to do with the aesthetic aspect of a site.

*A visual impairment can range from total blindness to partial vision (such as tunnel vision, macular degeneration, or the more common cataracts). It’s also important to consider that approximately 75% of adults use visual correction (source: World report on vision, WHO).

2- An accessible website is not “better” only for people with some form of disability, but it is also beneficial for anyone using the site, considering both users’ temporary disabilities (recovering from eye surgery, having a bandaged hand) and unfavorable situations (a noisy or overly sunny environment, poor connectivity). In general, however, an accessible site is more usable and easier to navigate for all individuals (due to clearer texts, information organized hierarchically, more specific feedback, etc.).

3- Ensuring that a website is accessible is not an optional choice but a matter of empathy and respect toward its users (and in many sectors, it is legally mandated). It is even a good marketing strategy: if a site is not accessible, the competitor with an accessible site stands to gain!

4- What does ‘beautiful’ mean? How do we measure beauty? Our aesthetic choices may not necessarily be universal and shared by all users.

So an accessible website can also be interesting and visually pleasing?

The answer is definitely yes, and without any particular constraints and compromises (which, even if there were any, should not be an obstacle to creativity but merely boundaries within which to express it!).

Here are some aspects to focus on when designing a ‘beautiful and accessible’ website:

  1. Color;
  2. Typography;
  3. Headings;
  4. Images, icons, and multimedia;
  5. Focus;
  6. Position and proximity.

Some aspects are obvious, others less so. Below, you’ll find some insights on each of these aspects, along with some useful tools or readings. In no case is the topic exhaustible in a few words, but I hope they can be a helpful starting point. I invite you to read the ones that seem most interesting to you, in the order you prefer (at the end of each section, you’ll find a way to return to the list).

Beautiful and accessible

If you’re not familiar with Stephanie Walter, take the opportunity to remedy that: on her website, she consistently shares interesting insights on accessibility, and her site is a true example of ‘beautiful and accessible’:

Un piacevole sito con illustrazioni chiare e pulite e una palette giallo-viola piacevole a vedersi.
A screenshot of Stephanie Walter‘s website

And if that’s not enough, here are a couple of collections of accessible websites:

1. Color

Of course. The first thing that comes to mind when thinking about the aesthetic aspect of a website and accessibility is an accessible color palette, one that ensures sufficient contrast between text (or other graphic elements) and the background, and is also suitable for the needs of color-blind people.

Regarding contrast, the goal according to official guidelines (WCAG 2.2) is to achieve a minimum contrast (AA) with the background: 4.5:1 for text below 24px, 3:1 for text larger than 24px, bold text above 19px, icons, and other UI elements. There are (countless) tools that help in choosing combinations with sufficient contrast (see below) or that help us understand if the contrast is maintained between elements on a web page (for example, Wave).

A summary table of the above: contrast 4.5:1 for text below 24px, 3:1 for text larger than 24px, bold text above 19px, icons, and other UI elements.
Image shared by Oliver Schöndorfer in this article: https://pimpmytype.com/color-contrast/

Simple? Not exactly, actually. The WCAG 2.2 contrast is calculated using a mathematical model that analyzes the ratio between the luminance (in short: the intensity of emitted light) of the text color and the background color, without considering the complexity of human vision. As a result, some combinations considered ‘accessible’ by tools based on this model are not truly accessible.

Untill a new update of the guidelines (WCAG 3.0?), other models are being discussed, including the APCA (Accessible Perceptual Contrast Algorithm) proposed by Andrew Somers.

Here are some examples of the difference between the two models:”

Some text-background contrasts compared. Some that are easier to discern do not pass the WCAG, while others that are less legible do pass.
Examples taken from the article: https://blog.datawrapper.de/color-contrast-check-data-vis-wcag-apca/

The advice, in short, is to go beyond the initial check and preferably test with users.

It might not be immediate, but finding a pleasing and accessible color palette shouldn’t be too difficult (also because it all depends on how each color is used!).

Three palettes, each with five colors.
An absolutely random example of palettes generated with the Venngage tool.

Some useful tools

  • Randoma11y generates accessible color pairs (WCAG).
  • Contrast-grid allows you to see all possible intersections of a palette that ensure good contrast (WCAG). There’s also a plugin available for Figma.
  • Contrast finder finds accessible alternatives given initially inaccessible colors (WCAG).
  • Colorsafe allows, once the background color and text style are chosen, to select a text color that ensures good contrast (WCAG).
  • Venngage offers a tool that allows you to create accessible palettes generated from a starting color (WCAG).”
  • Whocanuse Whocanuse shows how a text-background combination is seen by people with color blindness. For the same check, the Chrome Web Disability Simulator extension is also very convenient. .
  • APCA Contrast Calculator takes into account human visual perception to determine if a color pair is accessible.

Something interesting

return to the aspects to focus on →

2. Typography

Among the people who benefit the most from careful use of typography are individuals with low vision as well as those with certain learning-related cognitive disabilities (such as dyslexia).

Some considerations include:

  • Setting the text size ideally to 16px (and not less than 12px).
  • Choosing a minimum line height of 1.5 times the text size.
  • Avoiding narrow columns, as well as text lines that are too long (ideal is around 70–80 characters per line).
  • Avoiding justified text.
  • Writing short paragraphs.
  • Avoiding italic, underlined, all-uppercase text.
  • Allowing users to zoom in on the page (up to 200%) for better text readability.

In essence, these are no different from the best practices that enhance text readability on a web page for every type of user.

Another piece of advice is to use fonts with clear letters that cannot be easily confused with each other. Here are some font pairs to check and verify:

  • qp
  • db
  • 0O
  • il1I
  • rn, m
Text: “Use a font that prevents perceptual misreading: when glyphs appear similar to another, this can introduce ambiguity, impacting reading speed.” A comparison of letters C and O, and I, l, and 1 written in 2 different fonts showing how the sign can impact letters recognition. Text: “Check pairs of letters perceptually close” Cool written in too close letters can be read as cod.
An example taken from my #100ThoughtsOnInclusiveDesign

Some fonts with these characteristics are:

Some insights:

In this case as well, there is no ‘perfect recipe,’ but neither writing best practices nor font types should be an obstacle to visually pleasing design.

return to the aspects to focus on →

3. Headings

Headings help understand the page’s structure. The visual appearance of different heading types helps understand the hierarchy of information, and, in parallel, at a semantic level (from H1 to H6), it assists those using a screen reader in understanding the logical order of information on the page.

However, there is some confusion and a few myths. For example, despite being a good practice, the WCAG does not explicitly suggest that there must always be an H1 and that there must be one and only one. This represents a WCAG failure:

  • a text that appears as a heading has not been tagged as such;
  • the logical order of headings is not respected;
  • headings are not descriptive of the section.

Something to better understand

return to the aspects to focus on →

4a. Images

Another important element for the visual appeal of a page is images, inaccessible to those with visual disabilities but critical for those navigating the page with a slow connection. The technical solution here is simple: an <alt-text>: a description of the images (which will be read by screen readers or visible before the image is fully loaded).

The complex part in this case is writing a good description. Here are some brief suggestions:

  • If the image is purely decorative and does not convey important information, leave the alt-text empty.
  • Be concise: describe the subject depicted, what is happening, and in what context.
  • Provide functional, not aesthetic information: for example, if the image is a logo, it should be indicated, and a detailed description should be avoided, omitting the fact that it is a logo.
  • You can omit “image of” at the beginning of the description (the screen reader itself interprets the code and notifies the user).
  • Write a description suitable for your context (a photo of St. Peter’s Square in Rome probably needs to be described differently if the perspective is religious or architectural!).

Other helpful suggestions:

4b. Icons

A good alt-text is crucial for icons as well.

However, icons must be accessible not only from a visual perspective (not too small or with very thin lines, with proper contrast with the background) but especially from a communicative standpoint. For some user types (those with cognitive disabilities or even just very young or elderly users), icons may not be clear and easily understandable.

In this case as well, there are no set rules (but it could be a good practice to accompany them with a label indicating their function), and the ideal approach is to gather feedback from users.

Drawing of a camera icon with details to make it look like a fish. Next to it, the caption ‘Is it a camera or a fish?’
An example taken from my #100ThoughtsOnInclusiveDesign

4c. Multimedia

Accessible design can include videos, audio, and complex objects like charts or maps.

In general, be cautious not to auto-play any of these objects (ensure that the user is always in control of stop and play).

In this case as well, WCAG 2.2 guidelines come to our aid: to summarize very roughly, remember captions and audio descriptions for videos and transcriptions for audio content.

If you’re dealing with complex images (charts, diagrams, flowcharts, maps), you’ll need to write an alt-text (here are some useful suggestions on how to do it).

return to the aspects to focus on →

5. Focus

For those navigating the site via keyboard, it’s essential to understand where they are: the :focus state serves as an indicator.

It’s one of those less obvious little things where a visual intervention can be designed: borders, backgrounds, shadows, or underlines can be created in line with the site’s style (or the design system).

Guidelines on how the focus of an element should appear are at the AAA level (the most inclusive), and they suggest using a border that is at least 2 CSS pixels thicker than elements not in focus and that the contrast should be at least 3:1 between what is in focus and what is not.

5 stars, 3 orange, two with only the orange outline. The center star is orange with a dark blue border.
Example taken from WCAG 2.2 — Success Criterion 2.4.13 Focus Appearance (the 3-star focus passes the criterion).

For further details:

Keyboard interaction design

An aspect less visual but extremely relevant in terms of design involves the planning of how the experience should be for those using a keyboard and in what order elements should be in focus.

The actual implementation falls to the developers, but guidelines on how to do it can be provided.

A card with information, next to each section is a progressive number and arrows indicating an order
Example from A11y Annotation Kit

Two annotation kits in Figma, already ready and usable for (among other things) designing the order of elements:

return to the aspects to focus on →

6. Position and proximity

This aspect considers more the clarity of a site than aesthetics per se.

Some people have a very limited view of the screen: either because they have tunnel vision and can only see a small part of the visual field or because they use a magnifying glass to better see the page. In both cases, the overall view is lacking.

If we design microinteractions on the page, it would be good practice to ensure they take place contextually within the section the user is currently viewing. For example, adding an item to the cart should produce a change of state in the button just used and not only in the cart icon at the top right.

Reflection taken from:

return to the aspects to focus on →

--

--

Chiara Cielo Longobardi (she/her)

UX Designer. Interested in accessibility & inclusive design, curious things in the world, and everything that can make me a better designer and a better person.