XXI.3 May-June 2014
Page: 56
Digital Citation

Integrating color usability components into design tools

Montgomery Webster

back to top 

The academic community has produced extensive documentation of usability and accessibility principles. Much of this work has been wholeheartedly adopted on an international scale, for example, by the International Organization for Standardization (ISO) [1], and is required by law in some countries [2]. Nevertheless, one branch of usability continues to present implementation challenges: color contrast. One of the most important usability tasks is ensuring sufficient contrast between text and its background color. However, color contrast tools are extremely slow or not available when designers are making color decisions. I propose incorporating color contrast evaluation into design tools.


A number of obstacles still prevent large-scale color usability integration. Generally, no methodologies have been proposed to implement color contrast usability guidelines and heuristics. Instead, most of the work has been evaluative, resulting in complex and lengthy standards. Thus, producers are expected to simply comply with the standards. The process is time consuming, as each standard has to be checked individually for each product or section created. Additionally, standards might require complex mathematical computations to evaluate. The standard for color contrast text legibility [3] is a 4.5:1 ratio between the relative luminance of foreground text and background color. There is no easy or fast way to compute that value. Clearly, a tool is required to simplify the task.

back to top  Insights


Tools that evaluate usability compliance come in two forms, Web-based HTML reviewers and color selector tools. HTML reviewers (see [4] for a comprehensive list) look at a Web page and compare each element's text color with its background color. Reviewers usually output a list of all color pairs that fail either brightness or color contrast levels. While these tools certainly are a great step forward for usability, requiring HTML input limits their utility. Designers traditionally do not create their assets in HTML; more commonly they create image-based designs before sending them off to a developer. As such, these tools cannot give feedback when color decisions are being made. Countless assets might have been made with an unusable color theme before finally being evaluated.

As a result, designers and developers typically use color selector tools when they are making color decisions. This is often done while using a color scheme tool to select appropriate color relationships. Color contrast selectors require both foreground and background input from pixel color selectors or as HEX color values. The contrast values are then given for that single color pair. To do so for every unique foreground-background pair in a design is a significant amount of work, especially when changes are made. Though these sets of tools can be applied during various stages in product development, none are integrated into the design environment or into color scheme tools. Consequently, all feedback is static and presented out of context. The design process must necessarily be stopped to evaluate the current compositions, breaking the creative flow or presence. It's not a very impressive solution for modern computing, suggesting that usability is still not a priority.

back to top  A Paradigm Shift

In 1990, Flavio de Souza and Nigel Blevin suggested that designers often do not have the usability experience necessary to adhere to ISO's extensive guidelines [5]. This is unlikely to be true today. What is clear is the tools that might have served to satisfy a few usability professionals back then are no longer acceptable more than 20 years later. An updated solution is necessary. Here is what I propose: Incorporate quantitative usability feedback into places where design decisions are made. Immediate feedback allows designers to make rapid adjustments as choices are made, preventing mode-change errors that can occur from using external tools.

Moving the responsibility for usability evaluation to the design tool marks a significant paradigm shift. Before, designers presented their work (comps) to a user experience designer or quality assurance tester for usability evaluation. With this new approach, designers have immediate access to the data by which they are judged, empowering their positions. They can utilize or ignore the feedback as they choose, but are able to defend their color decisions with quantitative data.

The idea of providing additional usability and referential data where color decisions are made is certainly not new. Design tools have long included lists of Web-safe colors so users did not have to look for the information elsewhere. As another example, traditional color scheme tools, such as Color Scheme Designer [6], often include color-blindness filters (Figure 1). This feature shows what a design or color palette would look like for someone with a color deficiency. Showing the difficulties these people face certainly goes a long way toward making usable and accessible color decisions. However, these tools do not include quantitative feedback. As a result, designers cannot know if their color decisions comply with usability guidelines using these tools alone. The responsibility still rests with the designer and whether they judge that the text contrast is sufficient for these audiences. Simply including quantitative data revealing if the color combinations pass accepted standards would assure that color decisions are made with all the information needed.

back to top  Applications and Integration

Clearly, more information should be given to designers. However, integrating quantitative feedback into design applications is not straightforward. To start, which users specifically are considered "designers"? Similarly, are some tools appropriate for text contrast feedback, while others are not? Another challenge is determining how to display this additional feedback.

Separating users from design tools can be difficult. As technology progresses, more and more applications that previously required technical information to operate now have simplified versions for everyday users. Photo editing is one field that has seen such a change. Apps such as Instagram give users automated photo filters, which can completely change a picture's style. The larger implication of such interfaces is that everyone can be a designer. Thus, the audience for design tools and applications is quite broad. In addition to these tools, design options are presented to users in a variety of other contexts. Color choices are often made using design applications, but they may not be. Adobe Kuler [7], for example, exists both as a standalone Web and mobile application with a large user community and also integrates into various Adobe Creative Suite products (Figure 2). On the other hand, many color websites are limited to designing themes, choosing color schemes, and sharing these elements, thus requiring them to be used in conjunction with other design tools.

Generally, no methodologies have been proposed to implement color contrast usability guidelines and heuristics. Instead, most of the work has been evaluative, resulting in complex and lengthy standards.

While not everyone will use Powerpoint to create a presentation, most users will use email, a Web browser, and an operating system, all of which have theme personalization options. Even clothing and shoes offer product customizations. Of course, if a customizable interface offers only predefined options, a designer can make all of them usable. However, most of these interfaces allow the user to work unhindered and uninformed, limited only by the capabilities of the product. As a result, both professional and casual designers may create illegible text in applications they regularly use. The efficiency problems created by these usability errors will often remain uncorrected.

Clearly, many users are making design decisions while using a variety of software products. Does every tool that allows text and background color selection need quantitative feedback? That depends largely on the audience for the design being created. For example, personalization interfaces mainly affect only the user making the color decisions. As the designer, they are certainly allowed to make unusable themes, mainly because they will not be used by anyone else. Maybe quantitative feedback is not required. In these cases, however, a company providing a service such as Gmail may not want, for example, their users to have trouble reading their emails. As a result, the creators of these interfaces have a few choices: to give the user additional data to make informed color decisions (my proposal); to provide premade, usable themes; to allow some configuration, while limiting options that would result in poor legibility; or to provide no personalization at all. Though the last option may sound absurd, some companies do not want to invest in the additional work. Apple, for example, has chosen to limit the personalization options on the majority of its products.

If more than a few people will use a design, then quantitative feedback should be included. How easy is it to include text readability data? Simple. Design tools regularly have a large set of properties displayed for each element in the design. Including additional elements, such as luminance contrast values, with these properties or in other views, tabs, and toolbars would be straightforward. On the other hand, color schemers and customization interfaces usually do not have element property sections. They often do include additional information in tabs, so usability data could certainly go there. If a simpler layout is implemented, they differ from designs in an important way: The textual content on these pages is usually not important. For example, color interfaces present large blocks of the colors themselves, both graphical and text versions. Similarly, themers often have dummy or Greek text instead of content, used to show how the theme would look in context. Both of these user interfaces have sufficient room to include numerical usability data.

back to top  Proof-of-Concept and Limitations

To demonstrate adding dynamic quantitative feedback in color selection interfaces, I created a proof-of-concept [8]. The prototype, shown in Figure 3, has some typical Web page text scenarios with two interactive components: A color selector has been added in the first column, and the contrast value, normalized from 0 to 99, has been added to most text elements (e.g., "c.27"). The user interacts with their work by clicking the element they want to color, including background areas (DIVs), which updates the feedback section of the interface, labeled "Contrast." The user can then use the color tables to alter the color and view the resulting WCAG 2.0 luminance contrast grades. Though the prototype does not allow the user to change color schemes as a whole, giving dynamic, quantitative, color contrast feedback is significantly faster than either the HTML reviewers or color pickers that designers currently use.

Providing users with dynamic color contrast feedback during the design process has the potential to make a significant impact.

Luminance contrast can easily be evaluated on foreground-background combinations even if the background is fully transparent. However, modern websites and user interfaces commonly have much more complex use cases. For example, a single text block can appear above images, gradients, and partial opacities, all of which have multiple background colors that vary drastically between pixels. Recently a solution was proposed to address partial opacities [9]. However, I have not come across any other methods to compute the contrast for these everyday design styles. There may, though, be ways to approximate the background color. For example, two-color gradients can simply divide their background into two parts, one for each color, and then compute the contrast. Images, alternatively, can be approximated by a user-selected color. More robust solutions might take too much processing power to feasibly include in an application. Clearly, more research needs to be done to create standards for common design tasks.

These shortcomings present a significant hindrance to the design-tool contrast-feedback proposal. Few manufacturers are willing to invest in a technique that does not function in a majority of cases. Nevertheless, while complex background color tasks are present in most design tools, they are not applicable in color scheme tools. Color scheme tools do not include images, opacities, or gradients. Clearly, these tools can include dynamic contrast data. If these color design tools are used frequently enough, including the contrast feedback here could assure that designers have the information they need to determine if their color combinations are usable. The creative director at my company estimated that 20 percent of projects will use a color scheme tool. However, once the designer moves to their main design tool, which does not include contrast feedback, no usability standards can be evaluated.

back to top  Conclusion

Providing users with dynamic color contrast feedback during the design process has the potential to make a significant impact. Designers use applications to create products that fill the world around us. Thus, changes to these tools will generally improve the readability of text in everyday life, even in non-digital spaces. For users who are unaware of usability guidelines, the responsive new feedback properties will teach them about accessible color decisions. Advanced users and design professionals can defend their color decisions with real data. The prototype I introduced shows the interactions and interface that could support this quantitative data. However, significant limitations prevent usability data from gaining wider adoption. Nevertheless, the color scheme tools often employed by designers in addition to their main project tool can easily integrate text color evaluation into their interfaces. Let's work on that now, while more contrast evaluation standards are developed for complex design cases.

back to top  References

1. International Standards Organization (ISO); http://www.iso.org

2. EU Web Accessibility Policy; http://ec.europa.eu/ipg/standards/accessibility/

3. W3C WCAG 2.0; http://www.w3.org/TR/WCAG/

4. Greeff, M. and Kotzé, P. A lightweight methodology to improve web accessibility. Proc. of SAICSIT '09. ACM, New York, 30–39.

5. de Souza, F. and Bevan, N. The use of guidelines in menu interface design: Evaluation of a draft standard. Proc. of Interact '90. North-Holland Publishing Co., Amsterdam, The Netherlands, 1990, 435–440.

6. Color Scheme Designer; http://colorSchemeDesigner.com

7. Adobe Kuler; http://kuler.adobe.com

8. Dynamic color contrast feedback prototype; http://uxmonty.com/usability-tools/

9. Lea Verou's contrast ratio tool; http://leaverou.github.io/contrast-ratio/#

back to top  Author

Montgomery Webster works as a junior user experience architect at a digital marketing agency in southeast England. He innovates digital experiences and simplifies everyday user tasks, from e-learning to crowdsourcing. His research interest is interaction design, focusing on universal customization, simulators, and futurology.

back to top  Figures

F1Figure 1. Color Scheme Designer's color-blindness filters.

F2Figure 2. The Adobe Kuler app parses colors from a user-defined image.

F3Figure 3. Prototype shows "Instructions" h2 tag fails Level AAA color contrast validation.

back to top 

Copyright Held by Author. Publication Rights Licensed to ACM.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2014 ACM, Inc.

Post Comment

No Comments Found