… 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
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 interactive elements in
HTML5, should not come as a surprise. We have missed that functionality far too long already.
My solution covers more use-cases than the proposed one though, and already works in all HTML5 capable browsers.
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
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 true origin of a famous quote … will always be “unknown”.”
Read that as: no matter what someone becomes famous for saying, one can be sure someone else on this earth has said the same thing before. Finding out who really said what first is of course all but impossible, and in most cases it doesn't really matter either.
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
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.
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.
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
-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
checkbox with an
and describe the context.
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
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.
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 background image, and repositioning – from bottom to top, easy to control.
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
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 clarification. 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
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
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
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 “precondition” content
and leave out potentially 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
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
(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.
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