Accessibility & Design Tools: Introducing UXPin’s Contrast Analyzer & Color Blindness Simulator

It is a duty of designers to make digital spaces accessible for all people.

No one should feel excluded from digital experiences by means of their visual, motor, auditory, speech or cognitive disabilities. Taking care of accessibility is an ethical imperative for designers.

And yet, until now, design tools have completely failed to deliver sufficient ways to help create accessible experiences.

Shockingly, no design tool has invested into the creation of dedicated accessibility features. Researching the subject, I found just two barely working plugins for two of the vector design tools. Their creators had the right intentions and I commend them for the effort. Unfortunately, plugins frequently exist in unstable environments and break thanks to their platform’s updates. The problems of accessibility are way too serious to hang them on third party plugins developed by good-hearted folks. It’s the job of design tool makers to provide the right features.

Dear designer: Allow me to speak for the design tool market for a second — we’ve failed you and I apologize. It’s time to right at least some of these wrongs.

Therefore, our team recently took on the challenge to introduce the first high quality, built-in accessibility features in a design tool. We’ve started with two: a Contrast Analyzer and Color Blindness Simulator!

Contrast Analyzer

According to WHO, over 1.3 billion people live with some form of vision impairment (217 million with moderate to severe vision impairment!).

If your vision is perfect, it’s hard to imagine how others can perceive your creation. Something that may be perfectly visible and sharp for you may be completely unreadable for another person. The stronger the impairment, the more a person will rely on the size and contrast of the elements of the user interface.

To help designers understand the right level of contrast for a given size of text, W3C Accessibility initiative, in their Web Accessibility Guidelines, specified the standards for contrast ratio between text and the background.

And now in UXPin, the WCAG contrast standard is now used in our built-in, automatic linter! In our design editor you can specify whether you want to comply with AA and AAA standards. It’ll automatically inform you whenever the contrast is insufficient. Right there inside your design tool without clicking around, looking for plugins and external tools. The contrast checker will be always with you helping you design inclusive experiences for all!

Color Blindness Simulator

Did you know that 4.5% of the world’s population has one of the types of color blindness (8% of the male population)? This huge number is too often overlooked by designers.

Embarrassingly, I’m as guilty as the next designer; I have definitely designed interfaces in my career without testing them with color blindness simulators. Now, I’m very excited that UXPin will show you your design as perceived by a person with one of eight types of color blindness during your design process! No more referring to external tools and jumping between programs. You can analyze your design thoroughly and make the right design decisions.

This is how the header image of this blogpost would be seen by people affected by deutranopia

UXPin can simulate:

Four kinds of red–green color blindness (caused by limited function, or lack of red or green cone photopigments):

  • Protanomaly: 0.66% of the population. People with protanomaly have an abnormal red cone photopigment. It makes red, orange and yellow appear greener and all other colors appear less bright.
  • Protanopia: 0.59% of the population. Those with protanopia have no working red cone cells. Red appears black. Certain shades of orange, yellow and green all appear yellow.
  • Deuteranomaly: 2.7% of the population. This causes an abnormal green cone photopigment. Yellow and green appear redder, and it is difficult to tell violet from blue.
  • Deuteranopia: 0.56% of the population. People with deuteranopia have no working green cone cells. They tend to see reds as brownish-yellow and greens as beige.

Two kinds of blue–yellow color blindness (caused by limited function, or lack of blue cone photopigments):

  • Tritanomaly: 0.59% of the population. Those affected by tritanomaly have functionally limited blue cone cells. Blue appears greener and it can be difficult to tell yellow and red from pink.
  • Tritanopia: 0.016% of the population. This causes a lack of blue cone cells. Blue appears green and yellow appears violet or light grey.

Two kinds of complete color blindness:

  • Achromatomaly (Cone Monochromacy): In this type, two of the three cone cell photopigments don’t work. People with cone monochromacy cannot distinguishing colors because the brain has to compare signals from different types of cones to see color. When only one type of cone works, this comparison isn’t available.
  • Achromatopsia: <0.0001% of the population. This severe type of monochromacy causes none of the cone cells to have functional photopigments. Lacking all cone vision, people with this type of color blindness experience the world in black, white and gray.

Hopefully, with the color blindness simulator at our fingertips in UXPin, we’ll all always make sure that people affected by color blindness can use and enjoy our digital creations.

Two paradigms of design tools and accessibility

You’re likely aware that the market of design tools is split into two parts:

– Image–based tools that render and output raster and/or vector graphics (Sketch, Figma, XD, Studio…)

Code–based tools that engage browser rendering engine and web technologies to render designers’ intent in code without asking for coding expertise (UXPin, Modulz, Framer X)

The big advantage of code–based tools, apart from unmatched prototyping capabilities (real experiences instead of hotspot presentations!) is the realistic rendering. Render of colors and text in a code–based design tool and the browser is identical. Unfortunately, that cannot be said about the vector tools that keep designers in the realm of images and separate the process from the reality of code.

With that in mind, it’s obvious that accessibility checks should be performed on the level of code and now, with UXPin, the designer can do it before actually coding the entire product.

In order to create inclusive digital experiences, designers have to make accessible design decisions early enough. I’m beyond happy that we’re the first to deliver this capability right inside the heart of a design tool.

We’ve started with the contrast checker and color blindness simulator, but we’re looking forward to expanding our accessibility suite of features in the future. If you have ideas of how we can improve the world of design tools — let us know. We’re all ears.

Together, we can create anew world of design tools that helps designers create accessible digital experiences, and not only draw vector images of interfaces!