Tallan Blog

Tallan’s Experts Share Their Knowledge on Technology, Trends and Solutions to Business Challenges

Good Design is Accessibility.


Accessibility isn’t always about ARIA roles and text to speech, it’s often about simply good design. There is a range of disabilities that need to be considered when working with the web. We often just think about blindness, but we should remember to consider the other things that make surfing the web difficult for people. Even under “visual” there are different kinds of disabilities, including color blindness and issues with low contrast visuals. Without going into detail about which disabilities need exactly which changes to make the web easier for them to use, let’s take a bird’s eye view and concentrate on good design. Design standards are considered “good” because of their time proven and well tested concepts. Some of these may seem obvious, but it’s easy to forget the core concepts when working on a design.

Color Palettes

Use of a palette, once selected, should be in accordance with basic rules of graphic design and color theory. Color choices and groupings require brand-minded, usability, and aesthetic decisions to be made about color harmony / color dissonance, value and contrast comparisons, use of a color for a text element vs. background element, and proximity of colored elements in relation to each other. To help you choose or change a palette, or add to a palette already in use, refer to one of the many color palette designers, like http://colorschemedesigner.com/. It should be noted that there are no hard and fast rules that will guarantee a color combination that is liked by all, because color choices are very subjective.

We can, however, reduce color dissonance, improve legibility, and elevate the aesthetic value of the application by following these few guidelines:

Use color to create distance cues. Windows, tabs, and other elements which are layered atop each other must look as if they “come forward” or “go back” from the user’s viewing plane, and should mimic “atmospheric perspective” (explained below). To that end, title bars and borders of active windows should be more saturated and of higher contrast than windows behind them. Similarly, the label of the selected tab in a tab set should of higher contrast and saturation than the other tabs which are not selected. Choice of the font color for the label of a selected tab will depend on the color of the tab itself, but should exhibit a higher contrast ratio than that of the unselected tabs.

Generally, saturation and contrast can be related; increasing the saturation of a color in a set of colors with the same starting saturation will increase the contrast between the pair; be wary that this is not always the case, but it can be used as a rule of thumb. Contrast can also be changed by increasing the amount of black or white in a color. Increasing the black levels in a color creates shades or darker values, while increasing the white levels creates tints, or lighter values.

These suggestions derive from the concept of atmospheric perspective, a natural phenomenon that makes the color of objects in the distance continually decrease in contrast and saturation the further away they are positioned from the viewer. Conversely, elements in each successively closer plane increase in contrast and saturation. The atmosphere acts as a veil to “dim” objects in the distance, allowing the objects that are closer to the observer to show truer color fidelity, stronger contrast, and more sharpness. Colors with higher saturation and higher contrast are interpreted by our eyes to be closer to us (or, the user).

The other tabs in the tab set, because of their comparatively lower contrast, seem to “fall back” behind the active tab, so the relationship does work within the tab set. Lastly, because of color unity of the active tab and the tab information frame, we associate the content within the frame as belonging to the active tab.

Reduce problems arising from complimentary colors. Color palettes can be constructed from some well-known and time-tested “formulae.” The usual formula is to choose one base color and then to use other colors to create schemes, or families. Schemes can be monochromatic, complementary, triads, tetrads, analogue, or a mix. Problems usually surface when using complementary colors, which sit opposite each other on the color wheel.

Do not use complementary colors of similar value in large areas, or put colored text over complementary backgrounds, or use text in such small sizes or weights such that the background color seeps or “bleeds into,” or overpowers the foreground text (this applies to all schemes). See the example below that shows a limited-palette color wheel of blue/green and orange/red color complements on the left, and the green/red and blue/orange complementary paired squares next to it.

Notice that the colored text in each of the top two squares is hard to read because the words are applied on complementary colored backgrounds and create visual vibrations. Conversely, backgrounds created from tints of the main colors (in the 4th quadrant of each square) allow text to be quite legible, because they are less saturated and don’t produce the vibrating effect (these colors are not of similar value).

Complementary colors may be used throughout an application as part of the overall color scheme, but the placement of the specific colors will determine the harmony or dissonance of the combination.

For more examples of good and bad color contrast, visit WeAreColorblind and see their examples. It will give you a great idea of what a person with a color deficiency sees when looking at the web.

Monitor the color contrast of UI elements. There are recommendations of contrast ratios for accessibility standards for low-vision users, which can help everyone regardless of their visual acuity. As in the complementary color discussion above, the size of text plays into these acceptable contrast ratios as well. WebAIM, an initiative of Utah State University, is a site that lobbies for accessibility standards on the web, and provides an online color contrast checker to help designers meet this recommendation. It is found at http://webaim.org/resources/contrastchecker/. Web Content Accessibility Guidelines (WCAG) from W3C has two levels of conformance, AA and AAA. Normally, the minimum color contrast ratio for text (and images of text) to be legible on a colored background is 7:1. However, large sized text (16px or above) has a lower requirement of 4.5:1. The colors #912025 (red in the example above), and #999999 (a dark gray) do not pass either the AA or AAA levels for Normal sized text, and only passes the AA level of conformance for Large sized text. Your objectives should be to choose pleasing colors by eye, and then check that the choices will pass the AA and AAA sizes of the small text. If the small text passes the requirement, the large text will too.

Some color combinations do not yield a high enough contrast. Some make text completely illegible, while other combinations work quite well because the contrast between them allows the text to separate from its background. Furthermore, text in a normal weight seems to break down when paired with especially powerful background colors because of color bleed.

Use color to amplify meaning. Do not use color alone to convey meaning.  This greatly impacts accessibility. Put the color in relation with a text label, or some other indicator. As an obvious example, using only the color green in a box to indicate a “System OK” is not only ambivalent without explicit text labels to cue the user, but makes it harder to comprehend the meaning for those with low-vision or who suffer from one of many types of color blindness, since they won’t be able to differentiate color changes in the box itself or in relation to other elements around it. Instead, use text or iconic representations for meaning, and use color for enhancement.
Create redundancy of meaning throughout the UI whenever possible (not redundancy of UI necessarily). Links on the Web have redundancy built into them (color and underlines) for accessibility enhancements. While accessibility for application design is less valued because of the concentration on aesthetic design, try to apply the same rules whenever possible so that the fewest number of people are faced with usability or accessibility issues.

imagery from wearecolorblind.com

Remember that green and red are two of the most problematic colors for color-blind users, and that color blindness has many forms, including deuteranomaly, which affects 5% of men and 0.4% of women.

Think about it this way: if the screen were presented as a black-and-white printout, would the viewer still glean the same information as easily as if you did not build in redundancy? In other words, if the color is an aesthetic highlight, and not used to convey a particular state or meaning, you’re probably safe.

Fonts & Text

As a general rule, do not use serif fonts for on-screen display, unless used in larger sizes (usually for headlines and such). Note that fonts will look different than expected sometimes because operating systems, browsers, graphics cards, and screen resolution all play a part in how fonts are displayed.

Text size is traditionally measured as the height of the lowercase letter x (“x-height”) for any particular font family; this is the reason fonts from two different font families may look substantially larger or smaller even if their font sizes are the same, and why some fonts look “cramped” vertically even if given the same line height as another font of the same font size but which has a different x-height.

One example:


Verdana 11px normal and bold
Verdana looks larger than Arial when similar sizes are compared. Use Verdana for data entry fields and form editing; Verdana is better for readability because of its extended spacing between characters; however it is not aesthetically pleasing in large concentrations; note that instructions or non-editable notes within the form should always be displayed in Arial using one of the specs listed above.

Use of italics: Refrain from extensive use of italics. Italics on the screen are hard to read, slow users down, and are often illegible in small sizes. If absolutely necessary, italics may be used sparingly in small lines of text for instructions or notes areas that are not critical for users to complete their task.

Line Height

Text spanning more than one line vertically is more legible if the minimum line height is at least 120% of the text size. That means 10px text should have a baseline height of 12px. Most times “normal” line height is automatically set at 120% by the development environment or design software being used.

In rare cases, line height can be set “solid” at 100% without detriment. This means a 9px font’s line height is set at 9px. Messaging in cramped spaces can withstand this deviation from the norm, as with in-line error messages, or tooltips.

Smaller font sizes benefit from larger line heights if the text block is dense, and if the line length is especially long. Larger text sizes do not always require proportional line-height increases, especially if used with a fixed line length.

Data (i.e., tabular matter) output to the screen is especially bound to this rule. Long lines of data are easier to follow across the screen or page if there is ample space between the rows of data (more on data visualization later), and so 150% or 200% line-heights are not uncommon when displaying data to be readable. Alternatively, if grids are used to help guide users’ eyes across rows, the line heights may be more compressed without detriment.

The following table gives some recommendations for line heights:

Font Size
line height
line height
line height
10px 12px 15px 20px
11px 13px 16px 22px
12px 14px 18px 24px

Line length

Lines of text are easier to digest visually if the horizontal length of a line of text is not too long or too short, otherwise it slows down reading speed and comprehension. In software however, this rule is rarely needed except for displaying help or error messages.

According to a traditional design rule, an “ideal” line of text is 39 characters (1.5x the length of the alphabet), regardless of the font size. However, on screen, the length of a line of text can be increased up to twice the rule (and sometimes longer), and still be readable, if the rule of line-height is applied judiciously. Minimum and maximum line lengths should fall within this rule of thumb for long blocks of text, in conjunction with the recommended line-height described below.

Buttons & Forms

It is best to reduce the variations of button sizes throughout a website or application. We suggest using no more than three sizes of icons.

Designs must include larger buttons sizes, particularly if there is going to be a mobile version available. According to a study by Microsoft, we recommend that target sizes should beat least 9.2 mm for single-target tasks and 9.6 mm for multi-target tasks (e.g. dropdown) in order to keep the dimensions of the targets as small as possible without decreasing performance or frustrating users. Now remember, those mm measurements are physical sizes. For a 300ppi screen, 10mm would be 118 pixels. It’s best to keep to a size that will be easy for people to press with their fingers or a stylus. A lot of disabilities include motor coordination issues and some people require alternate input devices.

Furthermore, buttons that represent opposite functions (e.g. Save and Delete) should not be in close proximity to each other. They should be situated such that overshooting the target with the mouse pointer will not accidentally allow the user to click on the button that does the opposite of what the user intended. Another way to think about this is to ask whether the mistake could be fatal, or if it is insignificant to the user. If the mistake will be fatal, there is good reason to separate the icons or buttons from each other.

TIP: Notice that the larger the button, the less space is needed between them. But, at no point should icons butt up against each other. There should always be some space between icons or blocks of buttons so that being at the edge of one icon users can’t accidentally slip and click the wrong icon. We suggest no less than 5px between icons as a standard, and an absolute minimum of 2px between icons if absolutely necessary.

Radio Buttons & checkboxes

  • Keep in mind the basic uses of radio buttons and checkboxes:
  • Radio buttons are to be used when ONLY ONE choice is wanted among multiple;
  • Checkboxes are to be used when ZERO, ONE or MANY choices may be selected.
  • Both radio buttons and checkbox elements should be placed on the left of their respective labels.
  • Dimensions and spacing of radio buttons and checkboxes and their corresponding labels are as follows:

  • Radio buttons and checkboxes should be spaced at least 20px apart, measured from the end of the previous label to the beginning of the next radio button or checkbox, regardless of the length of the label:

  • Checkbox labels should not change if the checkbox is clicked. The absence or presence of the checkmark should be the indicator of the state, not the label itself. Changing what the label says is confusing to the user because it is not a standard pattern.

Checkboxes are binary UI elements whose states are either ON (checked) or OFF (unchecked). Though some applications do this, they should not be used as 3-tier toggle boxes as in the following example:

  • If a 3-tier-state is desired, use radio buttons or a dropdown / combobox instead.

Checkboxes and radio buttons should never be presented without a label, unless being used in a matrix. Do not supply users with a checkbox to answer a yes/no question. Instead rephrase the question to be a statement, and use the statement as the label of the checkbox.



  • Radio buttons – not checkboxes – are the logical choice for when you want users to select from only two options (for example, Yes or No). The default, or most desired choice should be presented first unless the form is a survey.
  • Use a colon if desired, if a label for a radio button is a sentence fragment; but be consistent:

Modal Windows

Modal windows are the preferred method to let users take a sidebar to complete a larger task. Rather than sending users to a main window that takes the user out of context, a modal window appears as a popup layered on top of the main task window, with a gray veil over the workspace below. Once data is entered and submitted using the modal window, the data is saved and the user is sent back to their original task.

Modal windows are not given maximize or minimize buttons, only a button to close. Users are forced to deal with this window and cannot access the workspace until they successfully enter data, or till they can cancel the task. See the diagram below for an example of this workflow.

Modal windows are useful when the design needs multiple entry points to a data entry screen that is central to tasks within the same category.

Another use of a modal is to show a loading animation when data is being called or saved to the system and the user should not interfere. For instance, if you wish to block access to the UI until a large data set is successfully loaded, it is customary to give users some kind of visual indication that the system is still processing the task.

Dialogue Boxes

Dialogue boxes are used for interactions other than a workflow-specific task. For instance, when confirming a user action that may not be desired, to get the user to interact with the system to give the application some extra direction for doing an otherwise automated task, or making the user aware that changes are going to happen in the background.

The visual difference between dialogue boxes and modal windows is that there is no graying out of the background.

Error messages

Errors come in a few different flavors. Some, like data entry errors, may be handled in-line with the form element, or as a fading notification. Other errors which can impact the system more deeply, whether user-generated or system-generated, should be displayed as windowed error boxes, having the same attributes as a dialogue window but with only one option (OK).


This might seem like a lot of information about design, but using tried and true design tactics and standards is the best way to start with accessibility. Remember that a lot of internet users have some sort of handicap, and following these simple rules will go a long way to pleasing them. Accessible websites are a right of the individual, and businesses are required to make an effort to ensure accessibility. These concepts are going to help all of your users, and create a more pleasant experience for everyone.

Share this post:

1 Comment. Leave new

The Use of Color in User Interfaces
February 15, 2013 3:13 pm

[…] This post was recently updated. Please refer to the new article, Good Design is Accessibility. […]

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>