smallcreature

slowly recovering from birdsite

autistic queerthing from france. kitty fighting the puppy allegations. Asks welcome!

Icon: Komugi from Wonderful Precure
Header: Whisper of the Heart



ewie
@ewie

I'm gonna be honest, I'm not a particularly huge fan of people doing fancy text like this:

Oooh look at this fancy text aren't I so fancy

Or some, like, homestuck typing quirk-ass text like this:

GC: Objection!!!

I think it's hard to read, it's hard to make sense of, and honestly I think it's also kinda annoying. But, I understand that for some people, it's how they want to (or need to) express themselves. And as someone who's a bit of a big fan of accessibility, I'd like to give people the choice to do what they want, but in a way that's not going to completely heck over people using screen readers.

So, I'd like introduce Accessible fancy text ๐ŸŽ‰!!!

Below is a snippet you can use in your cohost posts (chosts) to make sure that if you use fancy text (which I wouldn't recommend using in general but still), it'll still be readable to screen readers. Below the fold is a writeup about it that goes into more detail.

The Snippet

<!-- use div, p, span, whatever works here -->
<div aria-describedby="user-content-id-name">
	<span aria-hidden="true"> <!-- Put your stuff here! --> </span>
	<span id="id-name" style="clip: rect(0 0 0 0); clip-path: inset(50%); height: 1px; overflow: hidden; position: absolute; white-space: nowrap; width: 1px;">Rewrite the stuff but in human-readable text</span>
</div>

It also works inline too!


Alright, so how does it work?

So, the main magic bullet here is aria-describedby. All it basically does is say to the screen reader, "hey, this chunk of html has another element describing it." Sort of in the same way that adding alt text to an image works I guess. There is a catch, though. Unlike alt text, aria-describedby doesn't actually hide (to the screen reader) what it's describing, which is fine. I can't really think of any reasons off the top of my head not to hide it, but I'm certain there's some good reasons. In practice, we can use aria-describedby like this (graciously stolen from this writeup by @thrice-totted):

  • Put the description in an element with id="{something}" on it
  • Set aria-describedby="user-content-{something}" on the element it's describing. (We stick it on a wrapper around both elements instead. I'm not certain if it's better, but I've had less issues with this over having them side by side when I did some testing.)

The reason we need to stick "user-content" in front of the id we want to use for our element is because cohost actually lets us use custom ids in our posts, but it'll prepend them with "user-content" to make sure they never interfere with any actual ids used by the website.

Since aria-describedby doesn't hide our fancy text from the screen reader, we'll want to manually hide it ourselves, or else the screen reader user could end up having to sit through this entertaining listening experience. So what we'll want to do is make sure to wrap the actual element with the fancy text in it with aria-hidden="true", which ensures that screen readers just assume it doesn't exist.

After that, we stick some css on the aria-describedby element to make it invisible so people who can see don't end up getting double text. (I'd rather prefer to have a little tooltip that shows the text, so that way you could hover over or tap the fancy text and read what it actually means, but I couldn't find anything accessible that doesn't use javascript. If anyone in the comments can figure it out, then please let me know and I'll update the post.)

clip: rect(0 0 0 0); 
clip-path: inset(50%);
height: 1px;
overflow: hidden;
position: absolute;
white-space: nowrap; 
width: 1px;

(For convenience's sake, here's how you'd put it in an html element)

style="clip: rect(0 0 0 0); clip-path: inset(50%); height: 1px; overflow: hidden; position: absolute; white-space: nowrap; width: 1px;"

Just as one last thing, I'll add that just like the accessible css crime pioneers before me, I don't rely on accessibility tools myself. I made sure to test all this stuff with Voiceover on my computer before putting it out there, but I don't use it on a daily basis. I'm just a weird nerd that saw the incredibly minor drama about fancy text on cohost earlier today (as well as the post resolving it), and thought "Oh there's gotta be a really simple solution". And there was! So that's good. Glad we got that sorted out and we're able to use the power of html to make our text accessible. It'd be awful if there was a social media website where people had to just constantly complain about how people should never use fancy text while other people ignored the wishes of people just seeking to improve accessibility.

I think I've got it, so I should just use this willy nilly now that I can guarantee my stuff'll be accessible?

I mean, no??? No matter what, using plain text should always be preferred over fancy text, since that's accessible by default. I mostly put this out there since I know that no matter what, there'll be some people who have some reason to not use plain text, and so they should, at the very least, make it accessible. But as a rule of thumb, you should always prefer to have your text look like this

Plain text reading "Ooh look at this fancy text aren't I so fancy"

Over this

An accessible fancy text block that reads "Ooh look at this fancy text aren't I so fancy". It is harder to read at a glance than the plain text.

At the very least, it'll be easier for you to read when you're writing the post.


@smallcreature shared with:

You must log in to comment.

in reply to @ewie's post:

all my snippet does is hide the text to a screen reader and offer substitute text for the screen reader to read. it is only ever applicable if the base text itself is not legible by screen readers. if youโ€™re uncertain about whether or not you should use it, you can always activate the screen reader built in to your computer (or download a free one off the internet) and give it a listen yourself!

I don't mean this to be hostile, just curious (I want to be better able to test things going forward):

what fancy text and what screen reader? talkback and espeak read the unicode letter words just as their words at least on firefox (I checked by pasting the text elsewhere without your code blocks to make sure it wasn't just those)

edit: they still don't handle the block/circle text though, but they ignore it instead of spamming now

this post was made while i was still on twitter and i remained endlessly annoyed by the waves of discourse about people wanting to use the fancy unicode text in display names or posts and stuff. this is a beef iโ€™ve had for a minimum of 4 years.

A meme meant to look like a sketchy ad. It reads, โ€œScreen readers hate us! Learn how to ruin your disabled friendsโ€™ lives with this one weird trick! Find out how: click here.โ€

i really only re-shared it in response to a recent wave of posts because i didnโ€™t want to spread negativity and preferred to share an old post that was helpful.

i tested it using only voiceover, which is the dominant screen reader on mobile (and is only moderately popular on desktop). i donโ€™t have nvda or jaws on my computer, and didnโ€™t want download any additional screen readers just for a cohost post. (sorry!) i have never of espeak, and according to usage data, its not used at all. talkback isnโ€™t used very much, and given that i have heard that most people who need a screen reader will use ios solely for its accessibility features, itโ€™s far more likely that talkback just hasnโ€™t implemented the spec correctly and not that i am missing something. afaik, i am using these aria features mostly as intended, and these are the correct aria features for what i want.

hope that answers your questions!

yeah! no pressure, I just was wondering if you knew of a list or tested a few is all. This whole thing is a MESS, apparently i can't trust any single one since I'd just been testing things with TalkBack.

Windows Narrator fails the test too.