Skip to main content

Color Contrast Tutorial

The Takeaways

  • Webmasters must take 100% responsibility for focus, hover, active, visited, and link indicators (outline, color/background changes, border, etc., while ensuring box/content size never changes) and their contrast when those can be controlled (such as by CSS in web pages). Minimum width outline/border is 2px.
  • Color and contrast are important but avoid red (or orange)/green and red/black foreground/background paring and, for greatest inclusion, approach or exceed the AAA 7:1 contrast ratio rather than trying to exactly hit the minimum AA requirements.
  • When text is over images always guarantee with a solid or limited transparency background that the contrast will be sufficient regardless of what image is in the background.
  • White backgrounds are fine, the user should have their device brightness adjusted properly for them, and do not waste time creating accessibility controls (such as for "night reading" or text size) because the user should be using the OS and browser tools for those.
  • Text, even within graphics should at least be true 16px at the size the image will be used but larger and/or bold could be better.
  • If placeholder text is used (not recommended) it must both have sufficient contrast to not be unreadable with the background nor be mistaken for a completed field value and it cannot vanish if it is instructive.
  • Meaning, when conveyed by color, must also be conveyed by at least one additional means such as underline, bold, or italics. Contrast with color is technically allowed but is difficult to do well and best seconded by a non-color means regardless (imagine that it must be clearly understood in a black-on-white printout).
  • Logos are exempt from contrast requirements but ... it is strongly suggested that MSU logo use always at least match its native green on white contrast.
  • Always verify your contrast with a contrast checking tool such as the Colour Contrast Analyser including for focus, hover, active, visited, and unvisited (perhaps by checking a grabbed image).
  • Label charts/graphics unambiguously, separate colors with high contrast borders, use hatching, etc. instead of or in addition to color, use different line and/or data point styles, include data point values if appropriate, and always provide meaningful alt text and/or state the graphic takeaway in the text (but don't repeat in alt),

Page Contents


Color is an effective way to incorporate design aspects into your documents and websites. However, it is important to make sure that fonts and images have a sufficient contrast or use other mechanisms to help visually impaired users understand the content. While the official minimums for AA are an absolute minimum MSU requirement it is best to also remember that MSU has a broad MSU inclusion policy so if you find yourself tweaking something to just hit the AA minimum you probably ought to stop and ask yourself if there is any justification for hitting the bare minimum. Usually there will not be so try to think more inclusively and meet or exceed even the AAA minimums.

The official contrast computation rules are not particularly perfect since they make some assumptions about green and/or hue that don't actually precisely track contrast recognition even in individuals without vision issues. For example, while it is technically possible to have some shades of green background on which white and black letters both exceed the minimum contrast ratio by a bit practically all users will likely find either the black or the white harder to read than the other. To properly test color and contrast issues you will need some way to accurately compare colors as can be done by following the instructions later in this document for "Installing the Colour Contrast Analyser" and using it.

Another reason for being more inclusive with contrast is that text over images contrast is often created with a specific image or images in mind for which the contrast ratios work "perfectly" but then someone else comes along and substitutes a new image or two and suddenly the contrast ratios do not work. The same holds true for various fonts with varying stroke widths, character widths, font complexity, etc. What worked well over an initial image doesn't work so well over the new one. In fact, a good idea when you see text over images with no way, such as a background box or a background cloud which is tuned to guarantee success for a particular font of a particular size and a particular color, is to imagine that the image was changed to one with perhaps black where white is now or white where black is now or very busy content right behind a key word in the text or even different text in a different font or color. Just eyeballing it, do you think the contrast would still be acceptable?

Focus, hover, active, visited

Unfortunately with the current wide variety of devices and browsers it is no longer appropriate to simply let the browser focus indicators handle their responsibility on their own. Other document display tools such as Word and PowerPoint don't give you the control that web pages with CSS (Cascading Style Sheets) do. When setting CSS for link, visited, hover, active, focus it is generally best to set the ones you need in that order for best behavior consistency. The indicators may be anything that does not cause the space taken up by the link or other active item to change size because changing size can cause reflow which causes page content to disconcertingly jump around and be distracting for all users.

The general conventions are that a link which is in its native state is both a different color from normal text and underlined, when it gets the focus (and often hover) something changes, typically a dashed outline, once it has been visited the color substantially darkens, and when active there is also at least a color change. But there are no hard and fast rules except that all color combinations must be distinct with regard to contrast or otherwise differentiated and the size cannot change. One goal is to have an MSU recommended combination that balances the required differences available with the next branding or web styling guide. It is also best to have only one consistent style indicator for (at least) focus throughout a website. Making the focus distinction by, for example, outline in one place but underline in another place and foreground/background swapping in another is not appropriate and is confusing for everyone.

Original browser focus indicators were a different color single-pixel-width outline for whatever had the current focus. With today's high-density pixel screens on all types of devices the single pixel width is no longer adequate and should always be set to at least 2 pixels wide. Solid is also more readily visible than dashed. Color choices must be done in a way that guarantees high contrast, something that is particularly difficult on images that are also links or controls (e.g., buttons). For such focusable items it may be necessary to provide alternative class definitions/designations understanding full well that the next webmaster will have to understand the need for choosing and applying an appropriate class if they change the images. Clear documentation of such requirements is the originator's responsibility. While borders can also aid in being a solution or an indicator they must be implemented in such a way that they work without changing the space taken up by the item, in other words they must remain consistent for browsers that use either the standard CSS box model or the original Microsoft box model.

Don't Be Afraid of White

In some circles there is a loud cry that the color white, especially as a background color, is too bright. Ignore the cry. If a white background is "too bright" it means the device operator that is complaining about the brightness has not properly adjusted the brightness and/or contrast of their device to meet their and their eyes' needs! Generally for websites/electronic documents you should assume that individuals will all be using their own devices and that they, or someone assisting them, can have properly set the device brightness and contrast for normal conditions. Occasionally it may need adjustment for working outdoors on a sunny day or in a darkened room but those are not document/page author/webmaster concerns. They very well might be concerns for an ATM kiosk maker but not for general electronic document creators. Black text on a white background is still great for reading but in bright sunlight even a book printed on dull newsprint paper can be impossible to read until it has been shaded from the direct sun.

Likewise don't fall prey to demands for "night reading modes" and similar issues for web sites and electronic documents. Let those modes be created by (preferably) the operating system developers where it has to be done only once. Or maybe by browser or reader software applications where again any user adjustments apply across all websites/documents. Imagine your website links to other websites (as it very likely does) and your user nicely visits your website in a darkened room and uses your on-the-page dimming control to get the brightness down to where they like it. Then they follow a link to a well designed black-on-white site and get blasted by the intense brightness. Should they have to find the new site's control and adjust it too? No. It is likewise impossible for you to win with light characters on a dark background because some eyes need the brightness of the light characters boosted for best reading while other eyes need the brightness dimmed to avoid halos. Adhere to universal design principles for your page/document out of the box, use the full spectrum of colors with care, and don't try to provide an experience perfect for everybody in every situation or controls for adjustment of your website/document alone.


It is essential that there is appropriate contrast between text and the background behind it. In general, light colored text should have a dark background and dark colored text should have a light background. This covers text in all documents including web pages, Word documents, PowerPoint presentations, and PDFs. WCAG 2.0 AA 1.4.3 specifies that (assumed 16px, 12pt) text must have a minimum color contrast ratio of 4.5:1. However, AA minimums are just that, minimums, not magic bullets. The AAA level standard is 7:1. Be considerate of users that need AAA minimums when choosing color combinations (think "inclusion"). And keep in mind that the AA minimums are barely tolerable as is demonstrated at the W3C color vision example page, for persons (2,500 on the MSU campus) with colorblindness.

When the text is large, 14pt (18.5px) and bold, or 18pt (24px) the allowed minimum contrast ratio is 3:1 at AA and 4.5:1 at AAA. (Click for more on fonts per se.) To get an idea of what these text sizes look like examine the below desktop image from a 96 dpi screen on a Windows computer in the Firefox browser. Appearance on the device you are viewing with will make a difference. The things to observe are that the default text size is indeed, 16px, that 16px and 12pt are the same size, that the Microsoft standard Times New Roman type shown in the image is a small format within its designated point size as compared against the more normal 12pt Ariel, and that 10pt Arial lower case letters are exactly the same height as lower case 12pt Times New Roman characters. There have been lawsuits over type size because, within the height of 12pt, font creators are free to make their characters whatever size they want (and still call it 12pt). For much more information on selecting fonts see the Generic Fonts Tutorial. The short answer is that the Arial font puts a normal size 12pt character in its 12pt space while the Times New Roman font puts only a 10pt character in the same 12pt vertical space. The WCAG standards were written based on 12pt characters in 12pt character spaces so be aware of that since the true 12pt characters are much more inclusive as the below image demonstrates. Or to say it the other way around, if you're going to use Times New Roman or any other small format font you should make its size larger than 12pt/16px in order to meet the intended goals of WCAG and MSU Inclusion. For Times New Roman that would be 120% but just setting that as a base size has its own issues as is described in the Generic Fonts Tutorial. As text size enlarges the distinctions between sizes become less critical.

Text size image demonstation as discussed in the text.

When text is over a background image or gradient or similar, effectively every point on the edge of every letter must meet at least the 4.5:1 or 3:1 minimum contrast criteria based on the font size. A single pixel wide boarder all the way around the letter can suffice on 96dpi screens but may be problematic on higher resolution screens with anti-aliasing (blending of colors to make edges appear visually smoother). Drop shadows that do not effectively appear on all edges are never acceptable for meeting the minimum contrast requirements when the character color vs. background itself does not. The minimum ratios assume fonts of normal stroke width and basic styling (e.g., serif/sans-serif) and allow the testing to be done with the nominal specified color of the font regardless of any anti-aliasing or, with anti-aliasing the text color can be taken in 2 pixels from the edge (but there is no guidance, other than nominal color, for the frequent case where a font has no pixel in 2 pixels from every edge). For any font the Digital Experience (DigitalX) team recommendation is that at least the AAA contrast level be met for nominal font color against the least contrasting background behind it and especially so on thin stroke or fancy fonts.

"The minimum contrast success criterion (1.4.3) applies to text in the page, including placeholder text and text that is shown when a pointer is hovering over an object or when an object has keyboard focus. If any of these are used in a page, the text needs to provide sufficient contrast." [from 1.4.3 Contrast (Minimum)] That statement applies to error, warning, and other type messages that may not be "page content" also; essentially it applies to any text shown that the user is expected to read regardless of when it is shown or how it is triggered. How to test contrast for mouseover highlights, boxes that disappear on loss of focus, etc. is covered below in the "Capturing Ephemeral Contrast" heading.

Adding Meaning via Color

It is also essential that color is itself not "the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element" per 1.4.1 Use of Color which is an A level requirement. Examples of other methods for text are underline (e.g., for links), added text (e.g., "Error:"), small images (e.g., a ? icon), font style (e.g., italics), and color contrast. When color contrast is used as the visually distinguishing technique the minimum contrast ratio allowed between regular text and the color distinguished text is 3:1 but in DigitalX we recommend at least 4.5:1 and the AAA 7:1 or beyond is even better as long as the color also meets the proper contrast ratio with the background color. While the WCAG 2.0 guidelines have no specific criterion for color contrast of non-text elements they do recommend "good contrast" and identify external standards with the expectation you will be meeting them. For such elements "good contrast" has generally been understood to mean at least 3:1 as is now explicitly specified in WCAG 2.1 1.4.11 (AA) Non-text Contrast.

Be aware that many font-families have a thinner stroke for italics which may further degrade with color anti-aliasing so look carefully at text distinguished by both font-style and color to be sure the distinction will be readily visible across devices in any text size your document uses. That potential issue usually goes away if the font size is 120% of a default true 12pt or more. Also, for websites in particular, it is not sufficient for underline, for example, as an additional distinction to only appear when the mouse pointer is hovered over say a link or the link is tabbed to, the distinguishing characteristics must be visible full time such that a user scanning down the page using the right scroll bar will see it (nor, generally, will a mobile user).

Also be aware that, while not outright forbidden, the use of an underline for any reason other than to identify a link is strongly frowned upon because of the prevalence of underlining for links. It is also poor for mouse hover or focus to cause a font change that changes the space taken up by the font because that will, in documents that allow text reflow, usually cause other content to move about on the page (which is generally disconcerting for all visual users, e.g., what happened?). Changing between fonts, especially uncommon fonts, is also not a good way to provide a distinction other than color because such changes assume that the device the user is on will have the font available and can render it distinctly from other fonts and that the user has not set their own font(s).

Adding Meaning Via Text Color Plus Examples

Turn in your final exam by Friday at 5:00 PM.

First, is there anything wrong with the immediately above line? No, it properly conveys the message.

Turn in your final exam by Friday at 5:00 PM.

Now is there anything wrong with the immediately above line? Yes, the red (#FF0000) of the "Friday at 5:00 PM" does not have sufficient contrast to differentiate it from the (white, #FFFFFF) background. Pure red (#FF000) on pure white (#FFFFFF) always fails the minimum AA contrast ratio for normal size text. It is irrelevant whether or not the red is sufficiently contrasted from the black text of the rest of the line (though it is).

Turn in your final exam by Friday at 5:00 PM.

The immediately above line fixes the contrast from the previous example line and now technically the contrast of the red (#ED0000) versus the white (#FFFFFF) or the black (#000000) both pass at 4.6:1 so we could stop here and be AA compliant. But if you were to look at the contrast of the red to the black in the red/black text shown in the Colour Contrast Analyser for either the "Text" boxes or the color blindness examples you would see that some users might have trouble.

Turn in your final exam by Friday at 5:00 PM.

The above line adds a strong tag in addition to an acceptable 4.5:1 or better red (#DD0000) to the "Friday at 5:00 PM" text so now we have something that is very clear. But all we've done with the red and strong is add emphasis, albeit via two routes (color and strong). No meaning has been added relative to either the color or strong.

Let's say there was a note at the beginning of the document that stated: "Red Strong text denotes deadlines that are non-negotiable (barring a documented emergency)."

Now are our red color and strong tag adequate? What if generally we know that screen reader users do not have style changes read to them? What if strong is used in other contexts also. What if bold is used in other contexts. What if bold is not how strong is conveyed by the users override style sheet. We can add one more thing, actual text, and clear up the meaning of the red strong unequivocally for everyone. Color is not the only indicator of meaning below, in fact, we've added 3 indicators of which only 1 is color and in the process we've made the meaning very clear and inclusive even when "strong" is not shown as bold or not read by a screen reader.

Turn in your final exam by Friday at 5:00 PM (non-negotiable).


Using forms in HTML, Word, PDFs, etc. is often appropriate (see the Generic Forms Tutorial) but for some types of documents, such as templates, other means of identifying text that the user is expected to replace when they convert the template into their own document are needed. Color is often the first choice but it generally will not work on its own because screen reader users will not be hearing about color changes since any screen reader capability to read the colors will be turned off by default. To solve this problem most universally, three things should be done similar to the above "Adding Meaning via Color."

In template documents, start with a table (because tables can be easily found and cleanly deleted) at the top with instructions that explain how the template text that is to be replaced is identified. The content of the table should include a cell row explaining how to delete the table just before the final save of the document the user is creating based on the template. Here is an example explanation of text to be replaced:

Text in $$green and bold and bookended by pairs of dollar signs$$ below in this document should be replaced by your specific information.

Merely showing the text in green would not be sufficient and, if the document otherwise includes meaningful bold text (such as for strong emphasis) then it may be good to add another indicator such as "$$green and bold and bookended by pairs of dollar signs and underlined$$" [intentionally not styled in this web tutorial] since, in this case, the underline in the template should not be confusable with a link and the underline will be replaced by the time the document is completed. In any event, the $$ in the above will be read (if default settings are kept) by a screen reader and it is easily searchable for all users creating their own document from the template. Any suggestions, even the above, should be carefully tested with screen readers and only ones that work should be used.


Logos, within themselves, are exempt from the color contrast standards. For MSU logos, the MSU branding standards also apply and when used properly substantially exceed the WCAG contrast standards. However, be careful when using MSU logos, or any images, with transparent areas. To see why look at the below image or visit the MSU Brand Logos and Marks page then set your computer's high contrast to a dark one. (In Windows 10 type "high contrast" into the "Type here to search" box in the taskbar, click the high contrast settings option, and Apply the "High Contrast Black" from the "Choose a theme" dropdown. Scroll the page and look at the logos all of which, as is, have transparent backgrounds.) In Microsoft browsers earlier than Edge, CSS backgrounds will be ignored and the transparent part of the logo will show through a black background making the dark MSU green almost invisible (see below image).

Firefox currently sometimes does and sometimes does not ignore CSS background while Chrome essentially ignores the Windows 10 operating system accessibility settings. Modern Apple computers have a similar contrast setting (System Preferences > Accessibility > Display > Invert Colors) but instead of the logos essentially disappearing, the MSU green is turned to pink and/or the CSS backgrounds, or images, you apply are properly handled. The only fix for best consistency across browsers is to modify the logo with an appropriate color (typically white) in place of the transparency. You may also need a white CSS border for best appearance. Logos of other organizations, e.g., Facebook, Twitter, may also be subject to use or license agreements established by or with their owners.

Image with black background and white text where MSU dark green logos with transparency for everything not MSU green barely is visible when black shows through the transparency.

Checking Color Contrast

In the next few paragraphs this tutorial will briefly cover how to check color contrast using the Colour Contrast Analyser and the D2L color contrast checker but there are many other tools available. You will also find that when using the MSU Evaluation Protocol for WCAG 2.0 AA you are asked to subjectively evaluate visibility without the use of a tool. One caution, many color contrast testers that test a whole page only test the immediately visible page content and ignore error messages, hover changes, placeholders, etc., which also are required to meet the minimum contrast ratios.

Installing the Colour Contrast Analyser (CCA)

The Colour Contrast Analyser is a free tool made available by the Paciello Group and is used to assess the contrast of text against its background or any other contrast level between two colors. There are several versions available and we currently recommend the older versions because they more easily allow pixel specific selection which is essential when validating the contrast of fonts against a background.

The instructions on using the tool further below are for the older version. The instructions immediately below for getting the older version are current as of this writing but subject to change so if you find they no longer work, please contact us at immediately.

To install the older Windows version visit and download and run CCA2.5.0.exe. (You may have to remove any extension, such as .htm, that might be placed after the downloaded file name and you may have to show "More info" and click "Run anyway" and/or other prompts to complete the installation.) For Apple computers go to and download and install the version.

If you wish to try the most current version of the Colour Contrast Analyser, it will be available via The Paciello Group website for both PC and Mac operating systems. As of this writing installations of the older version and the newer version can both be installed simultaneously without conflict. The Paciello Group link will take you to a Github website where, for Apple computers CCA-1.0.0-mac.dmg is the correct file while for Windows computers, CCA-Setup-1.0.0.exe is the correct file to download and run for installation. Be aware that the 1.0.0 number in the middle of the file name will change as updates are made. The task bar icons for old and new CCA will be the same so you may want to be sure the newer one is second in line. If you use the new version you probably need to keep your version current because improvements will likely be ongoing particularly in regard to handling of operating system features such as multiple screens. The images shown below are from the recommended older version but the use process should still be essentially correct for any newer version. If the use instructions are no longer correct, please contact us at

Using the Colour Contrast Analyser

To examine the color contrast of a page or site, begin by opening the Colour Contrast Analyser. The Windows version is shown first followed by the Apple version.

Screenshot of the Colour Contrast Analyser dialog box. There are sections for examining the Foreground and the Background of a document. These sections allow the input of hex codes and have eyedropper tools for selecting color examples. The bottom of the box states whether or not sample text meets AA or AAA contrast standards against the sample background.

Screenshot of the Colour Contrast Analyser dialog box. There are sections for examining the Foreground and the Background of a document. These sections allow the input of hex codes and have tools for selecting color examples. The bottom of the box states whether or not sample text meets AA or AAA contrast standards against the sample background.

In the Windows version, click the Eyedropper Icon under the "Foreground" section and on an Apple click the color picker rectangle to the far right of the words "Foreground Colour" near the top then at the bottom of the color picker click the Eyedropper Icon. The eyedropper tool allows you to use the mouse to select individual pixels of text, background, whatever. For text you should choose a sample pixel that best represents the text's color (usually somewhere in a vertical or horizontal line).

Alternatively, if you know the hex value of the color of the text, you can enter it into the Hex dialog box but be careful, the tool often reports a contrast ratio even for invalid hex numbers rather than identifying the invalid entry as an error.

In the following example, the brown hyperlink text of is examined. Note that the straight hyperlink underline is used for examination. The pixel selected is identified by the little box below the main downstroke in the "d".

Screenshot of the Color Contrast Analyzer's eyedropper tool being used to examine the underlined portion of a hyperlink on the WebAccess site.

Then find and use the Eyedropper Icon for the Background section. Select an area of the background close to the sample text. Like with text color, if you know the hex value of a uniform background, you can also enter it into the Hex dialog box but if the background is an image or gradient you will need to pick a pixel. When examining the contrast of text against backgrounds that are not a single color (such as gradient backgrounds or image backgrounds), use, as is shown below, a background sample that is closest to the color of the text but not an anti-aliased part of the text (e.g., when checking light text, use the lightest color in the background immediately adjacent the text).

Screenshot of the Color Contrast Analyzer's eyedropper tool being used to examine the background of the WebAccess site.

Results will be shown in the Colour Contrast Analyser. MSU’s technical guidelines only require AA conformance. AAA conformance is not required but is recommended (think "inclusion"). The first example above ("edu") shows the foreground/background pair pass for everything except AAA on normal font size text while the second ("the") shows that the pair fail for all font sizes.

Capturing Ephemeral Contrast

To handle flyout or dropdown menus and such other things that normally vanish (a major but common OS/application accessibility failure) when the CCA tool (or any other) window gets the focus, use your desktop computer's screen, window, or selection capture tool to grab at least what you will need to do the contrast analysis. On a Windows computer tapping the "Print Screen" (or PrtScrn or similar) will capture the current screen with any flyouts, etc., intact and you'll then need to paste that into a bitmap graphics program such as the Windows Accessories Paint program. On an Apple computer using Shift+Command+4 then selecting the area you want will automatically save the image to the desktop where clicking on it will open it in a preview window. Once your captured content is being viewed in its own window you can use the CCA eyedropper on that captured image.

D2L Contrast checker

To check your contrast for HTML web page content internal to D2L, launch the D2L HTML editor. You cannot readily check contrast for document types other than web pages in D2L with the D2L contrast checker. One route to the D2L web page contrast checker is from the profile button dropdown where you can select "Viewing as Course Editor" then More > Course Admin > Site Resources > Content. If Course Admin is visible without or in addition to the "More" option simply start from "Course Admin". Then navigate to a module and page that is a "Web Page" then click the "Edit HTML" button. Click in the text you want to check the contrast for to set the position of the edit cursor.

  1. Click the down pointing ("Select Color") triangle to the right of the ("Apply Color") box as shown below. If the "Select Color" dropdown down pointing triangle beside the color square as shown below is not visible on the toolbar click the Show All Components ("..." symbol) first to make it visible. Screenshot of the Edit HTML File screen in D2L, with the 'Select Color' drop-down selected.
  2. Check in the "Preview" area (see below image) to be sure the background and foreground colors are what you intend to check (usually the background sets correctly based on where you clicked the cursor in the edit box but sometimes you will need to select the foreground). (The Select a Color popup may be arranged horizontally, as below, or vertically depending on your window width.)
  3. A green check mark below the "Preview" box indicates a contrast ratio that meets the accessible contrast ratio for small text regardless of what size text the edit cursor is in. A white X in a red disk indicates failure for contrast in small text. If your text meets the requirements for large text then you merely need to note if the "Contrast Ratio" number is above 3:1.
  4. If you want to check the color contrast of other material you will need to know the 6-digit hex color number of a color in order to enter it in this opened tool on an HTML page. You must enter the full 6-digit Hex Value in the provided box (3-digit hex numbers are not allowed, e.g., 656 must be entered as 665566). Usually for non-HTML pages using the Colour Contrast Analyser tool as described above is easier.

Screenshot of the D2L 'Select a Color' screen highlighting the WCAG 2.0 popup.

Color in Graphics, Charts, etc.

When using color in a chart, to ensure all users, and particularly colorblind viewers, can access and understand your graphics, a few basic guidelines should be adhered to:

  • First use an appropriate chart type, E.g. occurrences of things over time probably should be a line chart while comparisons at a single point in time might be better as a bar graph and percents as a pie chart.
  • Avoid using the colors red, green, and orange together or in combinations on a graphic and avoid red on black or black on red.
  • Use hatching (sometimes called textures) instead of or, with proper contrast, in addition to colors in graphs and charts.
  • Draw attention to important information in graphics by circling it rather than changing its color.
  • Use high contrast colors.
  • If you can, label lines and pie slices directly, otherwise have a clear key or lines that show what labels belong to what or obey the next bullet.
  • Be sure chart keys and labeling follow proper conventions (left-to-right/top-to-bottom, clockwise).
  • Be sure chart keys (and individual symbols) are large enough to be clearly distinguished on high-density screens.
  • For line data points use distinct marks such as triangles, squares, discs on each line or use distinct line styles, dashes, dots, combinations.
  • Be sure non-color identifiers, such as the order in which the key items appear match with their use in the chart and thereby effectively completely duplicate the color identification.
  • Include the data in an accessible table below the chart when that is needed for fullest inclusion.
  • Be sure the content text or alt attributes/text convey the content the image is intended to convey.
  • Additionally provide clues in the text that make any colors redundant, e.g., the "Product 2" (top) line, the "Week 1: Product 1" (left) bar.

A generally good way to think of this is, If I printed this on a grayscale black and white printer, could a sighted user correctly understand the graphic? Could it also be understood without any description in the text? Unfortunately no charting program is known that gets accessibility correct without considerable creator effort. The most consistent failures are text that is too small, keys that are too small, and colors with inadequate contrast.

The best way to understand the red/green/orange bullet in the above list is to use the Colour Contrast Analyser, set the colors to the ones you want to compare, and check the "Show contrast result for color blindness" checkbox. In general you shouldn't be able to use those colors (or any hue in their relative spectrums) in pairs and get a 3:1 contrast ratio anyway. Stay aware that in charts and graphs particularly, contrast distinctions still should exceed 3:1 even when the two colors are not side by side and there is no other distinction, such as lines that show what labels belong to what sections of, for example, a pie chart. High contrast lines between pie slices, or a pulled apart pie can help separate colors. Different line weights and dashing and point marks can also help.

Below you will find several images of graphics. Text around these graphics will discuss the accessibility issues for all user disabilities, not just blindness.

Incorrect Contrast Pie Chart Example:

Pie chart where adjacent colors have insufficient contrast.

The contrast in the above pie chart fails on all but two adjacent colors and the fact that the key is in order starting from 12:00 o'clock and proceeding clockwise does not overcome that. Text sizes in this chart have been corrected from too small as output from the original program. Note that the default title and key text as output by the default chart settings exactly hit the 7:1 AAA contrast ratio. If the first slice does not start from a 12:00 o'clock radius you need to be certain that keys or labels can be correctly associated with their respective slices and that is usually more easily done with hatching or screening.

Pie Contrast Improved with Borders

Pie chart with white border separators between slices.

While the borders added to the slices above help there are still contrast issues. In fact no single border color will work with sufficient contrast between the border and all slices. You may also note that adding the border caused the key color boxes to shrink dramatically because the white border was added to them too.

Exploding the Pie, adding Percent Data

Pie chart exploded and with data added.

In the above version the pie slices have been separated by explosion and while some meet the minimum 3:1 contrast ratio with the white explosion separation some do not. Also note that the applicable pie slice portions as a percentage have been added in white text over a black background because there is no single text color that would otherwise work with the required contrast ratio when the percentages are applied directly over their respective slice. Note that in the above example the chart title and the key text color was changed to a full 21:1 so they stand out to the maximum extent for all users.

Labeled Pie Slices

Pie chart with slices labeled with slice label and data value.

In the above version of the Pie Chart all slices are individually labeled and the text is larger and bolder and with higher contrast than the minimum AAA requirements. This chart works on a desktop computer, on a phone, and readily enlarges 200% or more. Additionally the colors of the individual slices have been at least somewhat matched with user associations to the pie type they represent and slices that have too low of contrast with the white background have been given black borders. Unfortunately the leader lines that definitively tie each slice label to its slice are too low in contrast.

Pie Chart Final

Text of labeles upped to 14pt bold and leader lines drawn with proper contrast.

This final version of the chart fixes the contrast issue with the leader lines and additionally makes the text "large" by using 14pt bold type. Could it be improved? Certainly, a drawing tool that anti-aliased the leader lines might make the image better as would more separation between the smaller slices. But is it going to work for all users? Certainly, and more so if this were a real chart with real data and had an alt text of "Pie Chart (about pies), Apple 35%, Cherry 25%, Pumpkin 20%, Chocolate 8%, Key-lime 6%, Mincemeat 3%, Other 3%." (Shouldn't Pecan and Coconut Cream be in there prominently somewhere?)

Region Chart Showing Non-contiguous Hatching Areas

Map showing non-contiguous areas of identical hatching.

A map such as the above is a better example where "convention" such as starting from 12:00 o'clock and going clockwise doesn't work so well and where order is not so obvious and there is a color or hatching key off to the side because lines from categories to single areas won't work. (Adapted from Note here also that in this case the hatching all goes in the same direction thus avoiding irrelevant busyness or perhaps a jangling feeling. The touch of color has insufficient contrast compared to white but the hatching completely removes any ambiguity so the colors can stay as they are.

Basic Bar Chart

Graph that is properly labeled due to the order of the key being the same as the order of the bar pairs.

Bar charts similar to this can be found all over the internet that purport to show that the colors of the two columns fail to properly meet the color contrast requirements. While it is true that the difference between the two colors chosen for the products, medium blue and dull yellow, do not have at least a 3:1 contrast ratio it is equally true that the colors in this chart are not needed to understand the chart. The fact that the left bar is also the leftmost item in the key is sufficient for ensuring that something other than color distinguishes the bars in each pair. The same would also hold if the key were in the upper right with "Product 1" above "Product 2." You should note however, that without the black boarders around the bars they would not pass the color contrast requirements relative to the background white.

If you do find yourself with a chart where the labeling/key is not properly labeled by order you should correct the order (by cut and paste if necessary if you cannot set it in the graphing program). Likewise a pie chart where the first slice of pie starts with a radius from 12:00, top-dead-center and proceeds around clockwise to the right while the key is left-to-right or top-to-bottom is perfectly understandable as long as the color differences between adjacent slices have sufficient contrast, are separated by a line of sufficient contrast, are pulled apart so they are distinct, or are properly distinguished by hatching or screening.

The reality is that the above chart has much more significant problems than color contrast. The text type size is not a minimum of 16pt except for the main title which exactly hits it and even then it has anti-aliasing issues. While all text in the chart probably met the 16pt size when the chart was created, the chart's reduction to the size here presented as a web image does not. There is also the issue of it being a time series which might be better shown as a line chart (more fully discussed later). Additionally the default 0 line has insufficient contrast and the product keys are too small to work on a phone.

Fixed Bar Chart Gilded with Hatching

Bar chart with text sizes fixed and hatching added to color key.

The above reworked bar chart does add hatching to one bar and will reduce the odds of misunderstanding but you should also be aware that hatching, when poorly done such as too bold and too close together of lines or wild variations in slope can result in moire effects that cause the lines to appear to move, take on colors of their own, or generally get lost in confusion, so some people recommend only using various dot screening densities or gray (or other color) shades but they too have their own issues with screen pixel density sizes, anti-aliasing, and screen color limitations. The need for color distinctions to have at least a minimum contrast ratio of 3 between them poses a limit on number of colors/shades that can be used while hatching and screens have a lot more flexibility. There are no simple perfect answers, imagine a 100% scale where the bulk of the results (or just the critical results) are in the 1-2% range but where other items are over 70% necessitating the full 100% range be shown. Often the choice of graph/chart/table type for showing the data is critical and careful selection of what to include and what to omit is worth the effort rather than using a poor choice and trying to force some (appropriate or inappropriate) means of differentiation to work.

Even the hatching shown above could probably be improved for better visibility on phones and certainly the sized of the key boxes would be still better enlarged further, but, as previously noted, this chart works just fine without the hatching. Though it may not be the best chart type for the data.

Other improvements to the previous version are that the previous text sizes of all parts have been enlarged to be at least 14pt bold. The added exact values of the chart bar heights have been added at the minimum recommended 12pt size. If the exact numbers are not important then it is not necessary to have them but the catch is that if you are going to include them in the alt text and won't also have them in a table associated with the chart you may be giving screen reader users more information than you are giving other users.

The below chart takes the same data as the above bar charts and makes it into a line chart which is generally much more appropriate for showing something where the horizontal axis represents some type of time series.

Line Chart for Time Series

Line chart for the same data as the above bar chart better showing the time series.

While the above chart is not as "full" looking as the bar chart is it is easier to follow the differences between the two products in their changes over time. Where this chart falls down is that the default order (due to the order in the data) of the two lines versus the key order is not conventional. It is, even again in spite of the inadequate-for-differentiation contrast of the two colors, possible to distinguish between the two lines due to the circles and triangles on the data points of the line. So as it stands this (with a proper alt text) will meet the WCAG 2.0 AA criteria. But the below version is even better. You may also observe that removed are both the redundant "Number of Sales" from the title and the vertical axis in this and the below line charts that originally appeared in the above bar charts. It might be arguable that removing that text could pose an understanding difficulty for a cognitively disabled user but on the other hand the clutter of the extra words might just as easily decrease ready grasp of the chart.

Line Chart Key Order Corrected

Line chart with the key on the right better showing the relationship of labels to lines.

This version of the line chart makes sure that the lines are clearly identified by putting the appropriate key to the right of each of the product lines. While the 2 then 1 order of the product names seems odd it is only due to their arbitrary choice, if the products were "red bricks" and "yellow bricks" there would be no apparent unorderedness. Also done is that the original 14pt key labels and week labels have been upgraded to bold and the data point symbols have been changed to hollow symbols with the actual data value in each. These latter have a text size of 12pt. If the data point numbers were made any larger there would be overlap issues. Try out the two charts above on your phone and see which type, the unbolded vs bolded (for the product labels and the weeks) appears like it will work best for the most users.