For Infinite Scroll, Bounce Rate Is a Vanity Stat

Animation showing me scrolling an article at the Fortune site. The yellow arrow indicates when the URL changes. At that point leaving the site will not count as a bounce.

About a year ago I wrote a post with a checklist of items I feel you would need to satisfy before you can ever consider putting infinite scroll on a site. Surprising no one, the checklist hasn't really caught on (though it has generated a lot of traffic and discussion).

Worse, no one (that my Google-fu found) is challenging the most common argument in favor of infinite scroll: user retention, often described as a reduced bounce rate.

I've simplified it a bit, but the gist is that advertisers and marketers want to see a low bounce rate on a site (ideally one that continues to fall). This helps justify ad buys and is often used as a proxy for engagement.

Typically authors who want to write a pro/con piece on infinite scroll will cite user retention. The same is true for those whose success is measured by low bounce rates, as well as those who just really like the infinite scroll "feature."

Because content continues to appear, users find themselves scrolling and interacting for longer periods of time.

Infinite Scrolling: Pros and Cons at Design Shack

You stand a better chance of retaining the user because there’s nothing for them to do but scroll. It’s almost like a subliminal call to action.

The UX of Infinite Scroll: The Good, the Bad, and the Maybe at SitePoint

Since its March redesign, Time.com’s bounce rate — the percentage of visitors who leave the site after viewing only one page — has declined by 15 percentage points[.]

Mobile page views in June were up 30 percent over the previous 12-month average [on the redesigned NBC News site.]

Quartz estimates “readers view about 50 percent more stories per visit than they would without the option to scroll.”

Time.com’s bounce rate down 15 percentage points since adopting continuous scroll at Poynter

The numbers look great in a vacuum. As readers, we don't have access to the raw data. We can't see if the reduced bounce rate correlates with a (minimum) doubling of time on the site. We cannot see if the user gets to the new headline and just leaves the site. There is no metric for a second-step bounce rate.

I posit that the goal to affect the raw stats doesn't necessarily mean more engagement.

On these sites, when I keep scrolling to make sure I've finished the article, the URL changes. I haven't actively gone to another page. Whether or not I choose to read the next article, this is counted as retention. I don't count as a bounce simply because I scrolled, not because I have started to read (let alone finished) the next article.

A couple examples of this in action (in addition to the opening image)…

Animation showing the URL changing (when the yellow arrow appears) as I scroll down the page at the Time site.

Animation showing the URL changing as I scroll down the page at the Forbes site.

We should be wary of these engagement or retention claims. Measurements shouldn't be about solely bounce rate, and minor jumps in engagement time are also a poor proxy. Perhaps a bounce should count unless the user makes it to the end of the next article. Perhaps retention should only count if the user's time on the site equals or exceeds twice the average time it takes to read an article.

As always, unless someone who manages a content site with infinite scroll (that isn't a stream-based site like Twitter or Facebook) can show data to prove infinite scroll genuinely leads to greater retention and engagement, I won't trust the measuring stick. Neither should you when making a decision about whether or not to implement infinite scroll.

Related

• So You Think You’ve Built a Good Infinite Scroll at this site, May 31, 2014.
• Infinite Scrolling – Impact on Accessibility Series – #1 Common Issues from SSB Bart Group, May 1, 2015.
• Infinite Scrolling (mobile version of the page so you can tap the alt text) from XKCD.

Update: May 18, 2015

USA Today decided to ditch its infinite scroll, as reported by Digiday and its infinite scroll:

FTW’s implementation of infinite scroll, which displays a never-ending lists of article headlines below its articles, has been a major drag on the site’s mobile page loading times, so it had to go.

USA Today's FTW redesign ditches the infinite scroll, at Digiday

Another Update on May 18

Smashing Magazine asks the question, linking to this post:

Have you actually seen an infinite scrolling pattern working well for user engagement in your UI? A few notes: http://t.co/PiYGMfoMc0

— Smashing Magazine (@smashingmag) May 18, 2015

Twitter App Sets Browsers Back 10 Versions

Screen shot of a web page as seen in the Twitter app, with a menu showing the option to open in the user's default web browser.

The title of this post may be a bit of hyperbole for some, but it is completely true for me.

Sometime over the course of the last week Twitter changed what happens when I tap links in the native Twitter app on Android. Links now open within an embedded browser, not in my default browser.

I have Chrome 40 installed on my Android phone. The built-in web view on my phone is 10 releases back, at Chrome 30. Normally this isn't a concern of mine, but when a good deal of my Twitter timeline consists of bleeding edge web development techniques, I want to view those on a current release of Chrome.

The first image shows that the user agent string within the Twitter app includes Chrome 30. The second image shows my default browser user agent string is Chrome 40.

This change appeared while I was traveling internationally, which means I had a slower connection than usual as well as a data cap. Not only do I have to view content in an old browser, I have to know that the web view is older so that I then know to open it in my default browser.

That's at least two more taps, plus the burden of the download starting in the web view that I don't want. That extra download burden also impacts my data cap, which is an even bigger issue if I have chosen to surf with Opera Mini to make the most of my limited data cap (you know, data budgeting).

Not only did I never enable this feature, I cannot disable it. It appeared three weeks after my last Twitter app update (see the caption below).

The first image shows the settings screen in the Android Twitter app, version 5.48.0. You can see there is no option to disable the in-app browser, though it has been enabled. The second image is the note in the Google Play store that tells me the only change in the new release is updated profiles so it's easier to view bios, Tweets and photos. The final image shows the option to disable the in-app browser, but only because I updated to version 5.51.0 (when I returned from home and shed my data cap).

So What?

A couple months ago Peter-Paul Koch wrote about the massive fragmentation in the world of Chrome (Chrome continues to fall apart at brisk pace), something to which Twitter is now contributing en masse.

In the modern world of rapidly updating browsers, 10 releases may not seem like a big deal. I guess it comes down to what you want to see, or more importantly, what you want your users to see. Can I Use provides a quick way to compare Chrome 30 and Chrome 40 to see which features you may be missing. Here's a short list:

• The ability to discard many -webkit- prefixes,
• Font unicode-range subsetting,
• matches() DOM method,
• CSS touch-action property,
• CSS Font Loading,
• Custom Elements,
• picture element,
• Web Cryptography,
• WOFF 2.0 - Web Open Font Format.

If you rely on any of these (or many other) features of the open web platform, and you receive traffic from Twitter, I suggest you monitor your logs to see if the most common version of Chrome drops.

As for user experience, If you plan to allow users to toggle a new "feature," don't push that feature to them without the toggle. Especially when you exclude it from your update notes within the app store.

Best Viewed in 1 of 11 Flavors of Chrome!

Make sure you view this on Google's flavor of Chrome, otherwise, well, I have no idea what will happen.

Sometimes it's frustrating being a developer who's been around to see Mosaic supplanted by Netscape Navigator supplanted by Internet Explorer supplanted by Chrome/WebKit. Developers just love dumping one platform for the new shiny.

As I said last week, all of this has happened before and will happen again. The difference with this post is that I am not going to rant about lazy developers whining over a world that will still contain Internet Explorer and its offspring.

Instead, let's ask the average anti-IE / pro-WebKit developer a very simple question — on how many flavors of Chrome do you test?

I don't mean how many versions of Chrome. I also don't mean how many different WebKit-based browsers. No, how many flavors of Chrome?

I'll guess probably not more than a couple. I have four that I can, but typically don't, use. Even at four that's far too few.

Today Peter-Paul Koch pointed out that there are eleven (11!) flavors of Chrome (Chromia, if you will). All of them built on Chromium. Here's the breakdown from his article:

Vendor	Version	Tested	Default	Remarks
Google	40	Yes	Yes
Opera	39	Yes	No
Yandex	38	Yes	No
Xiaomi	34 or 35	Yes	Yes	Zoom reflow
HTC	33	Yes	Yes	Zoom reflow
Cyanogen	33	Yes	Yes
LG	30	Yes	Yes	Mid-range
Puffin	30	Yes	No	Proxy
Samsung	28	Yes	Yes
Amazon	37	No	Yes	Silk
LG	34	No	Yes	High-end

Peter-Paul Koch from the post Chrome continues to fall apart at brisk pace

You may have noticed that this only accounts for mobile devices. Some on Twitter also noted Chrome on Google TV, or on Android TV, which doesn't account for the Samsung Android TV nor the Sony Android TV.

So maybe it's fifteen (15!) flavors of Chrome. Either way, I suspect that number will continue to grow.

Even if I include IE6, I only have to worry about 5 versions of Internet Explorer across mobile and desktop. If I want the idyllic WebKit-only world so many seem to crave, then I need about a dozen flavors of Chrome before I can get started with the Operas, Safaris, Yandexes, and Vivaldis (plural because those forks of WebKit also have their own versions to support)

All of this written against the backdrop of a Medium post claiming it won't consider IE11 a Tier 1 browser because of what it considers an ugly border in the editor view. Unable to find IE developers anywhere, nor to figure out where to file a bug, Medium just browser-sniffs IE11 into a second tier. I'm sure Medium tested across eleven flavors of Chrome, though.

Please read PPK's piece: Chrome continues to fall apart at brisk pace

All of This Has Happened Before and Will Happen Again

Jacob Rossi from Microsoft put together an article for Smashing Magazine that discusses Microsoft's Project Spartan web browser, Inside Microsoft’s New Rendering Engine For The “Project Spartan”.

Unlike other click-bait efforts that only speculated that perhaps Spartan was going to be WebKit-based, showing their own preference instead of any real understanding of the browser world, this one is filled with lots of great information. You should read it.

The first few comments, on the other hand, started off a mess (with many more on Twitter since the initial announcement). Two examples from the article:

So here was the opportunity to swallow their pride and join WebKit to make the internet a better place

…and they built *another* closed-source, proprietary rendering engine.

[Slow sarcastic clap]

Jones

« IE did shape the web in a positive way »

This made me laugh more than it should. You seem to forget why Internet Explorer has felt the need to change its name in the first place. And it’s not because it was «too good» or «too innovative»…

Erick G.

Many folks jumped in and corrected, down-voted, and generally balanced the insipid whining. Christian Heilmann, who has logged more years working for Firefox than most devs have logged using it, waded in to challenge many of the incorrect assertions.

Bruce Lawson, who happens to work for another browser vendor (Opera) noted all the things Internet Explorer did for the web in his five-year-old post In praise of Internet Explorer 6. It's also a cautionary tale about where reliance on a single rendering engine will take us.

What these two guys have in common, besides working for the competition, is that they have been on the web since its dawn. They've seen what happens when one browser gets too big (Internet Explorer) and how we spend the next decade-plus digging out from the mess.

How did we get into that mess? By people coding for one rendering engine.

Everyone who calls for WebKit in Internet Explorer is exactly the same kind of developer who would have coded to Internet Explorer 15 years ago (and probably happily displayed the best viewed in badge).

If you are that developer, then it will all be your fault when it happens again. When WebKit is no longer the hot engine. When Chrome loses its dominance. When Apple's market share falls to match the developing world. You will be to blame.

Do you think that won't happen? Just look to Android browser fragmentation, or WebKit failing to support a standard that Firefox and IE have nailed, or Chrome introducing its own proprietary features (can't find the link; it's coming), or failing to use best practices as it tries to carry the next big thing forward, or the complete lack of developer relations from Apple. We've had over half a decade of warning signs.

It's happening again, and every petulant, lazy developer who calls for a WebKit-only world is responsible.

Related

• The Return of “Best Viewed in…”
• Everything Will Be the New IE6

Update: February 3, 2015

My rant continues in my post Best Viewed in 1 of 11 Flavors of Chrome! It's built off PPK's Chrome continues to fall apart at brisk pace. Even I didn't know there are so many Chromium variants.

Learn to Do It Yourself

Often when I identify a valid technical (typically accessibility) issue with a site, tool, or library and get a response of just make a pull request, I am thrown into an apoplectic fit for which I have to apologize to my co-workers (or people at the random coffee shop or airport).

My Thesis (Rant)

I am not going to fix your arcane niche library/tool nor your single-use site that you'll dump in a few months. That isn't a good use of my time, and you learn nothing.

I bill for doing just that; it's how I earn a living. Like all of you, I have many things to do besides my day job, some of which are far more important to my community or personal well-being.

I speak at conferences and write for sites not just for free, but at a cost to me in most cases (nearly all cases), specifically to teach the skills that would allow you fix the issue on your own. I do this without targeting a specific language or platform except where it most directly impacts the user (typically HTML, CSS, and vanilla JavaScript).

I am trying to identify issues and arm you to fix them, both in this case and for the rest of your career.

Asking me to fix it (hey, just make a pull request) is a cop-out. It's short-arming your own technical growth.

Fix it yourself.

Learn how to do it.

Carry that skill forward to future projects, enriching both your users and your career.

Take some pride in your craftsmanship by learning how to address a valid problem.

Short-arming accessibility (the vast majority of my bug reports) is why we're inundated with inaccessible libraries and tools. It's always someone else's problem.

My Pedigree

I've been performing reviews, contributing to and building one of the first developer sites and lists, speaking, writing tutorials, articles & books and generally been offering my time and expertise for free or nearly free for almost twenty years.

As an example, when I started Print Shame it was born of frustration from developers failing to make the extra effort. Then I decided to be more constructive and wrote a number of articles, developed techniques (with cut-and-paste code), backed it up with research, and flew/drove around at my expense to present all that I learned.

If I tell you that your site doesn't print and you suggest I can give away my time to fix it, I'll note that I've already done so. In some cases I've spent more time educating for free than you spent building the entire project.

I've given back, and I continue to do so. In a way that will outlive your site or project.

Ideally, my talks and writing reach more people than one bug report. Hopefully they provide real-world context and examples for others to draw parallels to their own projects.

My Overreach

My mentor would always ask the same question when I whined that somebody wouldn't do something I wanted. He'd ask, What are you going to do about it? Karl Groves makes the same point, essentially, for open source projects:

When you bitch about an open source project, you're not solving anything, just making noise. Stop bitching. Start fixing.

— Karl Groves (@karlgroves) October 16, 2014

Steve Faulkner pushes back:

@karlgroves 'open source' projects heavily funded by corporate $$$ should not place responsibility for #a11y on the community

— Steve Faulkner (@stevefaulkner) October 16, 2014

Sometimes that applies, sometimes it doesn't. Karl is right in his response that two thousand word blog posts aren't even bug reports. I get that. I encourage you to read the entire Twitter thread; there are valid points on both sides, some which poke holes in my argument above (in specific cases) and some which bolster it.

There are many people who are better than I by fixing tools directly. Patrick Lauke has been stepping up and contributing accessibility fixes to Bootstrap. Marcy Sutton has done the same for Angular. Many are contributing and doing great things. Not whining, but doing.

When it comes to non-open-source projects or sites, it's a bit more difficult to just do something. I've spent more time trying to get Virgin America to fix its keyboard accessibility failure than if I had been granted access to the code to remove one line of CSS. In those scenarios I am stymied.

I also know I can come off hot, like when I raised a similar issue to a buttons library. I acknowledge that when I recognize it, but in the end the issue was resolved, the developer learned something, and end users get a better experience. It can work.

My Message

If you are a developer and find an issue as part of an open source project and have the time to fix it, do as Karl suggests above and fix it.

If you don't have the time nor inclination, help the developer with a detailed bug report. You don't have to use the bug reporting tool, you just need to get it some attention.

If you're a developer and you've had a valid issue identified, then don't expect the person reporting the issue to fix it. It is fine to ask for help if you don't understand the issue.

Asking the person who reported it to learn your bug tracking system is a bit much. Accept the feedback as offered, even if by Tweet (where you may be most accessible).

Linear Gradient Problems in Chrome

Detail of the effect I wanted to re-create with a linear gradient — a gray column, a white narrow gutter, a black vertical line, and the rest as white.

I'm going to tell you up front that I don't have a fix for the issue I am raising, though there are bugs filed against it.

I wanted to create equal-height columns that don't use tables, piles of JavaScript, background images, or many of the other code-heavy techniques out there today. I just wanted a CSS-only option. I have played around with CSS gradients to define columns before, something it turns out was covered in 2010 at CSS Tricks, and I decided browser support had come along enough that I could make a prefix-free solution.

In the image above I show an example where I want a vertical line between two columns, along with a narrow gutter. This is pretty straightforward, though you're better off doing it by hand than using any of the gradient generators out there right now. Ultimately I needed a step that is one pixel wide (yes, I am using pixels for this example) that is also a solid color. Easy enough.

It turns out that Chrome, Firefox and Internet Explorer 11 just don't seem to dig making a one pixel gradient step. That's ok. I can work with that. What I wasn't prepared for was how Chrome (38 as of this writing, though this appeared in prior versions) opted to handle it.

At some window sizes, Chrome displays no step at all. At other window sizes, it's 5 pixels. Sometimes the widths of the other steps change as well. This means some Chrome users will see nothing, others will see something five times wider than I want. The animated GIF below shows what happens to the line (in red) as I scale the window width. I think you can agree that it can be a pretty jarring experience for users (part of me worries that this kind of rapid flashing on the whole page can also overwhelm some users).

Animated screen capture of the CodePen in Google Chrome 38 showing the stuttering width of the "columns" and the inability to handle a one pixel band/step.

The animated screen shot is from a Pen that I created to show the effect. I have embedded it below, though you can visit (and fork) the pen directly at CodePen.io.

There are also two open Chromium bugs and one Stack Overflow discussion that are related, though not just with single-pixel gradients.:

• Issue 233879: Bug with linear-gradient layout, Apr 20, 2013 (with a sample pen).
• Issue 281489: Linear Gradient color stops not calculated correctly, Aug 29, 2013 (sample pen missing).
• Webkit linear gradient stops render incorrectly, May 13, 2014 (with a different example pen).

Notes on the first bug offer an explanation of sorts:

skia discretizes the colors into 256 levels for (lots of) speed. hard-edged gradients like this (where there are two colors at the same color-stop) definitely show up this limitation. We can look at ways to increase precision, but there will be a real performance cost, so we have to decide how important this particular behavior is in practice.

Essentially the argument is that this is a performance trade-off. One that both Firefox and Internet Explorer seem more than capable of handling, which means I'm not buying this excuse a year and a half after it was offered. It just feels like a cop-out.

If you think that your work could benefit from having these bugs fixed, please go star them. Otherwise we may not use that awesome CSS feature, and by extension we're enabling the browser monoculture that is Chrome.

Update below the pen

See the Pen Testing Gradients as Column BG by Adrian Roselli (@aardrian) on CodePen.

Update: 10 minutes After Posting

I posted a link to my pen and this post to the bugs, and in both cases I later got email bounce notifications ("The email account that you tried to reach is disabled."). The address srsrid...@chromium.org, the only CC on 281489 and one of two on 233879, is gone which makes me think nobody is listening on at least one of the bugs.

CDC Ebola Response on Twitter Excludes Blind

This is one of the images tweeted by the CDC. The text contrast is 4.53:1, so it barely passes for large text. At this scaled-down size, however, the question text would fail a contrast test for accessibility.

In the United States, the Centers for Disease Control (CDC) is (or at least is supposed to be) the first line of defense against public health threats like Ebola. It makes sense, then, that the CDC would use social media to assist its efforts to get useful information in front of as many people as possible.

The problem is that the CDC's efforts on Twitter have fallen prey to reliance on the image attachment. When Twitter proclaims that engagement goes up when images are used, and because tweets limited to 140 characters, it can be pretty compelling to use images to convey a lot more content than would otherwise fit — and it can be styled and better branded.

The CDC Emergency Preparedness and Response account started an Ebola fact campaign, framed as a Q&A series of information nuggets (which makes me think it's really an Ebola FAQ campaign, but I digress). Here is the text of these tweets so far (no images):

We put together your most common questions about Ebola. Our first #EbolaFact is about sneezing. pic.twitter.com/KO25cXKiQI

— CDC Emergency (@CDCemergency) October 17, 2014 [alt]

Our next #EbolaFact is about how long the virus lives on surfaces, a common question about Ebola. pic.twitter.com/ekLEdM4o3z

— CDC Emergency (@CDCemergency) October 17, 2014 [alt]

Our next #EbolaFact is about why health workers wear protective gear if #Ebola virus isn’t airborne. pic.twitter.com/cEzVkqPGgK

— CDC Emergency (@CDCemergency) October 18, 2014 [alt]

Today's #EbolaFact is about whether pets can transmit #Ebola. pic.twitter.com/He5WP4suXq

— CDC Emergency (@CDCemergency) October 19, 2014 [alt]

Our next #EbolaFact is about the incubation period for those exposed to #Ebola. pic.twitter.com/TIwaiga1wi

— CDC Emergency (@CDCemergency) October 20, 2014 [alt]

That's it. No answers, no context, no links to more information. If you are a blind user, you get nothing of value from these tweets.

The main CDC twitter account makes the same mistake:

Get the facts about #Ebola. Here’s what you need to know about when a person can spread the disease to others. pic.twitter.com/DxeSlNhwKE

— CDC (@CDCgov) October 17, 2014 [alt]

Don't think the White House is doing much better. While the tweets at least include URLs to get more information, the text within the image is not included in its same easily-digestible form, and the data contained in the image is scattered across a long-form article on the site.

Worth sharing: Here are the facts on #Ebola, and what we're doing to respond → http://t.co/RMFwal2IB8 pic.twitter.com/UJLnOsP7RV

— The White House (@WhiteHouse) October 16, 2014 [alt]

RT to get the word out: Here are the facts on #Ebola: http://t.co/RMFwal2IB8 pic.twitter.com/KR25pBZvaR

— The White House (@WhiteHouse) October 16, 2014 [alt]

Easy Fixes

Even if you're not the CDC, I think there is still a lesson to be learned here — putting all your tweet content into embedded images is a great way to exclude users. Thankfully the CDC can choose from one of three (four?) easy fixes.

Make Supporting Web Pages

The CDC can simply link to the content in the images as equally-short nuggets on its web site. Clear out the cruft of third-party "share" icons, remove the excessive footer, and generally pare the page down to the fastest load possible. To support these users, don't make them have to navigate to the nugget of content when landing on the page, make it the entire page.

Tweet Your Own Alternative Text

There has been a trend in the accessibility community on Twitter to include or describe images in their own tweets and sometimes in others' tweets.

It ranges from linking to a longer description, to just a quick inline description, to sometimes a reply to the tweet with the alternative text so the two stay associated within Twitter's own tweet-linkage display. You might be pleasantly surprised when people thank you.

Use a Tool Meant for This Purpose

Alternatively, look at a tool like Easy Chirp to embed the full text content within the tweet itself. It already has traction in the blind community, so those already familiar with it don't have to struggle through a learning curve.

Here's the same tweeted image as CDC's first Q&A tweet, but this time it has alternative text just one click/tap away (without losing the image for sighted users):

Giving @CDCemergency example of image embed with alt text within tweet with @EasyChirp. http://t.co/7jlgrSJm53 pic.twitter.com/FUK3N3xcqQ

— Adrian Roselli (@aardrian) October 20, 2014

GIFs in Words on Twitter

This one is a bit far-fetched, but convince the @gifsinwords Twitter account to fill the gap. It's already proven pretty handy to some.

Update: October 21, 2014

These slides might prove interesting related reading (no video that I am aware of): How Companies Engage Customers Around Accessibility on Social Media

Update: October 23, 2014

It looks like both CDCEMergency and CDCgov have each improved a tiny bit in their most recent tweets, insofar as the key point of the message in in the text of the tweet (even if there is still no full alternative text):

Our next #EbolaFact: A person infected with #Ebola virus is not contagious until symptoms appear. pic.twitter.com/MQUpd0zRC4

— CDC Emergency (@CDCemergency) October 23, 2014

#EbolaFact: No cure for #Ebola, but @NIH @DeptofDefense & other fed partners are working on a vaccine. pic.twitter.com/IBftmce3NX

— CDC (@CDCgov) October 22, 2014

---

Alternative Text (You Can Probably Skip This)

I intentionally didn't allow any of the images in the examples to embed. I think you should experience the tweets the way a blind user would (with the exception of the opening image with its low contrast). However, I also want to make sure the content is still available to readers. So I am helping the CDC here and including the text from each image above (also linked from each image above).

CDC Ebola Q&A:
Q: Can Ebola spread by coughing? By Sneezing?
A: If a person with Ebola coughs or sneezes on someone and saliva or mucus contacts that person's eyes, nose or mouth, disease may be spread.
http://cdc.gov/ebola

CDC Ebola Q&A:
Q: How long does the virus live outside of body? What effectively kills it outside of body?
A: Ebola on dried on [sic] surfaces such as doorknobs and countertops can survive for several hours; however, virus in body fluids (such as blood) can survive up to several days at room temperature. Ebola is killed with hospital grade disinfectants (such as household bleach).
http://cdc.gov/ebola

CDC Ebola Q&A:
Q: If Ebola isn't airborne, why do health workers wear protective gear?
A: CDC recommends Ebola healthcare workers wear protective gear due to the possibility of large amounts of blood, other body fluids, vomit, or feces present in the environment.
http://cdc.gov/ebola

CDC Ebola Q&A:
Q: Can I get Ebola from my dog or cat?
A: At this time, there have been no reports of dogs or cats becoming sick with Ebola or of being able to spread Ebola to people or animals. The chances of a dog or cat being exposed to Ebola virus in the United States is very low as they would have to come into contact with blood and body fluids of a symptomatic persion sick with Ebola.
http://cdc.gov/ebola

CDC Ebola Q&A:
Q: What is the incubation period for Ebola?
A: The incubation period, from exposure to when signs or symptoms appear, is to 2 to 21 days, but the average is 8 to 10 days.
http://cdc.gov/ebola

Facts about Ebola
When is someone able to spread the disease to others?
Ebola only spreads when people are sick. A patient must have symptoms to spread the disease to others. After 21 days, if an exposed person does not develop symptoms, they will not become sick with Ebola.

Get the facts on Ebola:
Ebola is not spread through: Casual contact, air, water, food in the United States.
WH.gov/Ebola-response

Get the facts on Ebola:
You can only get the Ebola virus through direct contact with: body fluids of a person who is sick with or has died from Ebola; objects contaminated with the virus; infected animals.
WH.gov/Ebola-response

One-man Focus Group for Twitter's Timeline Changes

TL;DR: Twitter is showing tweets in your timeline that people you follow have favorited or just from those they follow. Way below I outline how I have been reacting.

Much has been said of Twitter's recent change to start putting more than just promoted tweets into users' timelines (such as this forewarning from Gigaom in July). Much of it was said from the "what if" perspective before it had been fully implemented. I've decided to share my experience as a user now that it's up and running.

Context

For a little context, I first saw this happen in March and quickly got annoyed when Huffington Post (which I consider the bottom feeders of regurgitated news bites) tweets started to appear in my timeline. Considering how much time I have spent cultivating my feed, I was worried this was a new trend.

Once Twitter formalized this, some savvy people felt compelled to post a disclaimer once it became clear what they favorite could become stuffed into someone else's timeline alongside their name. Here's one example that covers my feelings pretty well:

Given Twitter’s new change, I want to clarify that when I fav a tweet, I mean “Ha!”, “Read later”, “Thanks” or “First against the wall”.

— Ed Yong (@edyong209) August 20, 2014

I could link to tweet after tweet expressing frustration with this change, but posts like this one from The Next Web have already done a nice job of cataloging the changes as well as the general response.

With all the Ferguson coverage lately Twitter has come out as the best source for news — moreso than traditional media and far better than Facebook. It's been a PR boon, resulting in posts like the aptly-titled Why Facebook is for ice buckets, Twitter is for Ferguson.

Why would Twitter want to start adjusting the timeline that is garnering it so much praise, further risking a descent into being no more than an echo chamber or a marketing assault?

Observing Me

Once these changes started to appear in my timeline I mostly got annoyed and tried to ignore them. I swiped past them and mumbled. But this weekend I snapped. Saturday morning my timeline was regularly filled with cruft I have worked to avoid, from outlets such as Buzzfeed and TMZ. Since they always include photos in the tweets, it takes up half my screen with every unwanted tweet.

Knowing Twitter doesn't care about me as a single user, and clearly doesn't care about the rising voices who are against this change, I opted to do something about it for myself. I didn't start these steps with the intent of writing this post, but perhaps someone at Twitter will see how the user is routing around the problem and reconsider its position.

Steps I've Taken (So Far)

• Blocking
• Unfollowing
• Not Favoriting

Detail on each follows…

Blocking

I enjoy the Twitter account Saved You a Click. It has become something of a news source for things I wouldn't ever see anyway (sports, celebrities). Saved You a Click follows many accounts I would never follow, like Buzzfeed and TMZ. After tweets from those two sources appeared in my timeline, tweets that Save You a Click didn't even favorite, I decided to simply block those accounts.

I then let Buzzfeed and TMZ know that I blocked them (probably falling on deaf ears). Perhaps, however, if enough people block the accounts that are shoehorned into their timelines, those account owners might raise a stink with Twitter on the other end.

The first screen shot shows a tweet from TMZ, the second shows another from TMZ, both taking up half of my visible timeline with content I do not want. So I blocked TMZ. You may click/tap/select each image for a larger version.

Unfollowing

Yesterday after seeing a few tweets that folks I follow had favorited, or even just from accounts that they follow, I opted to prune my following list. I cut my list from 199 people to 183 people and immediately reduced some of the items in my timeline related to sports, celebrities, and other things that don't interest me.

Having me as a follower isn't exactly a badge of honor. I'm sure none of them care very much. But we as users should all consider that we might lose followers simply because of who we follow and what we favorite (regardless of why you favorited it).

The first screen shot shows a tweet from CNN that I had already seen three hours prior (since I follow CNN), the second shows one from Buzzfeed, which I then blocked. In this case I did not unfollow the accounts from which those tweets were "sourced" (?), but I did unfollow others. Note that the second image shows two tweets, of three, that were not re-tweets nor from accounts I follow. You may click/tap/select each image for a larger version.

Not Favoriting

Tweets that I favorite might appear in someone's timeline now. I've already seen it happen to others, and just this morning I got verification that it happens for mine.

I don't like that. I don't want people seeing what I mark for later reading. I also don't want it to appear to be a re-tweet (I am so opposed to the "ideal" re-tweet model that I have only ever done one, the rest are all manual). So I have a simple solution: I will no longer favorite tweets. I'll simple send them to myself (there are tools that can do this for me, but I'll probably just email them).

Each image shows a tweet that someone I follow favorited. The tweets don't interest me, but I don't want to unfollow them. The lesson here is that I shouldn't favorite else I get unfollowed, not to mention I don't want folks to see a favorite as an endorsement. You may click/tap/select each image for a larger version.

Other Actions

I'm now looking at the tops of tweets to see if the tweet was truly re-tweeted, or just favorited, or is just from an account that someone I follow follows in turn (see the opening image). That's annoying.

I'll probably refine this over time, either as Twitter adapts or as I find better ways to do it (like installing a third-party app that I don't hate).

Wrap-up

I'd prefer if Twitter stopped this or at least made it an option I can disable. In the absence of that happening, I am taking the Internet's lead and routing around the problem.

In time I may simply check out of Twitter as I have already done with Facebook for doing the exact same thing.

If you are from Twitter and are reading this, I hope this post is useful as a one-person user study. I am happy to answer any questions you may have.

Update: September 4, 2014

Looks like this is just the first step in a larger change for Twitter to try to replicate the very feature that causes so many to make fun of Facebook: Twitter CFO says a Facebook-style filtered feed is coming, whether you like it or not

Since Saturday I have blocked the following Twitter accounts, solely because of Twitter's change:

• @TMZ
• @BuzzFeed
• @WIRED
• @VICE
• @verge
• @Slate
• @HuffingtonPost
• @peoplemag
• @USATODAY
• @Adweek

Patents versus Accessibility — Again

I've ranted about frivolous patents more than once here. Others far closer to the issue do it daily, so my voice is but a drop in the ocean (and yet nothing happens).

This time it's a little different, and yet familiar (read my April post Patents versus Accessibility). Thanks to a tweet from WebAxe, I found out that somebody has patented (granted June 26, 2014) a tool that automatically makes a web site accessible. I find this a preposterous claim (at best), but here's the abstract from the patent:

A method for an accessibility solution provided as a software. The method includes approving or implementing by a website owner of a code into his website and receiving web format by a user device by “scraping” the data from the website pages or by other means of using client side plugin, server side plugin, browser or 3rd party server side or mobile app. The method also includes analyzing the data over the user device or on the server side and clicking a button by the end-user and the original code and the content and code that were collected from the website are rewritten which can also be done automatically as a suggestion to the end user, and the end-user sees or can use a new format according to the updated standard.

Unlike so many frivolous patents that are nothing more than an idea, this patent has some compelling claims. Unfortunately, the likelihood that all those claims can be realized seems pretty small.

Why I Am Wary

Just as anyone who practices accessibility understands that there is no automatic tool that can completely and truly evaluate a site's accessibility, there is also no tool that can automatically make a site accessible. To quote Jared Smith of WebAIM fame:

Accessibility is a continuum. It is based on the user experience. It cannot simply be defined as pass/fail or accessible/inaccessible.

While I don't want to attack what may very well be the well-intentioned best efforts of a dedicated person or team to improve the nature of accessibility on the web, I also have too many conversations with clients who are happy to accept a one-click solution at face value, unaware of the risks. More than anything, this post will serve as a quick reference for the inevitable conversation I'll have with a client or prospect about relying on a tool like this (or perhaps this tool in particular).

I am interested in how this tool can evaluate the value of alt text on images, verify whether an article or section is the correct sectioning element, make sure that placeholder text is not a barrier, understand when a button should be used, and so on. And then fix all these by re-writing HTML, JavaScript and CSS and not introduce more issues. These are just a tiny, miniscule slice of the kinds of decisions that require a person who understands the context in order to be successful.

The Patent Holder's Qualification

The evidence doesn't bear out that this tool can do what it advertises. The company that makes it, which promotes its accessibility services, has many issues on its own site. Which begs the question, did the company use its own tool and get such awful results, or does the company not see enough value in it to use it?

I wasn't the first to tear into the site. Folks on Twitter independently identified issues with color contrast, keyboard navigation (ok, that was me), image alt text, use of a carousel, a blank accessibility statement, incorrect ARIA role use, and misspelled ARIA attributes. All this feedback was unprompted.

To be fair, the tool may not exist yet. The patent was only just approved, though it was filed over two years ago. While I don't want to name and shame, there really is no way to make my point about the proposed tool without doing so.

The Patent Holder's Possible Example

Looking to the site of the registrant of the patent (I also made a Wayback permalink) I see an "Accessibility" box floating on its home page which may provide insight into how this patent might be applied. This "Accessibility" box allows some rudimentary control over the content. For example you can scale the text up or down, something I first built into sites about 15 years ago. You can change the text to white on black or black on white (yes, I also did that about 15 years ago). Oddly, you can convert the page to grayscale, removing all color information (it's not obvious how to turn that off, so it's still gray for me). You can toggle "alternate navigation," which just puts a big box around items that have keyboard focus (the site benefits since it wrongly uses outline:none). There is an option called "Speed control" which may adjust the rate at which its carousel/slider changes. There is an option to "Block blinking," though its affect was not immediately apparent to me.

I'm not sure that the patent would withstand scrutiny from someone who has worked in web accessibility. Some of the ideas outline, while not implemented in the tool on its own site, seem to lean on existing technologies that themselves are subsumed within patents. For example, one of the figures in the patent shows how optical character recognition (OCR) can be used to convert the text in an image into text that can be passed along to the user (figures 7a and 7b).

The Takeaway

As always with what feel like frivolous patents, I fear that they can be used to block truly useful and innovative solutions from coming to market. In this case, I worry that the already poor state of accessibility on the web could be stifled if the patent owners try to exercise any claims against those of us who've been doing accessibility work for years.

Keep the Focus Outline

This animated GIF is a screen capture of cycling through every interactive element (mostly links) on the page using just the tab key. You'll note that in all but one case, the only indication of any change is in the lower left in the browser's status bar where it shows the URL of the destination link. The URLs ending in a "#" are the booking options.

Today's rant is inspired by all the gushing over Virgin America's new web site — just because it's responsive.

To be fair to Virgin America, making its site responsive is a huge win for users whose primary method of booking is via a smartphone or tablet (or, god forbid, phablet or tablone). Its new site, however, is a huge step backward for users who rely on the keyboard as their primary method of interaction.

Virgin America's CSS has a style to identify anchors with focus (yes, there are other elements that should get focus, but I am looking at just the most basic support): a:focus {outline: thin dotted;}

What's so frustrating is that the useful style is then overridden with this harmful declaration: a:focus {outline: none;} This override greatly decreases the usability and accessibility of the site. Unfortunately, this practice is still common on many more sites across the web.

As a web developer, one of the simplest accessibility tests you can do is unplug your mouse. Two quick things to review as part of that: Can you interact with all controls with only the keyboard? Can you tell which item has focus?

Even if you aren't motivated to run that simple test from an overriding sense of being nice to your users, there's a legal concern here. As I wrote last week, the U.S. Department of Justice held H&R block accountable to Web Content Accessibility Guidelines 2.0 Level A and AA Success Criteria. That means there is case law for making your consumer-facing site comply or face penalties.

By excluding focus styles, Virgin America is running afoul of one of the AA Requirement 2.4.7:

2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA)

In short, if your site doesn't make interaction elements obvious when accessed via keyboard, not only are you hurting users, you're opening yourself up to litigation.

Further Reading

Again, this isn't a new issue. It even has its own mini-site at OutlineNone.com, which offers these handy links:

• http://www.456bereastreet.com/archive/200905/do_not_remove_the_outline_from_links_and_form_controls/
• http://webaim.org/blog/plague-of-outline-0/
• Web Content Accessibility Guidelines (WCAG) 2.0 (2.4.7)
• Failure of Success Criterion 2.4.7 due to styling element outlines and borders in a way that removes or renders non-visible the visual focus indicator

To add another, this article, When Do Elements Take the Focus?, might be handy to understand just when you can expect to see :focus styles get applied by a browser.

Related

In March I wrote about how Google removed underlines from search result links. My concern there was that web developers might follow suit. Between removing keyboard focus indicators and underlines from links, I am amazed that developers do so much to make the core interaction element of the web essentially hidden to so many users. I am reproducing the list of related links here as they are relevant to the overall issue of keeping links usable:

• NoCoffee – Vision Simulator for Chrome (added March 25, 2014).
• WebAIM Color Contrast Checker.
• Juicy Studio Luminosity Colour Contrast Ratio Analyser.
• Contrast Ratio by Lea Verou.
• Color Contrast Analyzer Chrome plug-in.
• Use Adobe Photoshop proofing features to simulate color blindness.
• G183: Using a contrast ratio of 3:1 with surrounding text and providing additional visual cues on focus for links or controls where color alone is used to identify them
  • Links with a 3:1 contrast ratio with surrounding text, which also shows 26 web safe colors to use with black or white text.
• F73: Failure of Success Criterion 1.4.1 due to creating links that are not visually evident without color vision
• Making Accessible Links: 15 Golden Rules For Developers at SitePoint (note rule 11), February 20, 2014.
• To Underline or Not Underline Links, March 9, 2012.
• Keep the Underline at WebAxe, April 14, 2013.
• Do Links Need Underlines? by Jared Spool, July 5, 2006.

My Efforts to Reach Virgin America (so far)

I may have contacted Virgin America on Twitter once. Or Twice. Or three times. Perhaps even a fourth time. And filed a bug with WebCompat.com. And left a comment at Wired's article. I've embedded the tweets below so you an retweet if you are as whiny as I.

Hey @VirginAmerica, to help you fix your lack of keyboard access, I left a bug report for you at @webcompat: webcompat/web-bugs/issues/141

— Adrian Roselli (@aardrian) June 18, 2014

Hey @VirginAmerica, I left a comment about your lack of keyboard access at that Wired gush-piece: http://t.co/9RAjaLcAdS Just trying to help

— Adrian Roselli (@aardrian) June 17, 2014

Seriously, @VirginAmerica, just go into main.css (https://t.co/E1Jh0qSu74) and *at least* delete this: a:focus{outline:none} 2 minutes.

— Adrian Roselli (@aardrian) June 16, 2014

Useless for keyboard users. RT @RWD: […], so I missed that the new responsive @VirginAmerica site went live! http://t.co/RM1tikjo14

— Adrian Roselli (@aardrian) June 16, 2014

Update: June 27, 2014

On December 12, 2013 a rule became effective from the U.S. Department of Transportation (DOT) titled Nondiscrimination on the Basis of Disability in Air Travel: Accessibility of Web Sites and Automated Kiosks at U.S. Airports. That links points to the following section on accessibility:

Finally, we proposed a tiered implementation approach in which the WCAG 2.0 standard at Level A and AA would apply to (1) a new or completely redesigned primary Web site brought online 180 or more days after the effective date of the final rule; […]

As keyboard accessibility is one of the requirements of WCAG AA compliance, Virgin America's new site does not honor this rule. However, if the Virgin site officially launched before June 10, 2014, then it squeaks by on a date technicality.

More information on the implications of the law are in the post New accessibility rules coming to airline websites. Are you ready?

Update: July 21

It took just over a month, but Virgin America responded to me:

@aardrian Thanks for your feedback on the #VXnewlook Please follow + DM if you'd like to share more.

— Virgin America (@VirginAmerica) July 21, 2014

I don't see any reason to follow and/or direct message to share more information. I have this blog post, which I've linked repeatedly. I think that's plenty. I responded and asked if or when the issue would be fixed, but I've been met with silence. Perhaps in another month I'll hear more.

In the meantime, given the amount of action the below tweet of mine has gotten, I know I am not alone in thinking that disabling the focus outline is generally a bad idea:

Use this ONE WEIRD TRICK to make your sites keyboard friendly: Delete this: :focus {outline: none}

— Adrian Roselli (@aardrian) July 17, 2014

Update: October 15, 2014 — Screen Reader Walk-Through

Marcy Sutton, at the JSConf, provided a walk-through of the Virgin America web site experience using a screen reader. It does a great job of showing what a terrible experience this site has created. I've embedded it below, bracketed to the relevant part of her talk, or you can view it directly on YouTube (starting at 0:20).

Update: October 23, 2014

Here is a video of the screen reader walk-through, pulled from the latest version of Marcy Sutton's slides on Angular Accessibility:

Verizon Using Disabilities to Fight Net Neutrality

On Friday, Mother Jones reported that it has three sources saying that Verizon lobbyists are making a case on Capitol Hill that net neutrality harms those with disabilities. From Mother Jones:

Three Hill sources tell Mother Jones that Verizon lobbyists have cited the needs of blind, deaf, and disabled people to try to convince congressional staffers and their bosses to get on board with the fast lane idea. But groups representing disabled Americans, including the National Association of the Deaf, the National Federation of the Blind, and the American Association of People with Disabilities are not advocating for this plan. Mark Perriello, the president and CEO of the AAPD, says that this is the "first time" he has heard "these specific talking points."

In the absence of seeing the language Verizon is using, I can only go on what Mother Jones reported (other news outlets covering this are linking back to Mother Jones). Given the amount of cash ISPs like Verizon are lobbying to kill net neutrality ($19 million in the first quarter of 2014 alone), I don't consider this report to be far-fetched. Certainly Verizon is unlikely to make this argument in the open — there will be a backlash when no proof is offered and disability rights groups shoot it down (as has been happening just on these rumors).

It seems to me it is in the best interest of net neutrality to react as if this report is true. Further, it seems like a good idea to make it clear disabilities cannot be used as a pawn in some armchair morality action, no matter how well elected officials feel it may poll.

I was pretty quick to jump on this on Twitter, mostly out of anger, and given the retweets and favorites from my meager following (particularly from the accessibility community) I suspect I am not alone. Feel free to retweet it to your followers (or write your own):

Hey @FCC @TomWheelerFCC @BarackObama, @Verizon is lying. #NetNeutrality will not harm disabled. Ask for proof. http://t.co/gWJyPLnilJ

— Adrian Roselli (@aardrian) June 13, 2014

A quick Google search (or use your own search terms) will net you many results from people who think Verizon's reported argument is absurd (Won't somebody please think of the childrendisabled?).

I don't think my blog post, which ranks nowhere on Verizon's radar, will do much to sway its nor the FCC's opinion, but I do want to make sure I add to the growing chorus of people publicly denouncing something Verizon is arguing behind closed doors.

Related

In April I wrote a post about net neutrality (We Need to Raise a Stink about Net Neutrality) where I asked people to tweet to Tom Wheeler and the FCC. In it I include plenty of references and arguments, but this video from Last Week Tonight with John Oliver (which I amended to my original post) does a better job of explaining net neutrality:

As John Oliver suggests, you can leave our own comments at the FCC site. As of a week ago there were 49,206 comments. As of this writing there are 115,213 comments. Only the most recent 10,000 comments are available to be viewed, which I cannot explain. Further, if you want to consider accessibility, as Verizon seemingly does, you may want to also ask the electronically filed responses be made available in a format other than PDF.

Update: July 25, 2014

Perhaps in reaction to the Verizon rumors, or just because the cause makes sense, on July 18 five different organizations related to accessibility filed their own joint comments with the FCC. The organizations are: Telecommunications for the Deaf and Hard of Hearing, Inc. (TDI), the National Association of the Deaf (NAD), the Hearing Loss Association of America (HLAA), the Deaf and Hard of Hearing Consumer Advocacy Network (DHHCAN)), and the Rehabilitation Engineering Research Center on Telecommunications Access (RERC-TA) along with Professor Clayton Lewis. Together they filed a brief, which you may read online (and which I have copied locally as I suspect this URL will be allowed to rot by the FCC), outlining their support of net neutrality. An excerpt:

[We] seek to promote equal access for the 48 million Americans who are deaf, hard of hearing, late-deafened, deaf-blind, or deaf with mobility or cognitive disabilities to the informational, educational, cultural, and societal opportunities afforded by the telecommunications revolution.

The letter outlines six arguments in particular, with far more detail in its sixteen pages:

1. Retaining and improving transparency rules will improve the ability of consumers who are deaf or hard of hearing to access the Internet on equal terms.
2. A no-blocking rule would help ensure the availability of accessible telecommunications services for consumers who are deaf or hard of hearing.
3. The Commission should bar paid prioritization while ensuring that Internet-based services and applications are accessible to consumers who are deaf or head of hearing.
4. Title II reclassification would afford the Commission additional flexibility to ensure that broadband services are accessible, and the Commission should exclude accessibility-related Title II provisions from forbearance if it reclassifies.
5. The Commission should ensure that the enterprise services and premise operator exceptions avoid facilitating illegal discrimination against people who are deaf or hard of hearing.
6. The Commission should ensure that the use of data caps do not result in discrimination against people who are deaf or hard of hearing.

The same day, the American Association of People with Disabilities and the National Council on Independent Living also filed their own joint letter with the FCC (also available from a non-FCC URL). In addition to an open internet, the letter argues for an ombudsman:

Over the past few years, Congress shifted the focus of universal service from mere availability to adoption and utilization. […] This important review of Open Internet policy provides an opportunity to ensure that people with disabilities have full and open access to broadband communications and enjoy the important consumer protections mentioned in our comments. […] An Ombudsman Office Can Monitor and Report on Access Issues Associated with Consumers with Disabilities

Ars covered the latter filing in its Tuesday post, "Deaf advocacy groups to Verizon: Don’t kill net neutrality on our behalf."

Accessibility Regulation Confusion from U.S. Government

There has been some activity lately from the U.S. federal government related to accessibility requirements for web sites. Unfortunately, that activity is sending a mixed message to many burdened with making a case for accessibility compliance in the private sector.

Good News

The U.S. Department of Justice (DoJ) made news in the accessibility community back in March by issuing a Consent Decree in a case with H&R Block requiring H&R Block to follow the Web Content Accessibility Guidelines (WCAG) 2.0. From the DoJ press release:

On Dec. 11, 2013, the Civil Rights Division and the U.S. Attorney’s Office for the District of Massachusetts filed a complaint in intervention in the lawsuit National Federal [sic] of the Blind (NFB) et al. v. HRB Digital LLC et al. to enforce Title III of the ADA [Americans with Disabilities Act]. […]

[…] The recognized international industry standards for web accessibility, known as the Web Content Accessibility Guidelines (WCAG) 2.0, can be found online and are freely available to help companies ensure that individuals with disabilities can fully and equally enjoy their web-based goods and services.

Under the terms of the five year decree, H&R Block’s website, tax filing utility and mobile apps will conform to the Level AA Success Criteria of the WCAG 2.0. […] H&R Block will also pay $45,000 to the two individual plaintiffs, and a $55,000 civil penalty.

Essentially the DoJ stepped into a lawsuit, identified an accepted standard to follow, and put some teeth in its action in the form of a financial penalty (both in cash and H&R Block's cost to rebuild its offerings). For those who champion accessibility, this is a win.

It's not the first. Back in 2012 the DoJ filed a Statement of Interest in a battle between Netflix (never mind that it's in a PDF) and the National Association of the Deaf that the absence of closed captioning violates the ADA. Earlier this year it also filed a Statement of Interest in a case against Lucky Brand Jeans (another PDF) for its inaccessible customer-facing credit card swipe machines (which probably inhabit far more stores than just Lucky's).

The DoJ has effectively been enforcing ADA laws for private entities, not just state and local governments. This is A Good Thing™

Bad News

Let's ignore the fact that the DoJ can't get the name of the National Federation of the Blind correct in a press release, or that the ADA site provides Statements of Interest from the DoJ as PDF files (you can learn some more about PDF accessibility at Denis Boudreau's a11y Tips site).

The Laws

The DoJ was expected to release a set of legally binding standards for web site accessibility back in April. That deadline flew by with hardly a word from the DoJ. Instead, buried in a Unified Agenda (a catch-all planning document), The DoJ casually mentioned that it's been delayed until March of 2015. You can credit Seyfarth Shaw LLP for catching that one.

As the Law Office of Lainey Feingold notes, this has been happening for years:

The web regulations have been pending since July 26, 2010 when the DOJ issued its Advanced Notice of Proposed Rule Making (ANPRM). The public comment period ended on January 24, 2011. Ever since then, the DOJ has been announcing deadlines for the next step — and then moving those deadlines as the target date approaches.

Enforcement

The H&R Block Consent Decree has some dates associated with adhering to the ruling. One of them (14.d) has come and gone:

14. Web Accessibility Policy [underline theirs, not mine]: By June 1, 2014, H&R Block shall adopt and implement a Web Accessibility Policy consistent with the attachment at Exhibit A and as approved by the Private Plaintiffs and the United States. By June 1, 2014, H&R Block shall: […]
    4. make publicly available and directly link from the www.hrblock.com homepage, a statement of H&R Block’s policy to ensure that persons with disabilities have full and equal enjoyment of the goods, services, facilities, privileges, advantages, and accommodations of H&R Block, through www.hrblock.com, its mobile applications, and its Online Tax Preparation Product; […]

When I visit the H&R Block home page, I see no link or content related to accessibility, disabilities, nor the ADA (if I am wrong, please correct me). I even made an archived version from the Wayback Machine so you can see it in case H&R Block changes it tomorrow (see how you can make your own).

Granted, that requirement is only a week overdue, but given that the DoJ is four years overdue on issuing regulations, one could argue that deadlines don't carry much weight with the DoJ.

Just Setting a Good Example

The DoJ site itself is not exactly a shining beacon of accessibility. From the odd image map on the logo (really, one image, two links to the same location?) to text as images, it could use some help. If you head over to the DoJ Acccessibility Information page you will see it states that the DoJ is committed to provide its content in accordance with Section 508 of the Rehabilitation Act.

If you've been working in web accessibility, then you may be aware of the government web site devoted to Section 508, which requires that Federal agencies’ electronic and information technology is accessible to people with disabilities, and which is intended to be used by federal employees: Section508.gov

As I challenged on Twitter, try using it with your keyboard. Go ahead. Just try it.

For the more technical among my readers, here's an example of the CSS declarations of agony (files linked in this tweet):

WTF? section508•gov CSS: img, a img { border: none; outline: none; } :focus { outline: 0; } http://t.co/EKk1JvkC9D http://t.co/svCNTYifpx

— Adrian Roselli (@aardrian) June 8, 2014

For added fun, find the Skip link and then see where it takes you.

The government body in charge of creating rules for making sites accessible is built based on the requirements of a federal site that itself is a complete cluster. It may, in fact, be a brilliant parody site showing government workers how not to build a compliant site.

Or it might really be the best they can do.

What You Should Do

Keep coding (or start coding) your sites to meet Web Content Accessibility Guidelines 2.0 Level A and AA Success Criteria. This is the requirement the DoJ put in its ruling against H&R Block, the most recent example we have of where the federal government is defining a standard.

And then stop worrying. As WebAIM notes, fear of litigation isn't the best reason to make a site accessible. You should do it because it's the right thing to do. Of course, in my HTML5 Developer Conference talk, I argue that making accessibility all about you (slide 13) is probably a more effective means of getting developers to implement, but I leave that decision up to your personal level of narcissism.

Related

• Assets, the accessible, Bootstrap-based development framework from the federal government (really from the Centers for Medicare & Medicaid Services).

Update: June 9, 2014

Read my post about Assets, the U.S. government framework based on Bootstrap 3, and PayPal's accessibility plug-in, which promises to make your existing Bootstrap implementation accessible: Accessible Bootstrap Frameworks

Update: June 25, 2014

In a release last week from the National Federation of the Blind (NFB), the NFB and a blind business owner reached an agreement with the Small Business Administration because its web site violated Section 508 (read a brief from the law firm representing the NFB). This is newsworthy for two reasons:

• The SBA is a government agency and is being held to the only current federal law pertaining to web site accessibility, effectively stating the government has to follow its own rules.
• The Section508.gov site, the one housing the rules to which the SBA is being held, doesn't follow those very rules, as I noted above.

I am struggling to find a way to describe how absurd this is. I am open to suggestions.