An HTML Element Potentially Worth $18M to Indiegogo Campaigns

September 24, 2019 ; 4 Comments

The title of this post is a play on Jason Grigsby’s recent post An HTML attribute potentially worth $4.4M to Chipotle . In it he asks:

How many other people have failed to finish an order because the form doesn’t support autofill and the error messages aren’t helpful? An HTML attribute potentially worth $4.4M to Chipotle

He guesstimates maybe a half percentage point and then runs the numbers against public data to come up with a potential value to Chipotle of adding some standard HTML — $4.4 million USD.

This argument, and the math behind it, is familiar to me. I have spent years trying to make the business case to clients for why they need to make their site accessible. I have pointed to the Click-Away Pound for potential revenue, or to more esoteric arguments about public perceptions, but few seem to care unless I can point to a specific dollar amount for their business.

What is my opportunity cost? What top-line revenue will it bring me?

I spit-balled in a tweet:

Where @grigs shows how a simple HTML fix can get a 0.5% increase in transactions worth $4.4M: cloudfour.com/thinks/an-html-attribute…

Now let’s do one where a simple accessibility fix increases your market by up to 20%. Adrian Roselli (@aardrian) September 21, 2019

Then I remembered I have some data I can use. Sort of.

The Indiegogo Payment Experience

Last June (2018) I was in the midst of screen reader testing when a local crowdfunding campaign came across my timeline. I wanted to support it, so I popped over to Indiegogo and quickly found that if there is anything that causes the Angular code driving the page to fail, then the entire page fails.

A couple refreshes later when I got the page to render, I tried to fill out my billing information and was greeted with a wall of edit has autocomplete for nearly every field on the page.

Sorry, your browser doesn’t support embedded videos, but don’t worry, you can download it. The caption file is also available in case your video player can import it. Nearly all fields announce as edit has autocomplete . At 21 seconds I get a field name ( Country edit, blank ) and type a value, but note it goes away when I leave the field. If you stick it out to the end you can see the error messages that do not get announced.

It was immediately apparent that the fields had no accessible name. Despite the visible text label, nothing was programmatically associated. Some digging revealed the problem:

<div class="pf-input full" ng-click="focus()" ng-class="{full: showLabel}" style> <label class="pf-input-placeholder ng-binding pf-input-placeholder--full" ng-class="{'pf-input-placeholder--full': showLabel}" style>Full Name</label> <input pf-formatter pf-validator ng-model="model" ng-blur="onBlur()" ng-class="{'invalid-input': validatorError || outsideError}" type="text" tabindex gogo-test="shipping_name" class="ng-valid ng-valid-pf-validator ng-touched ng-dirty ng-valid-parse" style> <ng-transclude></ng-transclude> <!-- ngIf: validatorError || outsideError --> </div>

The <label> elements had no for attributes to associate them with the fields. However, this was moot since the fields had no id attributes to connect them. This is also why my browser’s effort to autocomplete the fields resulted in filling each field with the exact same text.

When you do not provide autocomplete cues, the browser may improvise.

I filed a bug with Indiegogo. The next day (June 8, 2018) Indiegogo marked it as solved and closed it.

Fast Forward 1 Year, 3 Months, 20 Days

I will let the video speak for itself (literally).

Sorry, your browser doesn’t support embedded videos, but don’t worry, you can download it. The caption file is also available in case your video player can import it. From 1:09 to 1:42 I am trying to Shift + Tab backward in the form but am trapped in the credit card fields. Then I drop out of forms mode ( Caps Lock + Space ) and go back to the nearest previous landmark ( Shift + D ).

With NVDA and Firefox getting you nowhere, if you fire up JAWS with Internet Explorer, a common browser pairing, Indiegogo gives you a different welcome altogether.

Along with useful link text such as Igg browsererror asset moz Mozilla Firefox, link .

At least with VoiceOver and Safari I can get through more fields on the form by guessing at field names, though it understandably falls down when it encounters fields that share an id with <label> s that point to… one or the other:

<div class="pf-input full" ng-click="focus()" ng-class="{full: showLabel}" style=""> <label for="address" class="pf-input-placeholder ng-binding pf-input-placeholder--full" ng-class="{'pf-input-placeholder--full': showLabel}" style="">Street Address</label> <input pf-formatter="" pf-validator="" ng-model="model" ng-blur="onBlur()" ng-class="{'invalid-input': validatorError || outsideError}" type="text" tabindex="" gogo-test="shipping_street_address_1" autocomplete="shipping street-address address-line1" id="address" name="address" class="ng-pristine ng-valid ng-valid-pf-validator ng-touched" style=""> <ng-transclude></ng-transclude> <!-- ngIf: validatorError || outsideError --> </div> […] <div class="pf-input" ng-click="focus()" ng-class="{full: showLabel}"> <label for="address" class="pf-input-placeholder ng-binding" ng-class="{'pf-input-placeholder--full': showLabel}">Address Line 2 (optional)</label> <input pf-formatter="" pf-validator="" ng-model="model" ng-blur="onBlur()" ng-class="{'invalid-input': validatorError || outsideError}" type="text" tabindex="" gogo-test="shipping_street_address_2" autocomplete="shipping address-line2" id="address" name="address" class="ng-pristine ng-valid ng-valid-pf-validator ng-touched" style=""> <ng-transclude></ng-transclude> <!-- ngIf: validatorError || outsideError --> </div>

A Single Element Fix

There is a lot going wrong on this page, even after Indiegogo’s effort at a fix. Axe finds 33 errors on the page, ARC finds 36. And we know automated accessibility testing tools only capture about a third of issues.

But the single thing blocking these screen reader examples is the broken accessible name or, more specifically, incorrect use of <label> . To use it correctly would require fixing the id s as well.

Correctly using <label> won’t resolve the problems for every user, but it gives us a starting point.

How Many Users Does This Impact?

Getting specific numbers of users is tricky. We cannot, and should not, detect screen readers. What we can do, however, is use Cornell’s DisabilityStatistics.org to get a general percentage of the population and extrapolate out.

The percentage of non-institutionalized people, male or female, regardless of age, ethnicity, or education levels in the United States that reported a visual disability in 2017 is 2.3%.

This self-reporting is from the U.S. Census Bureau’s American Community Survey (which has its own accessibility problems, potentially skewing the numbers lower), and the data is more recent than the 2018 Americans with Disabilities: 2014 which, as the title implies, looks at data four years earlier. You can get more segmented numbers from National Federation of the Blind’s Blindness Statistics page, which also offers a bit more detail on the population breakdown.

The numbers do not take into account screen reader users who are not blind (or visually impaired), such as those with learning impairments, dyslexia, mobility impairments, and so on. Between one-quarter and one-third of screen reader users are not represented in the blindness statistics, which means we should increment that 2.3% accordingly. In the interests of math, let’s round it to 3%.

The broken <label> s also means any voice-only users cannot use voice commands to choose fields. They may say the visible label text, but without it being programmatically associated with the field, it won’t highlight any of the fields they want. Since I do not have easy access to numbers of voice users, let’s conservatively assume my 3% number includes them (though it may be grossly under-counting).

Thanks to some questionable and sloppy math I can assert that a correctly implemented <label> allows any single campaign on Indiegogo to potentially capture 3% more money.

How Much is a Correct <label> Worth?

I am going to take one year of funding pledges on Indiegogo, using data from a cumulative history chart and looking at just the dollars amount raised between April 2018 and April 2019. In April of 2018, Indiegogo had raised $3,607,430,000 since its start. By April 2019 it was up to $4,203,440,000. That is $596,010,000 in one year.

If $596,010,000 is only from 97% of the total possible audience, then capturing 100% of the audience would put that number up to $‭614,443,300‬. That’s a difference of $18,433,300. I will follow Jason’s approach here and show my math:

$4,203,440,000 Raised by Indiegogo up to April 2019 − $3,607,430,000 Raised by Indiegogo up to April 2018 = $596,010,000 Raised by Indiegogo in that one year 2.3 % of population with visual impairment × 0.3 % of non-blind screen reader users × ?.? % of voice users = ~3 % of users $596,010,000 Raised by Indiegogo April 2018 to 2019 ÷ 97 % of potential audience (100% − 3%) = $‭614,443,300 Possible funds in that year − $596,010,000 Raised funds in that year = $18,433,300 Funds left on the table

Indiegogo takes a minimum 5% fee from funds raised, which comes out to $921,665.

Recap

To recap, if Indiegogo had correctly implemented <label> s on its payment form then last year its campaigns would have had access to more than $18 million dollars. Indiegogo then could have put nearly a million dollars in its pocket.

There may be a reason accessibility-related campaigns on Indiegogo consistently fail to make their goals.