The deceitful panacea of alt text

One of my favorite1 accessibility myths is this pervasive idea that alternate text is some kind of accessibility panacea. I get it – it’s theoretically2 a thing that content creators of any skill level can do to make their content more accessible. Because of these things (and because it is technically a required attribute on <img> tags in HTML), it seems to be one of the first things people learn about accessibility. For the uninitiated, alternate text (from here on out, alt text) is metadata attached to an image that assistive tech (such as a screen reader) will use to present a description of an image (since we don’t all have neural network coprocessors to do deep machine-learning and describe images for us).

This is all very good, if we have a raster-based image with no other information to work with. The problem is, we should almost never have that image to begin with. Very few accessibility problems are actually solved with alt text. For starters, raster images have a fixed resolution. And when users with limited vision (but not enough-so to warrant use of a screen reader) attempt to zoom in on these as they are wont to do, that ability is limited. Best case scenario, the image is at print resolution, 300dpi. This affords maybe a 300% zoom, and even then there may be artifacting. Another common pitfall is that images (particularly of charts and the like) are often used as a crutch when a user can’t figure out a clean way to present their information. Often this means color is used as a means of communicating information (explicitly prohibited by §508), or it means that the information is such a jumble that users with learning disabilities are going to have incredible difficulty navigating it.

Information often wants to fall into a particular structure. When I’m given a bar chart at work, in its original, non-rasterized form, I just structure it back into a table behind the scenes (in PDF). If you’re trying to communicate a message (particularly data), often part of the problem is that there’s a lot of information to communicate. This requires further structuring, and alt text is ‘flat’. By this, I mean, it lacks the capability to be structured – it’s generally restricted to paragraph breaks, if that.

An anecdote: in my professional life, I requested a customer provide original or recreated (but non-rasterized) versions of infographics in a document, and ended up with one that, when pasted into Word, yielded two pages worth of text. I explained to the customer that this was far too much content for alt text, for the reasons already mentioned. She responded that her ex-husband was blind, and how she had written it was exactly how he would have wanted to hear her read it. She failed to understand that if he knew what he was hearing was irrelevant to what he wanted to hear, he could ask her to skip ahead to the relevant bits. She failed to understand that if he missed how this piece of information related to the bigger picture (think, header row and column in a table), he could ask her. She failed to understand that she was not a robot and he probably enjoyed listening to her talk more than NVDA.

And it is here that we come to a major pitfall of accessibility work in general. Folks think that it’s enough to provide information, without any consideration for how that information is structured (or not). Pages worth of descriptions of a table are not a suitable replacement for an actual table where data always has context available if necessary. Data always has a sense of where it exists in two dimensions. Navigating among sections is a godsend when you’re trying to get through massive amounts of complex data, and fluffy tangential details are simply a waste of time when you’re listening to a robot. This is all on top of the issues that exist for folks struggling with poorly-rendered or poorly-designed images despite not using a screen reader.

Alt text is not a panacea. If it is to be used, it should be concise and clear, while presenting all of the relevant information a sighted user would grasp. If this is not possible, the image should not be rendered as a raster image, period. Listen to your alt text in a screen reader. Try to find a specific data point. If you get lost, find another way to present the information. If you stick with your rasterized image, drop the highest resolution version in that you possibly can. Print resolution is a minimum; 72dpi is for abled folks. Don’t use color as an exclusive means to communicate or associate data with meaning. Learn to resist images, and when you use them, learn to embed them in inherently machine-friendly ways.


For someone rooted in graphic design and illustration, I typically hate running across visuals on the internet. Aside from being numbed by ads, the fact of the matter is that a large percentage of the graphical presentation on the web is just bandwidth-stealing window dressing with little impact on the surrounding content. Part of my plan with this blog was to avoid graphics almost entirely, and yet over the past month or so, I have littered this space with a handful of SVGs. I think, for the most part, they have added meaningful visual aids to the surrounding content, but I still don’t want to make too much of a habit of it.

I’m far more comfortable with SVGs (or, vector graphics in general) because I find it easier to have them settle onto the page naturally without becoming jarring. I could obviously restrict the palette of a raster image to the palette of my site, and render a high resolution PNG with manageable file size, but scaling will still come into play, type may be mismatched… aside from being accessibility issues, these things have subtle effects on visual flow. I’m thankful that SVG has been adopted as well as it has, and that it’s relatively simple to write or manipulate by hand. Following is the process I go through to make my graphics as seamless as possible.

Generally speaking, the first step is going to be to get my graphic into Illustrator. Inside Illustrator, I have a palette corresponding to my site’s colors. Making CSS classes for primary, secondary, tertiary colors is in my to-do list, but I need to ensure nothing will break with a class defining both color and fill. Groups and layers (mostly) carry over when Illustrator renders out an SVG, so I make a point of going through the layer tree to organize content. Appearances applied to groups cascade down in the output process, so (as far as SVG output is concerned) there’s no point in, say, applying a fill to a group – each individual item will get that fill in the end anyway. I use Gentium for all of the type, as that is ideally how it will be rendered in the end, though it’s worth quickly checking how it all looks in Times New Roman as well.

Once I get things colored and grouped as I need them, I crop the artboard to the artwork boundaries. This directly affects the SVG viewbox, and unless I need extra whitespace for the sake of visually centering a graphic, I can rely instead on padding or the like for spacing.

Once in the SVG Save dialog, I ensure that ‘Type’ is set to ‘SVG’. I don’t want anything converted to an outline, because I want the type to visually fall back with the rest of my page. I never actually save an SVG file from Illustrator, I just go to ‘SVG Code…’ from the Save dialog, and copypaste it elsewhere for further massaging. This involves:

Illustrator seemingly outputs SVG with the intent being structural accuracy if the file is read back in for editing, which is often counterproductive for web use, which would prioritize small filesize without a sacrifice in selection ordering or visual accuracy. To be fair, I just installed 2018 and haven’t tested its SVG waters yet, so we’ll see how Adobe managed to mess that up handle that.

Finally, it’s worth mentioning SVGO (and the web-based SVGOMG). Very customizable optimization, definitely more useful once one starts dealing with more intricate, complicated SVGs. I’m happy to optimize mine down by hand, and stop there – but I’m keeping them to a handful of kilobytes anyway.

Scaling visualized data using common multiples

How we’re presented with data skews how we interpret that data. Anyone who has read a lick of Tufte (or simply tried to make sense of a chart in USA Today) knows this. Many such commonly-encountered misrepresentations tend to relate to scaling. Volatility in a trend line minimized by a reduction in scale, perspective distortion in a 3D pie chart, a pictograph being scaled in two dimensions such that its visual weight becomes disproportionate – technically, the graphic may accurately line up with the values to be conveyed, but visually the message is lost.

In taking mandatory domestic violence training at work recently, I was thrown completely off by a statistic and accompanying graphic. The graphic (albeit using masculine and feminine silhouette images) resembled:


…with the corresponding statistic that one in every four women and one in every seven men has experienced domestic violence. While the numbers made sense to me, it took me a while to grasp them, because the graphic was simply showing more men than women. It’s something akin to a scale problem, our brains are going to see the obvious numbers – four and seven – instead of readily converting the graphics into their respective percentages. How to fix this, then?


If we simply repeat our graphics such that the total number in either set is a common multiple, now it’s much simpler to process the information that we’re supposed to process. We might not immediately recognize that seven in twenty-four is the same as one in four, nor that four in twenty-four is the same as one in seven, but we do know that seven is greater than four (which caused the problem in the first place earlier), and now we’re not dealing with mentally constructing percentages from a simple visual.