Website Archives - Page 7 of 12

YNAB addresses color accessibility

Rachele DiTullio28 May 20197 February 2021Desktop, Websiteaccessibility

In a recent product update YNAB (You Need a Budget) announced it had made some change to the way it uses color to convey meaning about budget amounts. When I logged into the online webapp today, I saw this modal message dialog. (The content of the announcement is below the image.)

screen shot of a modal announcement dialog in the YNAB web application

Sarah from YNAB

Hi there,

As you probably know by now, we really care about your experience in YNAB. Like…really really care. We are always looking for ways to make things easier, more user-friendly, and just prettier.

We’ve heard that the colors in your category Available balances (or “pills” as we like to call them) make things a bit difficult to read. When we hear feedback like this, we gotta do something about it. We want YNAB to be accessible to everyone, so we’d like to introduce our new pill colors:

screen shot showing the before and after colors used by YNAB to show budget category information. the before colors are orange, green and red with white text. the after colors are lighter shades of the same colors but with text now a darker shade of each, which has better contrast.

In case you’re wondering, green still means green. Yellow still means yellow. Red still means – you guessed it – red! The only thing that’s changing is the increased contrast, which makes things a bit easier on the eyes.

The message links off to a blog post that discusses the changes further: A Budget That’s Easy On The Eyes

YNAB took note of two accessibility issues

Previously, it used color only to convey the meaning of a budget amount which does not meet success criteria 1.4.1 (level A) Use of Color.

“We added visual signals to the Available amounts to make it clear whether there was credit overspending or an underfunded goal. We also increased the size of the negative sign for overspent categories. Both of these changes help users with visual impairments easily scan their budget by relying less on a color-based signal.”
The color combinations of white text on an orange background (2.54) and white text on a green background (3.31) failed the color contrast requirement of 4.5:1 for success criteria 1.4.3 (level AA) Contrast (minimum).

“We significantly increased the contrast between the color of the background (the ‘pill’) and the text, while muting the background color. These changes increase the contrast in general, which makes the text easier to read for everyone.”

The new color combinations do indeed satisfy color contrast requirements now.

YNAB budget colors
Amount type	FG color	BG color	Contrast ratio
Negative	#651c0b	#f7c1b5	7.68
Positive	#1d4913	#c4ecbb	7.97
Upcoming	#70460b	#f9e1a9	6.37

This is a screen shot of how the colors actually look when viewed in the YNAB application. Note that I don’t see a check mark icon next to the positive amount:

YNAB acknowledges that it is still problematic for users who experience deuteranopia:

While this helps with readability, we still use red and green to send signals about Available amounts, which isn’t the ideal experience for anyone with red-green color blindness.

Below is an example of what these colors might look like for these users. It’s actually the difference between the red and orange pills that is nearly imperceptible.

screen shot of the YNAB colors using a filter that simulates red-green color blindness.

It’s great to see more web applications incorporating accessibility. Now if only it were clear what those three icons at the bottom of the modal message window mean. They have aria-label attributes on some emojis that are not at all informative:

<span class="intercom-reaction" aria-label="green heart reaction" aria-pressed="false" role="button" tabindex="0"><span>?</span></span>

<span class="intercom-reaction intercom-reaction-selected" aria-label="sleeping reaction" aria-pressed="true" role="button" tabindex="0"><span>?</span></span>

<span class="intercom-reaction" aria-label="art reaction" aria-pressed="false" role="button" tabindex="0"><span>?</span></span>

Postcard Resistance

Rachele DiTullio10 January 201817 July 2021Website

A year ago, I started a side project called Postcard Resistance in response to calls for writing the President and members of Congress to protest several issues. The premise is simple:

All you need are a printer, paper, pen and postage to make a difference.

The site provides several PDF templates anyone can download and print to create four postcards per 8.5″ x 11″ piece of cardstock. The front contains artwork about an issue or general premise, e.g. RESIST.

image of a red fist above the word resist in black — *Postcard front – RESIST*

On the backs, I created form fields where people can easily type up a message and add the name and address of recipients. This allows mass printing of ready-made postcards waiting for a stamp.

screen shot of the back of a postcard with editable fields for a message and a recipient's name and address — *Postcard back*

My goal was to spin up a simple, responsive site quickly. I decided that instead of creating something from scratch, I would use a template. W3 Schools provides a variety of templates for free. I began with the Start Page Template and modified it with code from another templates to display the postcard fronts in a photo gallery array.

screenshot of the Postcard Resistance site showing 6 sample postcard fronts — *Postcard Resistance website*

There’s always some code bloat with a template but I was pleased with how efficient the CSS is and the ease with which using a grid-based layout worked. I’m looking at using something similar to update my portfolio site.

The ongoing creative outlet of making new postcards is my favorite part of the project. Most are my ideas but a few were adopted from images on the web and converted from JPGs to vectors for the PDFs. Upcoming ideas include

Net Neutrality
Registering to vote
Retirement cards for MoCs facing reelection in 2018

Texas Gas Service Homepage

Rachele DiTullio7 November 2017Websiteaccessibility, forms

Another accessibility disaster. It’s great that people are finding creative ways to use JavaScript but it is not okay to ignore progressive enhancement techniques.

Your users should never see this instead of content:

Our site requires javascript, please enable javascript and refresh the browser window.

JS frameworks do a disservice to the Web after all the innovation and hard work that has gone into creating a separation model for content, presentation and client-side scripting.

drawing of a peanut M&M candy showing content as the peanut, presentation as the chocolate layer and client-side scripting as the candy shell — *Layering content, presentation and client-side scripting – Drawing by Dave Stewart*

The Texas Gas Service website gives us lots of examples. Let’s see how well we can use the site without a mouse, a.k.a tabbing through.

(Step 0: What is with this trend to play videos as background images? I thought we learned this lesson years ago. Having movement your users can’t disable is annoying and bad practice. Stop it.)

screenshot of the Texas Gas Service home page with user login form — *Texas Gas Service homepage*

Links I can’t click; let me count the ways
From the “I want to…” select menu to the hamburger menu to the footer, dozens of “links” are not marked up as <a href> and cannot be tabbed to, nor would they be read as links by a screen reader.

These aren’t links

This is lazy and wrong. If something is a link, make it a link. Fake links achieved with JS only are a large accessibility barrier.

<div click.delegate="goTo('home', true)" class="btn pill-btn white-fill-btn au-target" show.bind="!session.loggedIn" au-target-id="111">Pay my bill</div>
Tabbing order fail
The tabindex attribute can be a really useful tool. It can also completely screw up a user’s ability to access important information, like the “username” field. When I could not tab to the “username” field, I looked at the code and saw the field was set to tabindex=-1. I had to look this one up. Here’s a 2014 explanation from The Paciello Group:

When tabindex is set to a negative integer like -1, it becomes programmatically focusable but it isn’t included in the tab order. In other words, it can’t be reached by someone using the tab key to navigate through content, but it can be focused on with scripting.

From my perspective as a customer who visits this page, being able to log in is the number one user story but it isn’t possible using a keyboard.
Form validation errors
The only time the “username” field seems to get focus is if that field is empty when clicking the “Login” button. Plenty of client-side field validation solutions work without removing a field from the tabbing order.

Login form validation errors with login button disabled

If a user tries to login with bad data, a small modal window with a an unhelpful developer-style error message of “Login failed” appears at the top right of the page. There is no associated help text about the causes of the error, or which fields have errors, and focus is removed from the form making it that much harder to update the data.

Login failed error modal window

Adding to the confusion is the little green check in both fields indicating what would usually mean the field data is valid. But for this form, a green check merely indicates that a field isn’t blank. There isn’t any robust client-side validation occurring at all.

Pet peeve: What is the point of removing the browser scrollbar from the page? It provides a simple and useful way to indicate where I am on the page. This is something I really miss on mobile devices.