Superscript, Subscript, & Accessibility

I was recently asked by a UX colleague whether there were any accessibility concerns around font size and superscript/subscript text. Specifically: could setting superscript text to less than 16px in size be a concern for some people?

That's a good question! I had an instinctive answer, but nothing to back it up, so I did some digging around.

For some brief context, if you're not aware of the terms "superscript" and "subscript" then here are some examples: this is superscript text, and this is subscript text. In HTML and CSS, there are a few ways to mimic the look of super/subscript, but the simplest (and best) is to use the <sup> and <sub> elements themselves, respectfully.

What Does WCAG Say? 

Nothing, really. There are no specific WCAG success criteria that cover superscript or subscript text specifically. Of course, we're still talking about text, so SC 1.4.3 (Minimum Contrast) and SC 1.4.4 (Text Resizing) definitely apply, but super/subscript characters are not treated any differently than anything else.

For text resizing, so long as your font size is set using responsive units (e.g. rem or em) then any of the common methods for text zoom, font scaling, etc. will work as expected, no further configuration needed. I'd say that em has a solid advantage, in that it should scale with any changes to the immediate surrounding text; useful if people are only overriding the size of headings, for instance, rather than all of the text on the page.

Minimum contrast is a little more finicky, as this will depend a lot on the font you're using, the size and colour of the text, and (to some extent) the device being used to render it all. Still, so long as the amount of contrast between the text and the background is maintaining a 4.5:1 ratio, it would be considered compliant. If you're making the text very small, you probably want to bump that ratio up – and, as ever, the higher the better anyway – but that will need to be decided on a case-to-case basis.

Unicode vs. Abbreviations

One question is whether it's better to use Unicode characters like ™ and ° (just in case they don't show for you: that's the "trademark" or "TM" character and the symbol for "degrees", as in temperature) or use regular letters set in superscript text. Some people say that you should prioritise Unicode symbols where possible, as assistive tech and translation tools will then have more context to work with. As most fonts use glyphs for these characters that appear superscripted anyway, there seems little need for using actual <sup> elements (and this could cause them to render far too small, as well). I think this is sound advice, but there are some additional considerations.

First of all, not all fonts have complete Unicode glyph sets, and to the best of my knowledge it's not possible to apply per-glyph fallbacks. Whilst your chosen web font might work fine, a user with custom font overrides could be left with a blank or incorrect character, which isn't ideal. Unfortunately, I'm not sure that there's a good solution to this. Using elements like <abbr> or title would work in some contexts, but their support is patchy at best and can cause their own issues. I think it would make most sense to explicitly define the font stack for <sup>/<sub> elements, so that blanket user overrides may not apply to them specifically, but you'll never be able to control this 100% of the time.

Secondly, not all fonts choose to place these characters in the super/subscript position. Heck, some services take characters like ™ and automatically turn them into emojis, which are then rendered fully inline with the rest of the text. Again, there's no clear workaround available here, but perhaps there doesn't need to be. This definitely feels like a place where you can just cede some control to user preference.

(Honestly, I feel like my research into Unicode has left me with more questions than answers, so if anyone else has further insights, I'd love to hear them!)

Content Concerns

As with anything text-based, there's room for people to abuse super/subscript formatting. So just don't, okay 😄

The biggest concern here is length, which should be kept as low as possible. I feel like this is mainly common sense, but don't subscript entire paragraphs or always superscript your company name, for example. Super/subscript should be used for what I'd call complementary text. This is content which could be removed entirely, without losing any critical context or information.

A good example for this (and one of the most common use-cases in English for superscript text) are dates. You'll often see things like "the second of January" written with an "nd" set as superscript, e.g. 2nd January. This is a common convention and should be perfectly fine, but it also isn't the end of the world if you were to read "2 January" or see "2nd January". They're clunkier and less expected, for sure, but the key information is still there. Similarly, whilst flagging legal designations like copyright and trademark status is clearly beneficial, your content won't be unreadable without it – no matter what the legal department claims!

One area I can see some pushback to my definition of "complementary" here is with footnotes – probably the most used pattern of superscript content on the indie web. However, I'd argue that a footnote is complementary by nature; the very fact that the linked text has been moved out of the flow of the main reading experience suggests that it is a bonus, additional piece of content, not a critical piece of information.

Thankfully, most common use-cases (particularly for superscript text) tend to only use a handful of characters – it feels like either 2 or 3 characters is the median – so length shouldn't really be an issue. There are a few niche cases where this rule is likely to be stretched, particularly when using scientific or mathematical formulae, but these have their own well-established patterns and expectations so shouldn't pose major issues, either.

Assistive Tech

Finally, you can't talk accessibility without considering how your decisions might impact people using various assistive technologies, like screen readers or voice assistants. As the original question posed to me was mainly about font size, I've not done too much of a deep dive into this area of the topic, but I did come across an excellent article by Adrian Roselli: A Brief Note on Super and Subscript Text.

Adrian has done a solid investigation into how these text formats are exposed in common pairings of assistive tech and browsers, which shows that there are inconsistencies, but nothing that would preclude their use or negatively impact a user, which is good to know.

So what are the key takeaways then? Well:

  • Text should still be rendered with a good contrast ratio;
  • Text must work with common magnification techniques;
  • There's no specific lower limit, but use common sense; from discussions with various people, a font size around 12px or 14px (or roughly a 25% reduction compared to the surrounding text) seems perfectly reasonable;
  • Unicode characters are likely preferable (and don't need additional HTML markup);
  • And you should keep formatted text to around 1-5 characters in length (which covers almost all common use-cases).

Overall, then, there's no real concern with using superscript or subscript text, so long as common-sense considerations are taken into account and standard accessibility best practices are used.

Explore Other Articles


A Missing Narrative

Ever spend weeks writing something, hit publish, and then feel completely unsatisfied. That's what just happened to me. So I figured I'd try to work out why.


Want to take part?

Comments are powered by Webmentions; if you know what that means, do your thing 👍

  • <p>Are there any concerns with using superscript and subscript when crafting content for the web?</p>
  • Murray Adcock.
Article permalink

Made By Me, But Made Possible By:


Build: Gatsby

Deployment: GitHub

Hosting: Netlify

Connect With Me:

Twitter Twitter

Instagram Instragram

500px 500px

GitHub GitHub

Keep Up To Date:

All Posts RSS feed.

Articles RSS feed.

Journal RSS feed.

Notes RSS feed.