How To Make Accessible GIFs?


Alt-text works the same way for any image format; but is not intrinsic to the image; but to the page embedding the image, so GIFs should be covered. If the tool also auto-generates HTML, though, you might have a problem, since the alt text has to be defined there for it to work, and more than a few tools are lazy or deficient on that score.

1 Like

I’m not sure what you did there. I already have an add-on which disabled animated gifs [unless and until I choose to watch them, or unless and until an update breaks them], but I think these things should be a standard browser feature and animated gifs and autoplay generally should not, and should be considered bad form.

As for the phones: phones hurt, and really hurt. And phones present a lot of accessibility problems, but are often the only way to contact public officials, public services, and to contact public services about accessibility problems…

1 Like

Ah. Thank you for the clarification.


I think this made sense back when the primary way people viewed images was on webpages, because you could always harangue the to get with W3C standards.

Now that image files are so portable (I like to pluck them from image banks and plug them into tweets, bbs, e-mails, etc), I’m questioning the premise. If a significant (and, I’d argue growing) way we use image files is to transplant them from one context to another, wouldn’t it be nice if the format had some inherent accessibility features baked in?


I can understand the temptation of making the features ‘inherent’; but it has architectural perils that make me distinctly uneasy.

  1. Complexity is bad: no format gets easier to implement, easier to implement safely, well implemented on most/all relevant platforms, etc. by being complex. Some degree of complexity is unavoidable, of course, if you actually want the format to be useful; but you want to avoid introducing more than necessary. It makes implementation harder, increases the chances of ambiguities that render independent implementations incompatible, raises the odds of ugly and creative exploits, and so on. It also tends to encourage the growth of partial implementations, which are annoying in general and can be very bad for accessibility: if a format is relatively tractable, and software either does or doesn’t support it, you can rely on whatever features it has being available. If it’s a ghastly, multifaceted, totipotent tumor-growth of a format(looking at you, DICOM… and arguably PDF-as-Adobe-does-it, better ordered subsets like PDF-A are safer), you can’t be sure that ‘supports Format X’ actually implies that a given piece of software supports Specialty Feature Y(indeed, in hostile environments like message boards or chat systems, certain special features may be explicitly stripped to keep people’s rickrolling and shock site redirects to a minimum). If you can’t depend on the feature being supported by a given piece of software, then the value of the feature being ‘inherent’ just isn’t as great.

  2. Logical separation of different classes of features is very helpful: in order to keep down complexity (see #1): In the case of text, unicode defines glyphs and tries as much as possible to stay away from actually defining the appearance of characters, which it leaves to fonts, which define the appearance of characters but avoid interacting with color, line spacing, blinking, size, and other attributes that are left to the document format or markup language. This logical separation makes life easier for applications that only need to support one aspect of the broader problem(eg. the string manipulation libraries in a programming language can be unicode-aware without needing to be a full-blown word processor) and complexity is compartmentalized into a series of smaller, more manageable, parts.

  3. Sort of a correlary of #2, maybe a lemma, duplication of the same capability(or an incompatible-but-similar-ish one) in multiple locations within the overall stack of formats and standards being used is Not Good. Aside from the mere increase in total complexity, there’s the problem of interpreting multiple, potentially contradictory or ambiguous, approaches to the same problem without making a hash of the result. If, say, a font were extended to carry ‘color’, what would the correct response be if the entire paragraph has been assigned one color at the document level; but part of that paragraph has a different color assigned at the font level? Even more fun, what if the font color definition is based on a 24-bit RGB definition, with no alpha channel; but the document editor is being used to produce CMYK output, or the font is being used on a web page that does use transparency/translucency? Things have the potential to get exciting, especially if ‘transplantation from one context to another’ is a routine occurrence.

The other major reason to say ‘stick with HTML’ is that, in practice, a substantial percentage of the different contexts are basically just other wrappers around the same browser engine. For sake of convenience, if nothing else, tweets, message board posts, emails, etc. are typically shoved straight through whatever HTML renderer is platform appropriate unless you specifically demand plain text. Even ‘apps’ and native client applications frequently use the available HTML renderer, and browser-based views obviously do. If you want advanced formatting, your email will be a web page, albeit a static one. Bulletin boards and tweeter and the like are pretty much web CMSes; but with really constrained editing features.

In a substantial majority of cases, all the technical capability required has already been inherited, more or less for free. It may not be made available(BBSes typically constrain you to a reduced set of markup in order to keep malicious users from munging the entire page, twitter gives you very little control at all, etc.); but all the tech is in place. If they can’t be bothered to add a button that lets you turn it on, when it is already there, the odds that they’d bother to implement a new set of intrinsic features to duplicate that function are not terribly promising.

I’m certainly in favor of accessibility; but format overloading is likely not the way to get it, at least not without substantial unnecessary pain.

1 Like

So, what are you proposing? Should something like Discourse auto-detect when you post and image file, and then prompt you to enter alt-text (or skip)? Maybe make this a user-configurable setting for the cretins that never want to be bothered?


Some Quick Testing

Based on some quick testing(above) using the ‘upload’ button to add an image produces an ordinary img tag. At present, it doesn’t have a box for alt text(though one would fit reasonably well in the window where you select either a local source or a URL); but it does respect an alt string if you add one to the img tag it creates.

That would be more or less my proposal: depending on exactly how hard you wanted to encourage it, you could either have a separate prompt, have an optional field in the upload window, or never prompt the user; but don’t interfere with an alt string if they add one.


Interesting. Thanks! (I usually copy-pasta images in the wysiwyg, so it hadn’t occurred to me to muck with the upload button).

That said, I’m also LAZY, so I’m unlikely to add the extra steps. As I suspect most are. Hence, my desire for a default / native solution.

  1. An accessibility solution which relies on people typing everything isn’t an accessibility solution.

  2. See also: using gif-warning tags on Tumblr. It breaks down because it requires users posting/reposting the images to tag everything, when some users have trouble typing the tags, and some other users don’t bother typing the tags, and also because it requires users who are receiving the images to install extra software such as tumblr savior, when some of us can’t get tumblr savior to work.

  3. It turns out that some screen readers require pages to have “proper headers,” “proper layout,” and “proper tables,” instead of the minimalist underline headers, use plain text in layout, and use plain text with tabs in tables approach that I prefer. I am sick of “proper layouts” screwing with my text, and screwing with any outline, or any rules organization in my text, and I am sick of “proper headers,” “proper layout,” and “proper tables,” getting properly corrupted when switching between word processors. I don’t know what to do about that.

1 Like

nice gif!


I’m afraid I don’t know who is due the credit; but I am not. In fact, that was my test GIF precisely because I also thought “nice gif!” while browsing the interwebs at some point in the recent past, so it was among the most accessible ones on my computer.

Maybe TinEye knows…


Amen to that. If it requires user intervention, that’s a nice way of saying that it mostly won’t happen.

That said, what sort of automation do you think would be most helpful(within the limits of what can be achieved)?

Speaking as one who isn’t responsible for doing it(@codinghorror can feel free to smack me or correct me if he deems it justified), I’d imagine that simply automatically adding a generic alt string to images without one would be quite trivial. For the WYSIWYG editor to work in the first place, Discourse can clearly rewrite “user pasted an image” into a proper img tag, and handle uploading the image to some web-facing location in the background, so writing an alt string would represent a very minimal extension.

However, if you wanted more than a generic alt message “Somebody posted a picture here and didn’t provide alt text; that asshole”, things get more complex: would reporting the original filename be helpful?(reporting the original path on the client would be a dangerous information leak). Saying anything useful about what the image is would be a nasty machine vision problem(especially given the fondness for optical illusion and glitch GIFs). If the image has EXIF data, should those be used, or is that a potential data leak and an open invitation to sneak GNAA ascii ‘art’ into innocuous-looking images?

What would your preferred implementation look like? Add an EXIF-like string storage field to GIFs(or other image formats) to store a ‘default’ alt text for when none is otherwise provided? Have CMSes and bulletin board systems sub in a default alt text? I agree that relying on users is hopeless; but, until machine vision improves, there is no other source of actually good alt text, since image recognition and natural language description of images is a brutally hairy problem.


I put the gif between spoiler tags to blur it, which seemed like a good way to reduce the problem from my side without being able to control the autoplay feature.

In that case, I’m not really clear what the problem is. I can agree with you that click to play should be standard on forums like this one, but if you’re already doing it from your end, why would it be a problem that gifs autoplay for other people? I use adblock on my browser, which eliminates a lot of the annoyances for me; gifs are fine for me, but flash adverts and autoplayed audio aren’t. I don’t really care if websites, advertisers or other users post elements that don’t get past my filter. Or is it that a gif is often used to comment on something, so the comment is more difficult to interpret without the gif? As with phones, I’d like to see more accessibility and options for those who don’t want them, but they also serve a purpose for those who do. If your add-on solves the problem for you, what else needs to be changed?

This is what I see:

Is there an image behind the text? I get an arrow cursor when I hover over it, but I can’t click on it. It does seem to mess with the screen though, I get a white box that flashes up in different areas.


No, I’m afraid my attempt to talk about HTML tags was interpreted as HTML by Discourse. My mistake, nothing to see there.

Incidentally, is there a “code/interpret this completely literally and print it as a I wrote it” setting that anyone knows of?

Could it be the "preformatted text" </> button between Quote and Upload?  Let's see.  [spoiler] Can I see this?  [/spoiler]  <strike> Is this stricken out? </strike>  Hmm.  ;)  Seems to work.

Don’t know if it works for all tags, but maybe that’s what it’s designed to do. I am only an egg. :wink:


This is really the way it should be. Browsers should support a click to animate setting for GIFs for accessibility.

Anyway, as of today, that’s not the case… but I’ve already linked to plugins that do this.

1 Like

Or use Lynx.

Does that still exist?


Wow. I think my eyes just broke. When was the last time somebody said that about Internet Explorer?


That is not dead which can eternal lie…

closed #33

This topic was automatically closed after 744 days. New replies are no longer allowed.