annotations

… revealing information in images.

That text and diagrams in images can be pretty inaccessible for end-users relying on Assistive Technology (AT), is a problem. That content in images can be difficult to grasp visually regardless of software, doesn't make the issue any less problematic.

Populating an image's alt-attribute with proper text, can to a certain degree solve the issue for AT users. Apart from that proper text rarely ever is found in alt-attributes, it does very little for anybody else who may find content in images difficult to interpret. Also, text in alt-attributes should ideally be kept as short as possible, and quotes are rarely ever all that short.

(17.oct.2016) That my solution has some similarities with the proposed inter­active elements in HTML5, should not come as a surprise. We have missed that func­tion­ality far too long already.
My solution covers more use-cases than the proposed one though, and already works in all HTML5 capable browsers.

empty alt-attributes

I tend to leave alt-attributes empty, and expand the full meaning in surrounding text instead. Images then become visual additions to what is already presented in clear text, and as such they are redundant.
This strategy works fine in most cases, and only automated accessibility testing software complains about those empty alt-attributes.

Easy to find cases where that strategy simply won't work though, and one such case is quotes found in images. For instance, compare the following image containing a quote…

… with the following image containing the same quote, but followed up by an annotation that – although initially invisible – is available to all end-users…

The annotation above – which becomes visible on screen when you click or tap on the image – is a straight copy of the text in the image, plus an expansion. It could as such be part of the regular text, if it weren't for the apparent redundancy of having double up of the quoted text.

Not all designers, or their clients, like to double up stuff just to make sure all end-users “get it”. Besides, “duplicating content” in different formats can be seen as noise in web pages … not unlike the SEO-stuffed and mostly meaningless alt-attributes one can find on many web-sites.
Keeping annotations out of sight until they are called for – like I do here, is a practical solution in most cases.

always available

Annotations presented like the one above, should always be available to users of AT software/​hardware. This means that in most cases content can not be hidden by display:none, so I am left with choosing a suitable “off-screen” method to achieve the visual hiding of annotations.

Designers who only cares about the purely visual, may have problems wrapping their heads around the concept of “non-visual styling”. However, getting all the non-visual right is at least as important as tailoring any visual details in a design.

hide off-screen

In this case I have reused one of the “off-screen content” solutions that was already baked into the site-wide stylesheets, one where elements are floated and pulled about -5000px left of their original position using negative margins. Advantage: it doesn't cause page-jumping if/when containing links or other focus-catchers, as the off-screen content is packed vertically in line with the on-screen content it belongs to.

By limiting the off-screen elements' height to 1px and hide the overflow, and then apply a margin-bottom of -1px, an added padding-right of 5000px can act as an on-screen tail that doesn't take up space.
This on-screen tail isn't absolutely necessary here, but I use it for some other CSS trickery elsewhere on pages and it doesn't disturb the annotations – just have to turn off borders and background on elements when they are off-screen to avoid visible tail-stripes across the page.

Assistive Technology conciderations

In general I do as little as possible to “correct” anything for AT software. Proper use of HTML5 markup should in itself assure that well-organised content works reasonable well for users of AT software.

In most cases an aria-hidden is put on the checkbox, as the off-screen annotations are arranged and styled to be read in sequence by AT software with no need to “visually open” anything.

There are however cases where use of the checkbox is necessary also in AT software, as when off-screen links and video/​audio content have to be totally blocked (display:none) to avoid creating visual and audible problems for anyone. In such cases I replace the aria-hidden on checkbox with an aria-describedby, and describe the context.

triggering

The reason for using an invisible input type="checkbox" element to select opening and closing of annotations, is of course that this will always work – in new browsers – regardless of whether we're dealing with mouse pointers or touch screens.
That some call such use of input a hack, doesn't bother me – it passes as HTML5 and most certainly gets the job done across browser-land.

Others may prefer to use javascript to create the same func­tion­ality.

indicator

I have added a tiny “speech bubble” to the annotation itself to indicate that it is there, but its presence can of course be indicated any way one might like. One only has to remember that indicating by :hover effects alone doesn't do much on touch-screens.

The “speech bubble” is added as generated content to the first annotation element, so when it shows up there has to be an annotation attached to the image. The way the “speech bubble” is attached makes the switch from a “+” to a “-” sign – it's a back­ground image, and repositioning – from bottom to top, easy to control.

limitless annotations

My idea is that it should be possible to add annotations to any case that need some comments and/or additional info that won't fit naturally into the normal page content and/or layout. Thus, my solution is as open-ended as I could make it without creating too many conflicts in an already quite complex CSS setting.

In theory one can attach a whole series of annotation elements (text and images) to a case, but it makes sense to limit them to what is absolutely necessary for clari­fi­cation. One paragraph will usually do, but I have included examples of cases that clearly need more.

(29.oct.2016)There is also no precondition that the annotation has to come after the annotated element. In a later case the annotation is organized so it pushes the annotated image down when annotation is revealed. In that more extreme example the annotation is also split up in suitable chunks with place-holders in between, to allow for more visual “hide annotation” areas on screen.

choice of containers

For “quotes in images” I have found blockquote to be the right element. A figure may seem better when we need to expand on other types of “content in images”, but figure comes with serious restrictions and limitations that may make it of little real-world use.
Not the ideal choice maybe, but if all else fails to pass standards there's always the humble div.

For the annotation itself – the element that is pulled off-screen: any element that seems appropriate for the task at hand, and which is allowed inside the chosen container, can be used. With the restrictions HTML standards put on what elements some containers may contain, our selection of elements to carry the annotation(s) can at times be fairly limited.
Again, anything can go inside the humble div, and all block-elements allow for spans that can be pulled off-screen.

fine-tuning

By adding classes from the site-wide set of microtunings, I can tailor details in each instance to the case at hand. Whether or not a border is needed. Whether or not the annotation should be layered in front of the clickable layer (default), or be layered behind it. And so on.

I find this kind of detailed control absolutely necessary, to avoid having to “pre­con­dition” content and leave out potent­ially important details to make it fit. No “one size fits all” solutions will work, as there are no two exactly identical cases.
Annotations may for instance contain links – references to sources for instance, which will be inaccessible if the annotation is layered behind the clickable layer. Images on the other hand may as well be layered behind the clickable layer in most cases, and borders may fit in well on images.

easy to use

The solution must work well in a fluid / responsive layout. The annotations must not cover up anything else, so it must be turned on and off to get access to it as well as all the other content in the page.
I have tried to cover all such issues on this site, and haven't run into any real problems. I am sure I have overlooked a few bordercases though … something for another day.

an idea, served without code-sample

On this page I have described and exemplified an idea that I recently have found good use for on my own site. Should have implemented it much earlier, but better late than never they say.

As mentioned above, this “image annotation” solution is built on, and is integrated in, existing site design, and as such it will need a few rounds of testing and tuning across browser-land. Have to make sure the CSS cascade works for me as I intended.

I see no point in presenting actual code (markup and style, etc) for such a tailored solutions. It is standard HTML and CSS that anyone somewhat proficient in front-end coding can put together in an afternoon, and likely make it fit better to their own cases than I can. Besides, anyone can open up the markup and styles in code-view and examine it.

(08.oct.2016) I have however changed my mind about releasing code, so those who are interested can check up the basic CSS driving the examples on this page without having to plow through the site-wide stylesheets.

(06.oct.2017) Updated the the basic CSS to show latest upgrades to cover the latest and more complex cases on site.
Have fun…

sincerely 

Hageland 30.jun.2015
08.oct.2016 - minor rewrite after CSS upgrades
17.oct.2016 - added ref to HTML5 proposal
29.oct.2016 - added link to and info about 'basic-howto.html' example
06.oct.2017 - CSS upgrades
last rev: 06.oct.2017