Current location

Best practices for accessible diagram design (draft)

What's this?

Below you find the draft of an unpublished chapter of a forthcoming book (Diagrammatics, ed. by Clive Richards, Gower publications). The chapter outlines the universal design approach and identifies the requirements of three user groups: Low-vision users, blind users and users with cognitive and learning disabilities. The requirements of these groups in terms of perceiving and understanding diagrams are quite different, so each set of requirements is followed by a specific list of best practices. For other groups like motor-impaired of deaf users, there should be fewer accessibility issues, but I may be wrong about that (tell me). All best practices together add up to what I believe should be taken into accout when designing universally accessible diagrams.

Some context

I did some research on animated diagrams in the nineties when I was studying at Coventry University. 18 years and some career changes later, I am returning to diagrams to contribute a chapter about their accessibility.

Where did I get these requirements and best practice lists from? I made them up, drawing on own experience as much as on various resources that are too numerous to mention. In many cases, I would actually be hard pressed to pinpoint where exactly I found a particular best practice.

There are certainly gaps and things that warrant improvement. I would like to invite both accessibility experts and users of diagrams to provide your remarks, additions and critique in the comments section below the draft (or on the Webaim mailing list)!

---- BEGIN DRAFT----

Introduction

Diagrams are great for visualising data or illustrating relationships in some domain. Process flows and cycles, statistical charts, organigrams, decision trees and other types of content can be laid out on a two-dimensional plane – often labelled, grouped and arranged, colour coded and linked by lines or arrows. Such visualisation is an important complementary alternative to the textual mode of communication.

Not everyone, however, is fully capable of processing visual information. The percentage of the population with decreasing eyesight or visual impairments is growing. A designer subscribing to a universal design approach will aim to include this population. Diagrams can be made accessible in a way that they remain useful also for low vision users who require enlarged text or special adaptations via assistive technologies such as screen magnifiers. Even blind readers using a screen reader to get voice output or a refreshable braille display can benefit from diagrams that have well-crafted text alternatives. After all, a diagram often sums up important aspects of some domain, generalising for the sake of clarity. Such succinctness is a benefit to all users, even those who cannot (easily) process diagrams visually.

Another aspect is the accessibility of diagrams for people with cognitive and learning disabilities. Requirements here range from dyslexic people benefitting from particular typefaces to intellectual disabilities of people with Down syndrome helped by simple sentences and a direct style. Plain language recommendations that address cognitive disabilities suggest that text should be accompanied by pictograms or graphics which reinforce the meaning of text – a requirement that diagrams can often meet very well. Plain language recommendations also suggest avoiding whenever possible complex grammar, abbreviations, jargon, and foreign or technical words.

The accessibility of diagrams is not only relevant for the relatively small percentage of people who are legally blind, have strong visual impairments or some form of cognitive or learning disability. In an ageing population which sees its retirement age pushed back to the point where the working life will eventually end just before the onset of senility, the legibility, intelligibility and usability of information for people with decreasing eyesight or less reduced cognitive and learning faculties is increasingly a mainstream issue.

Intention and structure of this chapter

The intention of this chapter is to give the reader a broad understanding of the basic requirements of users with disabilities, especially blind and visually impaired users, but also people with cognitive and learning disabilities, and point out workable design strategies for making diagrams as universally accessible as possible. The chapter will not enter in any detail into the discussion of relevant standards like the Web Content Accessibility Guidelines (WCAG 2.0) [1] that describe success criteria for accessibility, or specific technical solutions like SVG [2] or WAI ARIA [3] that furnish semantics for interactive web content. There are ample resources for that [4],[5]. We also do not discuss in any detail the different ways of offering alternative text in HTML [6]. Instead, the chapter will look at the way users with different disabilities experience diagrams, sum up their main requirements, and provide three best practice lists that should help making diagrams more inclusive and more usable for all.

The focus of this chapter is on online diagrams. ‘Online’ is meant to stand for electronic versions of diagrams experienced on a computer, either via the screen or via auditory or Braille output. It is not meant to imply that the diagram in question lives on the internet – it can equally be a local file.

One reason for the focus on online diagrams is that these can be scaled and viewed in custom modes (like high contrast or inverted colours) which are important for low vision users. Customisation options are an advantage when following a universal design approach. The second reason for focusing on online diagrams is that more and more media consumption takes place online. Increasingly, documents are never seen on paper, and this trend is likely to continue. However, many of the recommendations regarding the visual layout and accessibility of online diagrams also pertain to the design of traditional printed diagrams.

At the outset, I will briefly cover the universal design approach and define what it means for the design of diagrams seen as a visual form of language. I will then describe requirements of blind and low vision users and those of users with cognitive and learning disabilities. Each of the three requirements sections leads to a different list of best practices. Diagram designers can use these lists to optimise the accessibility of their design.

The universal design approach

Universal design aims to make information, as well as more generally products and built environments, accessible to all − to people of different ages, situations, and abilities. The concept entails a shift away from accessibility as an afterthought to a position where a wide range of usages and access modes is considered at the outset. To give an example: In a universally-designed building, add-ons for accessibility such as the proverbial wheelchair ramp would never be necessary since designers would have made sure at the outset that all entrances be put at street level.

The payoff of the universal design approach goes far beyond people with disabilities: level entrances, for example, also benefit elderly people using walking aids, people with prams and push carts, emergency services, and delivery people pushing trolleys.

A similar payoff exists in the realm of information. Good text size and contrasts, plain language and a focus on salient features make diagrams easier to process for all. With a meaningful text alternative, the diagram becomes usable also for blind people. The text alternative will also provide a useful fall-back for users who for whatever reasons struggle to make sense of the visuals.

Diagrams as language

The reading of a diagram is a complex mental activity and its meaning is often far from obvious. Symbols and icons are often less self-explanatory than designers would like to assume, as any informal user testing will show. What do we actually mean when we talk about ‘reading’ a diagram?

The structure and aesthetics of diagrams have already been investigated in great detail - see, for example, the books on the visual design of information by Edward Tufte [7], or Clive Richards' seminal work Diagrammatics [8]. Here and elsewhere, we find references to a ‘visual grammar’ organising visual and textual elements as a kind of language. Seeing its roots in early codified image systems such as the Egyptian hieroglyphs, the diagram-as-language research tradition includes the conception of a particular simple iconography representing concepts and their relationships, Isotype, by Neurath and Arntz (1920) [8]. Isotype was even explicitly mapped to C.K. Ogden's Basic English, a restricted set of English terms [9]. The Isotype approach is still influential in today's pictograms and icons, and may be traced in the graphic or pictographic equivalents used in plain language texts (which often lack the clarity of Isotype).

Reading modes and requirements

Without delving into the complexities of diagram as language, it may be useful to make a broad distinction between two modes of reading that affect the way diagrams can be optimised for blind and low vision users: exploratory or sequential.

In the more common exploratory reading mode, the user takes in the diagram as a Gestalt and then enters a complex process where the eye moves between elements to explore their meaning and context in a recursive criss-crossing fashion – reading element labels, following arrows, inferring meaning from groupings that itself will be labelled, and so on. An example may be a diagram showing the water cycle (figure 1). Such a diagram can be “read” in any order – it does not require a particular reading sequence.

Figure 1: Diagram of the hydrologic cycle. The image depicts the cycle of water evaporating, turning into clouds, falling back to earth in the form of precipitation and being filtered through sediment.

In contrast, some diagrams suggest a sequential reading mode. This type is usually text-based and often informs some practical activity. An example of this is the social media response chart which is processed in a given order with decision points on the way (figure 3), another is the flow chart example in the already mentioned document HTML5: Techniques for providing useful text alternatives [6].

Figure 3: Air Force social media response chart. The chart tells public affairs personnel how to handle social media posts related to the US Air Force in the form of a decision tree chart.

If we accept the language view of diagrams for the purpose of discussing the universal design approach, the leading question of our chapter might be phrased: How do we approach the design of diagrams to afford as best as we can competent readings by all? For this, we need to be aware of different ways of reading employed by blind and low vision users which lead to specific requirements. The wide range of cognitive and learning disabilities makes it is difficult to enlist concise requirements for this group, but we can treat it as an edge case of the general audience.

Requirements of low vision users

Low vision users need a strong magnification in order to take in visual information. For printed matter, they use portable electronic magnifying glasses or desk-based video magnifiers with a flat cross table to simplify moving documents in the horizontal or z-axis. For viewing electronic documents, they use magnifying software [10] which can dramatically increases the output size, preferably on a very large screen. As the magnification scale increases, the section in view becomes smaller, i.e., less of the surroundings and structure of the document remains available. Therefore, context has to be gained by shifting the section displayed (e.g., by moving the cross table horizontally or forwards and backwards, scrolling content in an electronic magnifier, or tabbing back and forth through focusable elements to move the focus to next or previous elements, which often entails possibly disorienting abrupt movements or visual cuts.

Users with strong visual disabilities often use screen readers or other means of auditory output in addition to magnification, sometimes only for those elements that they find too small or lacking adequate contrast.

Best practices to address requirements of low vision users

Ensure good default contrast. This check targets things like the apparently fashionable grey-on-white text or washed-out interactive elements often seen in web design. They can make content utterly unusable for low vision people. According to WCAG 2.0, a text contrast of 4.5:1 is sufficient (3:1 for large text). While WCAG does not require contrast for graphics (other than for ’text-as-image’ elements) it should be clear that graphics in diagrams (icons, symbols, outlines, edges, arrows, etc.) should also meet this requirement. Dark or white outlines can be used where blocks of colour do not contrast enough. Some computer environments like, Windows, allow user-selectable custom contrast settings on the system level. Video magnifiers also have modes like black-and-white or inverted colour, but these will often not fully compensate poor contrast in the source material.

Ensure good default text and element size. The larger the size of text and graphic elements, the less magnification will be required to recognise them, which in turn means that more diagram context will fit into the visible section. But larger text and elements also mean that fewer elements will fit into the space allotted for the diagram, be it a document page or a screen viewport. This can be an opportunity to think about reducing the complexity of diagrams by increasing the level of abstraction.

Think of users with colour vision deficiency. The use of red and green as sole means of differentiation should be avoided because it will affect people with colour vision deficiency (colour blindness).

Pick easily legible typefaces. Sans-serif typefaces are usually preferable over serif typefaces. For blocks of text inside diagrams, make sure the line length of lines is not too great and that the spacing between lines is sufficient. The longer the text lines, the more horizontal scrolling will be forced upon the low vision user viewing magnified text.

Use scalable typefaces, not images of text. For online diagrams, try to ensure that text allows for lossless magnification where edges remain sharp. Use typefaces rather than bitmap images of text.

Place labels close to the elements they label. The limited section of magnified content visible at any one time suggests a judicious use of proximity and alignment. Labels should be kept close to elements whenever possible.

Ensure clear grouping. Where elements are grouped, it is important to emphasise that grouping via sufficient offset space, clear outlines, or contrasting backgrounds.

Prefer orthogonal arrangements. Since scrolling and cross table operation both happen in an orthogonal fashion, it is beneficial to align elements horizontally or vertically to make the diagram easier to explore.

Use of grids and leader lines. Leader lines or edges can be used to make relations/connections more explicit, for example when labels cannot be placed right next to elements. In charts where line or column labels impart meaning to chart elements, a grid with contrasting lines is essential to bridge the physical and cognitive gap when reading requires scrolling or a device or cross table movement.

Requirements of blind users

Blind users render electronic information as synthetic voice output, usually via some screen reader software such as JAWS, Window Eyes or NVDA. Some also use tactile output on a Braille display, often in addition to screen reader auditory output. The screen reader software allows users to navigate texts in different ways:

Linear reading, e.g. by using the arrow keys to move down (or up) through the content, or issuing a command that reads the entire page

Direct stepwise navigation by tabbing and shift-tabbing to next or previous focusable elements

While embossed diagrams exist for some select application areas, printed diagrams are only potentially accessible to blind users to the extent that they contain text that can be converted to text via scanning and OCR algorithms. While linear printed text can be converted into electronic text with a high degree of fidelity, this is not the case for printed diagrams. Even where textual elements (labels legends and so forth) are correctly captured, the interpretation of the all-important element relationships that is expressed via positioning, linking or grouping is (currently) beyond the capabilities of OCR software.

An intriguing turn comes with the availability of direct tactile exploration of two-dimensional content on today’s touch screens. On touch devices like tablets, screen readers are usually available as preinstalled part of the operating system, for example in iOS, Android, and Windows 8 [11]. Here, it is possible even for blind users to directly perceive semantic relationships (enclosures, proximities, orders) of on-screen elements – provided that elements are treated as distinct and given meaningful accessible names triggered at their location.

Best practices to address requirements of blind users

Provide descriptive alternatives of the entire diagram. Blind users of diagrams need usable text or audio alternatives. Depending on the type and format of the diagram, there are several options. A self-contained text or audio alternative can be provided alongside the diagram, or a link in the immediate diagram context may lead to it. A good text alternative of a diagram will be difficult to write for complex diagrams that go beyond simple sequences of flows and show a multitude of relationships. Text-based alternatives to flow charts or hierarchical diagrams can be hypertexts with links that reflect the nodes, decision points and alternative traversal paths (see below).

In articulated diagrams, provide accessible names for direct exploration. When online diagrams are implemented in a way that keeps individual elements articulated, i.e., semantically separate, for example, when they are implemented as Scalable Vector Graphics (SVG), or HTML Image maps, they lend themselves to direct exploration. For this, the individual elements need an accessible name. This name can be provided as actual text (not an image of text) or as the text label of graphic elements. In some cases, it can even be invisible. HTML has attributes like alt and aria-label that provide an accessible name for images in cases where the layout does not afford the placement of visible labels.

In articulated diagrams, provide a meaningful reading sequence. Articulated diagrams should afford the exploration of elements via touch or keyboard navigation. On a smartphone or tablet touch screen, a diagram composed of individual, accessibly-named elements provides a haptic map of the structure for tactile exploration. The careful ordering of elements in the source code can afford a meaningful traversal of temporal or spatial sequences. For example, a sightseeing round trip might be rendered as sequence of names representing city attractions or stops, possibly with descriptive text for each attraction.

Provide alternative encodings of graphic decision trees. Diagrams of processes such as the flow chart in figure 3 are perfect cases where diagrammatic content that can be turned into a fully equivalent decision tree. This can be encoded in various ways: for example as hypertext with individual nodes or with skip links within one node; as dynamic, JavaScript-driven HTML form; or even as Interactive voice response system that would process spoken input as do many of today’s automated hotlines.

Make articulated network diagrams navigable. Diagrams of networks with connecting paths may also be rendered fully accessible via keyboard navigation (tabbing backwards and forwards, and arrowing up/down or left/right). In transport network diagrams, tabbing backwards and forwards might traverse a line station by station, while transport interchanges would present a menu of skip links or other constructs from which connecting services can be accessed. The recently completed W3C standard Scalable Vector Graphics can include full text. It has a lot of promise for the design of interactive diagrams. SVG can position elements visually and at the same time keep them in a meaningful reading order or hierarchy that is independent of the visual presentation.

Requirements of users with cognitive and learning disabilities

Users with cognitive and learning disabilities generally benefit from clear, well structured, plain and easy-to-read information that avoids unnecessary complexity – but so do all users. The requirements of this group may therefore simply be taken as an edge case of the general target audience.

It is clear that diagrams in many domains contain concepts and technical terms which are hard or impossible to understand for users with cognitive and learning disabilities – but again, the same is true for many non-experts. For general purpose diagrams, thinking of users who command a smaller vocabulary will often help finding better and simpler terms or images. Trying to reduce the complexity of diagrams will also increase the chance that users with cognitive and learning disabilities are not left out. And this will often make the diagram a better one also for users without cognitive disabilities.

Best practices to address requirements of users with cognitive and learning disabilities

Reduce overall complexity. As the comparison of figure 1 and 2 shows, the complexity of a diagram can be greatly reduced so the basic concept is brought out more clearly. Many aspects of the water cycle in figure 1 (water storage in the form of snow or glaciers, groundwater, evapotranspiration etc.) and consequently many elements and relationships in the diagram have been discarded in the much simplified version shown in figure 2. While this simplified diagram will not further an in-depth understanding of the water cycle, it shows its basic operation, as may be appropriate in primary education.

Divide and simplify. Consider splitting a complex diagram of a domain into several less complex diagrams of sub-domains. This can work well in domains where little interaction between subdomains. A master diagram may be used to show the relation of sub-domains.

Minimise intersections. Arrange the position of elements to minimise the number of intersections of edges, connecting lines, arrows etc.

Use plain language. Try to use language that is as plain and simple as appropriate. The simplified diagram uses common terms where possible. The simplified water cycle diagram uses rain instead of precipitation (technically a better, more general term) and just clouds instead of clouds and water vapour.

Avoid technical terms. The limits of this recommendation are evident when looking at the simplified water cycle. For the technical term evaporation, there is no simple substitute. Rendering this as action (Water evaporates) may be easier to grasp. Condensation has been simplified to small drops build. These action terms have been rendered in blue and italics to indicate their different character.

Use redundant coding. Redundant coding is already good practice in diagram design, but particularly important to accommodate users with cognitive and learning disabilities. Elements or relationships represented both by graphics and by text create a redundancy that can help users both ways: the text can help underpin the meaning of a graphic element, and vice versa. In the simplified water cycle diagram, the graphics (wavy lines reaching from the water surface up to the sky, and the arrows pointing upwards) link ocean to cloud to express the least tangible part of the water cycle. The arrangement literally and metaphorically positions the difficult technical terms in a context of familiar graphics and easier terms.

Express abstract dimensions in iconic or metaphorical ways. Abstract concepts can often be represented by familiar physical objects that are experientially associated to them. A clock face or hourglass can represent time or duration, a thumbs-up or a smiley approval. While this can appear corny, it is often useful. In the simplified version of the water cycle, thermometers have been added to include an abstract dimension that largely drives it: temperature. The trade-off is that any metaphorical element risks being taken literally. User testing would be needed to establish how many users will think that the thermometers are interpreted by some as strange flying objects.

[11] On Windows, the pre-installed screen reader, Narrator, has still limited capabilities beyond the rendering of the tile interface and the default apps, especially compared to the more mature VoiceOver screen reader on iOS.

Share

Comments

Comment by Henawder Titsoff | 27.07.2015

First of all if someone had a cognitive disability; what makes you thing they could answer CAPTCH (2+2). I would think if you were really concerned you would supply the answer as well (the answer is 4). Secondly - Has American history taught us nothing? Segregation is not the answer, although you're still trying such technique. Why not just put a sign on the home page saying this website is designed for blind users with black text on black background, over there is the one's for colored folk, and here for short people, and here's another for microsoft mobile folks.

Why not "accessibility for all" inclusion by design, universal design? Do it once, well!

Sounds easy enough, but it's not...

Reply by Detlev Fischer (INCOBS)

I don't intend to suggest that one should design different websites / diagrams for different users with different disabilities. These design checklists are complementary, addressing different requirements but adding up to what I hope would be diagram design according to a univeral design approach. Sorting by type of disability is just a structural decision to map best practices to different requirements (and these exist). It could also be one big list without structure but I think that would be a poor choice.

As to the CAPTCHA, I am sorry it is there, wasn't my decision and I can't change it (right now).

Comment by Stomme poes | 07.08.2015

Henawder: you can do almost all of these recommendations with "regular" diagrams. No back of the bus here.

Detlev: I generally found this useful but the blind sections are a bit stuck between introduction to someone who's never heard of a screen reader and a developer who would like to see (code)examples of some of the things you mention. Might depend on other chapters in the book though.

Cognitive is the part I wanted to know the most about. Are there any studies about common diagram techniques that tend to have (unexpected) problems among people with various cognitive issues? The repetition idea and bring jargon down to a certain school level are known tips for cognitive disabilities, but since those are a broad spectrum it probably needs more separation (similar to how blind-blind have pretty different needs from those using magnification).

I asked about the serif thing, as I've seen and heard this elsewhere but haven't found any definitive research either way-- while some people have more trouble recognising serif letters, others seem to use the serif lines at the bottoms of letters similar to a finger, to follow the current line and not lose reading place.

Though perhaps there simply isn't enough research that's been done out there to answer these questions.

Comment by Fred Esch | 10.08.2015

Another useful reference is the editors draft of the WAI-ARIA Graphics Module http://rawgit.com/w3c/aria/master/aria/graphics.html. The WAI-ARIA Graphics Module will bring native accessibility for web graphics.