What a logo looks like, sounds like, feels like
A multi-sensory logo. A draft ARIA attribute. A story about accessibility, art, and the beauty of inclusive design.
Disability is an art
In this post, I’m going to be writing about the intersection of disability, accessibility, art, and… aria-braillelabel. All by telling the design story behind the OpenAccess logo.
To begin, here’s one of my favourite quotes that ties art and disability together nicely.
Disability is not a brave struggle or courage in the face of adversity.
Disability is an art.
It’s an ingenious way to live.
The OpenAccess logo
Most brands design logos visually first — but what if we flipped that? The OpenAccess logo is different: its primary sensory experience is tactile — felt through physical Braille dots. We often treat visual experiences as primary, relegating other senses to diminished “alternatives.” I want to subvert this bias. Visual and auditory perceptions of the OpenAccess logo receive alternatives. In this design, the visible logo is not the original — it’s the visual alternative to a tactile original.
The logo markup
<picture>
<source
srcset="/images/logo-dark.svg"
media="(prefers-color-scheme: dark)"
/>
<img
alt="OpenAccess logo, circles
representing the letters
OA in Braille"
aria-braillelabel="OA"
src="/images/logo-light.svg"
/>
</picture>
<h1>OpenAccess</h1>The visual logo
Visually, the OpenAccess logo is two characters in Braille: O and A — the initials of OpenAccess, followed by serif text underneath reading “OpenAccess”. A circle with a solid colour represents each Braille dot. If your device is in dark mode, the ‘raised’ Braille dots are light grey, and the non-raised dots are dark grey. For light mode, the colours of each dot are essentially ‘flipped’, to provide better contrast against background colours.
When the logo renders on a solid white or black background, the non-raised Braille dots have low colour contrast relative to the background colour. While I worry about breaking the spirit of WCAG SC 1.4.11 Non-text Contrast, I feel it’s justified to ‘bend’ the rules here because non-raised Braille dots are supposed to go unperceived. Oh, and SC 1.4.11 doesn’t apply to logos 😅
The serif sheriffs
The logo’s text is in a gorgeous serif typeface — Libre Caslon Text. Over the years I’ve heard many people claim that serif typefaces are not accessible. But I’ve always disputed that claim — I don’t think there’s much solid evidence to back that up. It’s turned into accessibility dogma.
The most accessible typeface is a deeply personal choice. Every human is different. I personally find serif typefaces far more readable than sans serif — that doesn’t mean I should impose that as a rule on all designers. Accessible design, at its core, is more about supporting user needs, rather than cutting down design choices. While reasonable default styles do help with accessibility, user customisation is the end goal.
One incredible technology that doesn’t get talked about enough, is “reader” modes, such as Safari Reader. Firefox, Chrome and Edge also have similar systems. Reader modes extract the core HTML markup from a webpage, and provide the user with a clean, minimal, and customisable reading experience of the page’s core content. The user can specify their preferred colours, fonts, line spacing, and even access user-friendly text-to-speech synthesis without firing up a complex screen reader. I heavily rely on this feature as a person with vision impairment. Supporting reader modes is an essential accessibility feature you won’t find in WCAG.
In the accessibility field, I think too many people parrot random little rules they’ve heard without much thought behind it as a way to unnecessarily police design — “don’t do this, don’t do that!” As a small act of defiance, I intentionally sided with the humble serif. I think it’s harder to pull off a design using serif typefaces while still appearing highly technical and modern. I hope I succeeded.
Light and dark mode
The logo automatically adapts to a light and dark mode variant — so the logo looks good no matter what the prefers-color-scheme value is.
I used an interesting technique to swap between the light and dark logo, using the <picture> element. The <picture> element is rather fancy. It allows you to specify different src values for its child <img>, and you can specify a condition under which each src is active. You can swap src values conditionally based on screen pixel density, viewport size, image format, and even prefers-color-scheme media queries.
<picture>: The Picture element — MDN Web Docs
Supporting light and dark mode is another essential accessibility feature you won’t find in WCAG. Many people get visual discomfort from light interfaces, or even migraines. Supporting the user’s visual preferences via prefers-color-scheme is non-negotiable.
It’s pretty unrealistic to expect people to write custom user-defined stylesheets, or to install browser extensions, just to experience the web in dark mode. I’ve used 3 or 4 dark mode browser extensions, and they generally produce terrible results, with low-contrast text a frequent outcome. Nothing beats the author intentionally specifying colours that are WCAG-compliant in both light and dark mode.
One major flaw in many dark mode browser extensions is that some websites use Content Security Policies (CSP) that block the injection of inline JavaScript and CSS — even if that a local extension injects that content. Injection of scripts into the DOM which were not intentionally included by a page author are a security vulnerability. Dark mode browser extensions like Dark Reader and Noir both seem to suffer from this frustrating design flaw. Perhaps there is a fault in the specifications that govern browser extensions, or perhaps those extension authors have simply arrived at an incorrect implementation — who knows. Can you tell I’m about to do a cybersecurity certification? 😉
The text alternative logo
To support screen reader (with text-to-speech) users who require text alternatives for non-text content, the logo has an alt attribute specified on the <img> element.
The alt value is: “OpenAccess logo, circles representing the letters OA in Braille”.
This description should provide screen reader users with an adequate audio-based description of the logo.
I decided to separate the “OpenAccess” text out of the logo’s SVG, and render the “OpenAccess” text as a plain HTML <h1> element. I felt this design choice exposed the most amount of semantic and structural information about the page to assistive technologies.
The tactile logo
I’ve always found it rather cringey when people print Braille on flat paper with ink, or when devices show Braille as visual dots on a flat display. The problem is pretty obvious there — its key audience cannot perceive it.
…and here’s where things get interesting: I found a way to make a digital Braille-based logo tactile.
There’s a little-known ARIA attribute, called aria-braillelabel.
🚨 WARNING: aria-braillelabel is currently in the WAI-ARIA 1.3 draft specification — it’s not in an ARIA specification that is a W3C Recommendation. Don’t try this at home — we’re trained professionals! Well… actually, you can try this at home if you’re aware of the risks, and know what you’re doing. I don’t think using this attribute will cause any harms if you carefully assess how all supported assistive technologies behave while using the attribute.
Before using this draft attribute, I have extensively tested accessibility support for aria-braillelabel across (most of) the screen readers I aim to support. To see the accessibility support test data, head to aria-braille*: accessibility support tests.
aria-braillelabel allows authors to specify a Braille-specific label for an element. This enables me to literally send the Braille characters “⠕⠁” to screen reader users who have a refreshable Braille display connected.
Like all ARIA attributes, with great power comes great responsibility. It’s important to understand all implications of using this ARIA attribute before you slap it on an unsuspecting HTML element. aria-braillelabel has limited and specific use-cases, and I was lucky enough to stumble upon one of them.
aria-braillelabel provides a Braille-specific accessible name for an element. It overrides other mechanisms of providing the accessible name, only for Braille display users. In most cases, the default accessible name of an element (e.g. provided by an aria-label, or the text contents within a <button>), is almost always the best accessible name to expose to Braille users. In some cases, the accessible name of an element may be overly verbose for Braille users, so aria-braillelabel allows authors to specify an abbreviated, efficient Braille experience for specific use cases.
Refreshable Braille displays generally have a limited number of Braille cells that they are able to display at one time, say ~20 cells for some models. Imagine if your visual computer display were only capable of displaying 20 letters at a time. This makes the need for short UI component labels ultra clear. Screen readers already output contracted element roles for Braille, such as “btn” instead of “button” to use less cells and increase reading speed — so, I assume Braille display users would be familiar with such contractions. The existence of contracted (or grade 2) Braille also suggests Braille users would value abbreviated component labels.
Note: I’m not a Braille reader myself so I’m open to corrections on my assumptions above. I tried learning Braille once, but Blind Low Vision NZ got upset with how slow I was at learning it (I was busy working full-time making the welfare system accessible…) and they requested I give back the training book. Can you tell I’m still mad about that? 😅
RTFM: Read the Fantastic Manual
Before you go anywhere near aria-braillelabel, please read the docs. Also please be aware that aria-braillelabel is not yet part of an official W3C Recommendation — so this attribute could change at any moment, and support across assistive technologies may be unreliable. Use at your own risk.
Carefully read through the following:
The nasal logo
Okay, no, I’m kidding — I’m not going to make a scent-based logo. Or should I? 🤔
The audio logo?
While I haven’t made it yet, I’m considering creating an audio-based logo. I want to build it using a JavaScript programme that can directly output WAV data using a stream of integers. Perhaps the algorithm could translate the Braille text data into a sound of some type. It sounds like a fun afternoon project.
Conclusion
I hope this article has given you an interesting perspective on how I approached the design of the OpenAccess logo. I consider different sensory perspectives, utilise all the incredible accessibility technologies available to me as a developer, and I treat accessibility as an opportunity to layer different forms of creative expression into a single piece. Accessibility isn’t a bunch of boring rules that restrict your design. Accessibility gives you the opportunity to find new ways to connect your work with people.
— Callum