Monday, January 26, 2015

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]

« 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»…

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.


Saturday, January 24, 2015

CSS Bookmarklets for Testing and Fixing

Animated image showing the Pinterest site and its infuriating blocking overlay, which is removed with the bookmarklet below.

I regularly have to test sites in development, review some third-party site, or just use a site in my day-to-day time wasting (and banking) rituals. I've relied on viewing the page's source or popping into my browser's dev tools to find a missing element, copy un-transformed text, check for inline styles, and so on. Typically I am relying on CSS and not JavaScript, as that is where I excel.

I got a little annoyed doing that all the time, and this morning I had reason to visit Pinterest and mostly lost my marbles at its login overlay and refusal to scroll. So I channeled that rage and taught myself to build a bookmarklet to dump that Pinterest overlay crap. I have created a few more that include my standard styles for testing, styles that perhaps you (dear reader) will find useful.

I'll have basic instructions below showing you how you can build your own and/or modify the ones I've provided.

Bookmarklets You May Steal

Note that I say may steal. That's me giving you permission. Note that I call them bookmarklets. That's me not giving into the term favelets or whatever HotJava called them (was it hot links?).

Restore Link Underlines

You know what's cool? Removing link underlines and providing terrible link color contrast. It's so cool, in fact, that I want to make those sites less cool. As well as usable. Read my rant on this.

This bookmarklet restores link underlines across the board. Every link. After all, if you want the link underlines, you probably don't care that the designer would freak out at the noise it adds to the page.

javascript:(function(){var a=document.createElement('style'),b;document.head.appendChild(a);b=a.sheet;b.insertRule('a[href]{text-decoration:underline !important}',0);})()

Restore Focus Outlines (or Fix Virgin America)

Just as cool as removing link underlines is removing the outline on elements that get focus as you tab through a page. After all, if you've hidden the links, why not hide when the links are selected. Virgin America tends to agree.

This bookmarklet not only restores the outline (in the form of the two-pixel dotted blue line), but also adds a drop shadow for those cases where the blue is lost against the surrounding colors.

javascript:(function(){var a=document.createElement('style'),b;document.head.appendChild(a);b=a.sheet;b.insertRule('*:focus{outline:2px dotted #00f !important;box-shadow: 0 0 2em rgba(0,0,0,.75) !important;}',0);})()

Find Inline Styles

Over at Algonquin Studios we have worked in the content management space for, well, since the dawn of content management systems. One of the risks of using a CMS is that your authors may accidentally (or intentionally) embed styles whether by pasting rich-text from elsewhere or by features built into the WYSIWYG editor within the tool. This is most common with text styles.

Sometimes it is faster to just find the elements that have a style attribute on them, as that's the first clue that there may be a conflict that needs to be corrected. This option will find any of those elements and give them a yellow background along with a two-pixel dotted red border (like the Windows "hot dog" theme from the previous century).

javascript:(function(){var a=document.createElement('style'),b;document.head.appendChild(a);b=a.sheet;b.insertRule('*[style]{border:2px dotted #f00 !important;background-color:#ff0 !important;}',0);})()

Find Duplicate ARIA Roles

In ARIA, there are a few instances of roles that should only appear once on a page. These landmark roles are banner, contentinfo, and main. In addition, the W3C HTML5.1 specification notes that there must be only one main element per page.

This bookmarklet will identify any additional instances of any of the once-per-page items above. If you know enough about coding ARIA, then you probably know enough about finding which of the roles/elements is on repeat. Offending items will have a two-pixel dotted red border and red background.

javascript:(function(){var a=document.createElement('style'),b;document.head.appendChild(a);b=a.sheet;b.insertRule('*[role=main]:nth-of-type(n+2),*[role=banner]:nth-of-type(n+2),*[role=contentinfo]:nth-of-type(n+2),main:nth-of-type(n+2){border:2px dotted #f00 !important;background-color:#f00;}',0);})()

Find Missing Alt Attributes

An image without an alt attribute can be anything from an annoyance to a barrier to those using assistive technologies. Being able to quickly identify those images on a page can save time when figuring where to focus your efforts.

This bookmarklet will find those images and give them a two-pixel dotted red border. Note that it only looks for images with a missing alt, as a blank alt attribute is often perfectly valid.

javascript:(function(){var a=document.createElement('style'),b;document.head.appendChild(a);b=a.sheet;b.insertRule('img:not([alt]){border:2px dotted #f00 !important;background-color:#f00;}',0);})()

Reset Text Size (Added January 30)

Sadly, it is not uncommon for sites to reset the default size of the text on the page. Too often that is done to satisfy a design change. One site where I find the text too small to read comfortably, or at all, is Daring Fireball. I know I am not the only one to feel this way.

This bookmarklet will resize the text on the body element to 100%, ideally conforming to whatever your default browser preferences are. It works great on Daring Fireball, but could easily be overridden on sites that set the text size in other ways and/or on other elements.

javascript:(function(){var a=document.createElement('style'),b;document.head.appendChild(a);b=a.sheet;b.insertRule('body{font-size:100% !important;}',0);})()

Fix Pinterest

When you visit Pinterest without a Pinterest account, or without being logged in, you are prompted to sign up/in by a terrible overlay. In addition, the page won't scroll past a certain point. This annoys me. So I made a bookmarklet to remove the two overlays and re-enable scrolling. You can test it on my abandoned Pinterest page.

javascript:(function(){var a=document.createElement('style'),b;document.head.appendChild(a);b=a.sheet;b.insertRule('.Modal, .UnauthBanner {display: none !important;}',0);b.insertRule('.hasFooter.Grid.Module{overflow-y:visible !important;}',0);b.insertRule('.noScroll{overflow:auto !important;}',0);})()

Make/Modify Your Own Bookmarklet

The Virgin America site is made usable for those who navigate with a keyboard by restoring link underlines and adding focus styles to elements.

If you look at the code chunks above, you'll see I am doing the same thing over and over. I am using the JavaScript CSSStyleSheet.insertRule() method to insert a new style rule into the page's stylesheet. Not only does the Mozilla Developer Network have a great overview with sample code, but David Walsh shows similar code with some minor tweaks.

This approach allows me to leverage my CSS skills to write selectors to find and style elements on the page. Since CSS has so many powerful selectors, I find this easier to quickly repurpose. In addition to adding a new style, I always include !important with each so that it will override any inline styles.

If you are writing a function from scratch, make sure you minify it to take up less space (you may bump into character limits for a bookmarklet). Pre-pend javascript: and make it the href value of a link and you are done.

Here is a sample block of code you can use with the styles rendered in bold so you can replace them with your favorite selector. In this example I have two style rules so you can see how to add additional selectors.

javascript:(function(){var a=document.createElement('style'),b;document.head.appendChild(a);b=a.sheet;b.insertRule("a[href]{text-decoration:underline !important}",0);b.insertRule("*[style]{border:2px dotted #f00 !important;background-color:#f00;}",0);})()

And with that you should be off to the races.


Links to my posts referenced above:

Sunday, January 11, 2015

On Use of the Lang Attribute

HTML5 Logo with character for Chinese number 5.

Way back in October I noticed this WHATWG HTML bug (26942) where someone asked why do these examples of <html> lack the lang attribute? I thought the answer from Hixie was a bit dismissive and not based on any data or real-world benefits of use, particularly in the context of screen readers:

Why not? Realistically, few people include it. It just means the language is unknown.

At the time, I could not get the latest archive to download from (though that has changed, see below), so I fell back to asking for help on why the lang attribute is valuable.

How the lang Attribute on <html> Is Used

I got lots of good bits of feedback, which I collected into a Storify. I've distilled all that great information to these key points:

  • VoiceOver on iOS uses the attribute to auto-switche voices.
  • VoiceOver can speak a particular language using a different accent when specified.
  • Leaving out the lang attribute may require the user to manually switch to the correct language for proper pronunciation.
  • JAWS uses it to load the correct phonetic engine / phonologic dictionary — Handy for sites with multiple languages.
  • NVDA (Windows) uses it in the same way as VoiceOver and JAWS.
  • When used in HTML that is used to form an ePub or Apple iBooks document, it affects how VoiceOver will read the book.
  • Firefox, IE10, and Safari (as of a year ago) only support CSS hyphens: auto when the lang attribute is set (not from Twitter; source).

In the absence of setting a lang attribute on the <html> element, screen readers will fall back to the user's default system setting (barring any custom overrides) when speaking content.

How Many Pages Use lang

On January 8, (from a W3C Community Group) posted its latest archive (which did not error on download, woo!). It consists of the HTML from 87,000 web pages.

I pulled down the 780MB file and re-taught myself the skills necessary to parse the files. For those who are regular expression geniuses, you are welcome to suggest an alternate approach, but I used the following pattern to return all the <html> elements: <html([^>]+)>. It fails for any <html> with no attributes at all, but for what I am doing that's ok.

Of the 84,054 pages I parsed (I excluded XML, ISO files, and so on), I found that 39,433 use the lang attribute on the <html> element. That's just about 47% (46.914% if I understand significant digits correctly).

What that tells me is that instead of the case being that few people include it, nearly half the web includes it.

There are 12,672 instances of xml:lang, though at a quick scan they appear alongside lang. If anyone with better regex skills would like to help me further parse, please let me know.

Why You Should Use the lang Attribute on the <html> Element


By using lang, you get the benefits of hyphen support in your (modern) browser that you otherwise would not get (assuming you use hyphens: auto in your CSS).


At the very least, lang is a benefit for screen reader users, particularly when your users don't have the same primary language as your site. It allows proper pronunciation and inflection when the page is spoken.

WCAG Compliance

Including the lang is a Level A requirement of the Web Content Accessibility Guidelines 2.0 (specifically item 3.1.1 Language of Page). Technique H57 identifies the lang attribute specifically.


The W3C Internationalization (I18n) Activity has a great Q&A on why you should use lang, which was updated less than two months ago. I'll reprint the start of the answer, but there is far more detail and I strongly recommend you go read it.

Identifying the language of your content allows you to automatically do a number of things, from changing the look and behavior of a page, to extracting information, to changing the way that an application works. Some of language applications work at the level of the document as a whole, some work on appropriately labeled document fragments.

We list here a few of the ways that language information is useful at the moment, however, as specifications and browsers evolve in the future there could be numerous additional applications for language information.

Interesting Aside

If you go to the WHATWG HTML5 specification today and view the page source, you'll see the following language declaration in the code:

<html class=split data-revision="$Revision: 8877 $" lang=en-GB-x-hixie>

Not to be outdone, the W3C HTML5 spec has the same language declaration.

If anybody has the en-GB-x-hixie phonologic dictionary in his or her screen reader, I'd love to hear it.

While technically allowed (the -x puts it in the private use sub-tag category), it's bad form:

Private-use subtags do not appear in the subtag registry, and are chosen and maintained by private agreement amongst parties.

Because these subtags are only meaningful within private agreements and cannot be used interoperably across the Web, they should be used with great care, and avoided whenever possible.

Update: January 1, 2015

For what it's worth, I've filed bugs against the W3C HTML5 spec and the WHATWG HTML5 spec.

Thursday, January 1, 2015

Announcing My Ring Warmer App

Animation showing the Ring Warmer in action.
Animation showing the Ring Warmer in action.

If you have to wear a ring, then perhaps you have experienced the discomfort of putting a cold ring on your finger (maybe in the morning in a cold house). I decided that I could do something about that using the only tool in the modern developer's toolbox — the smartphone app.

I'm kicking off the new year by announcing that my Ring Warmer app is done. Well, it's a web app. Actually, it's just a web page. Living as nothing more than a block of code at CodePen. Regardless, I started this in late 2012 and then mostly forgot about it, so I'm thrilled to call it done.

The opening image is an animated GIF that shows how one might use the Ring Warmer app. I've also embedded the same animation as an Instagram video (or view it directly on Instagram):

My ring warmer app is finally ready for release.

A video posted by Adrian R (@aardrian) on

The idea here is that you can choose a ring size and a warmth level, place your ring in the designated spot, and wait patiently for it to work its magic.

The idea is, of course, absurd.

In the strictest sense, it can work. At the lowest setting (warm), only the red LEDs will light up, carrying one-third of the total heat a pixel can produce. As you move to the highest setting (hottest), all the LEDs are lit to generate white, so each pixel is producing its maximum heat as the red, green, and blue LEDs are all lit.

Of course, the amount of heat this carries is negligible. You will transfer more heat to the ring from the warming battery than from the pixels. The ring itself might not get very warm unless you also fire up the radio antenna (I left that feature out as a courtesy).

Now that I've gotten as much pranking out of this fake app as possible, I figured I'd at least write it up a bit.

Very simply, I use a border radius with some box shadows to make the glowing ring. Then I drop the white glowing dot (using box shadows and border radius) onto one edge and rotate the entire thing in perpetuity. It's a mess of mixed sizing units, questionable animation syntax, and useless elements.

Then I made a form so you can change the ring size and the temperature. The ring size isn't matched to any real measurements, except in Chrome on my Samsung Galaxy S4 the default size matches my ring. All sizing after that is based on ems, so it doesn't scale like a real ring. The temperature change is nothing more than colors with CSS transitions and some JavaScript that sets explicit styles instead of classes. In other words, it's a terrible idea to copy this code.

Regardless, here's the pen in action:

See the Pen Ring effects by Adrian Roselli (@aardrian) on CodePen.

This will not be available in any app store. You can load the pen in full screen view to trick your friends if you are that bored.

Sunday, December 21, 2014

Don't Tweet Pictures of Text

Ironic tweet of a screen capture of a tweet saying 'these pictures of tweets drive me insane.'

Earlier this week M.G. Siegler posted Hacking the Tweet Stream at Medium, where he describes the trend of posting images of text to do an end-run around Twitter's character limits. His post quickly changes from descriptive to prescriptive, advocating for this behavior to bypass what he sees as a limitation of Twitter.

Christian Heilmann quickly responded to note what a bad idea this is (my words) in his post Great publishing works with the medium, not against it.

Reasons Not to Do It

Christian covered a few reasons why you shouldn't rely on images, which I am including here from his Medium post:

  • Maybe they are blind and can not see text in an image
  • Maybe they are on a tiny device and whilst the font here is readable the text in a small JPG with artifacts is less so.
  • Maybe they are on an unreliable connection and the image hasn’t loaded yet
  • Maybe they have a mis-configured ad-blocker that is overzealous with its blocking

Let me add some more:

  • Maybe the tweet isn't in the reader's native language and he/she wants to translate it.
  • Maybe the text contrast is too low for a small screen or sunlit screen.
  • Maybe the user is bumping against data caps and has to pay for each extra byte.
  • Maybe the user is on a feature phone (think of users outside of North America and Europe).
  • Maybe the user relies on searching the text to find relevant tweets. There is an opportunity cost to not using text.

This isn't an accessibility issue, it's a usability issue and an engagement risk. When you factor connection quality, data plan caps, image quality, contrast, potential image blocking, and search failures, this seems like a terrible method to get your important message in front of people.

Better Options

There are some easy ways to get around this that are native to the medium. I originally offered three of these in October, so I'll include them here with more.

  • Link to the source. Most of these tweets are screenshots from web pages, so link to them.
  • Use Tumblr or a similar platform. Twitter Cards will embed the image into the tweet (except for Instagram).
  • Tweet your own text version or abstract in a follow-up tweet.
  • When you are retweeting someone else, include an abstract or link to the source.
  • Ask the original tweeter for the text or the URL of the source.
  • Use a tool meant for this purpose, like Easy Chirp (an example using a useless tweet from the CDC).
  • Write less. Get to the point, focus on the message, write for the medium.

Now for the Expected Rant

I think this is too easy to dismiss unless there are examples and context. I think it's important to also show that even people who work in UX struggle with it, as I too have done before.

Media Outlets Are Getting Lazy

It seems more and more news outlets are trying this out. In so doing, they are leaving some readers in the dust. More importantly, the reporters who do this are leaving their employers in the dust by not linking back to the news site.

I even asked politely for a non-image version, maybe a link to a release or news story. No response.

I asked the same here, and again no response.

Same situation, different news outlet, still requested a plain text link. At least this tweet has an abstract, though no link to the source.

People Who Should Know Better

While these examples are far from the only three who engage in picture-only-tweets, they each came up in my timeline recently and none included anything helpful for users who cannot see the image (whether by vision impairments or technology issues). These are in reverse-chronological order.

Jared Spool, from his personal account, tweeted a screen shot that had already made the rounds, and didn't take any opportunity to add any value. Of course I got snarky, but when this image first appeared at least I asked for the source URL and got it. It's not that hard.

This tweet from Zeldman is an image of browser stats from a site (probably one of his). That's it, just an image. No descriptive text, no context (though the included text might make it seem NSFW). As I demonstrated in a follow-up tweet, you can fit all the information into a tweet as plain text.

Luke Wroblewski ran a series of tweets which were nothing but images, though he included a barely-legible URL at the bottom of each image (itself a gray URL that is so small and light it's terribly difficult to tell a 1 from an l). Why would he do this when the tweets had more than enough characters for the URL as well? Even the image confused some users. I opted to retweet some of them with the links restored and context added.

I am of the opinion that if your image-only tweets had text or links to sources, readers wouldn't need to make a Storify of them, manually creating the URLs on your behalf (and noting that now the embedded-in-image links are clickable).

Given the influence these names have on web developers and the industry in general (497,000 followers combined), and given Spool's position in the UX community, the recent push from Zeldman for accessibility on the web, and Wroblewski's constant push for better UX on mobile, their own behavior simply validates laziness when they could, rather should, be examples of useful, inclusive behavior.

Update: January 2, 2105

Steve Faulkner provides a less ranty collection of tips: Notes on providing alt text for twitter images. In it he outlines three of the techniques I do above, noting that by itself Twitter doesn't include any of the elements nor attributes that would enable accessible images otherwise.

Monday, December 15, 2014

20 Years Since Netscape Navigator 1.0

Screen shot of the Netscape 1.0N browser information page.
Screen shot of the Netscape 1.0N browser information page.

The creepy pulsing N. Twenty years ago today, Netscape Communications Corporation released version 1.0 of Navigator, the browser that became synonymous with the web (for the general public). Well, really the general public (and most developers) referred to the browser as Netscape, not by its real name, Navigator.

The Navigator broken image icon. Based on Mosaic, Navigator quickly replaced the now not-so-cool Mosaic on my work and personal computer, and made Lynx look downright boring. It also presented the world with the creepy pulsing N, which was thankfully replaced pretty quickly. The first release also provided us with the familiar broken image icon that would persist until Internet Explorer's ubiquity usurped it.

Navigator persisted for more than thirteen years after that release, through the ups and downs of the oddly-named browser wars, until it was finally scuttled by its last owner, AOL, on December 28, 2007. AOL released security updates until March 1, 2008, marking the last update Navigator would ever see.

In honor of the browser where I cut my teeth learning all about the web, I grabbed the Navigator 1.0 release from the browser archive (Mac and Windows 16-bit only, sorry, and it's the 1.0N release) and installed it on a shaky WindowsXP virtual machine. Unsurprisingly, trying to surf anywhere with it was a mess. The browser pre-dated frames, cookies, HTML tables (support came in 1.1), JavaScript, and support for any of the robust features of HTTP.

Screen capture of Wikipedia in Netscape 1.0.
Screen capture of Wikipedia in Netscape 1.0.
Screen capture of Yahoo in Netscape 1.0.
Screen capture of Yahoo in Netscape 1.0.

Interestingly, Navigator was first released as free software, only to walk it back a couple months later. The Wikipedia post spends a couple sentences on this:

Netscape announced in its first press release (13 October 1994) that it would make Navigator available without charge to all non-commercial users, and beta versions of version 1.0 and 1.1 were indeed freely downloadable in November 1994 and March 1995, with the full version 1.0 available in December 1994. Netscape's initial corporate policy regarding Navigator is interesting, as it claimed that it would make Navigator freely available for non-commercial use in accordance with the notion that Internet software should be distributed for free.

However, within 2 months of that press release, Netscape apparently reversed its policy on who could freely obtain and use version 1.0 by only mentioning that educational and non-profit institutions could use version 1.0 at no charge.

If the history of browser is something you find interesting, Wikipedia has this handy timeline of web browsers dating back to 1990. On the plus side, this is an SVG file, so you can zoom in to read it. Eric Meyer has a more structured browser timeline, but it doesn't start until 1996.

Timeline of web browsers.svg
"Timeline of web browsers" by ADeveria - Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons.

Interestingly, I don't use Netscape Navigator (any release) at all anymore, but I do still fire up Lynx a few times a month.

Friday, December 5, 2014


Animated GIF showing the No CAPTCHA deciding you aren't a robot.

If you've got any stake in the wonderful world of spam bots, then you've probably heard about Google's CAPTCHA update, the No CAPTCHA reCAPTCHA. Essentially a user need only check a box and Google's ground-up pixie dust automagically knows whether or not to believe you. A video overview of the update:

Almost as soon as the announcement, people in the accessibility community spoke up stating it was completely broken, worked well, or worked no worse than the current option. To Google's credit, walking through the source code shows an effort was made to provide accessibility hooks.

At the very least it may prevent embarrassing mis-haps like the broken keyboard navigation at DigitalGov. At its worst it may appear that Google is turning a blind eye (pun intended) to accessibility as we've witnessed with its Web Components demos.

I am not an assistive technology (AT) user, so while I can fire up NVDA and try the form, I cannot truly experience it the way a day-to-day or power user would. Conveniently, both Patrick H. Lauke and Alastair Campbell made demos so that anyone can try it out for themselves (Patrick's demo, Alastair's demo).

I started to track the comments on Twitter in a Storify (and will continue to do so), but in the interest of providing a narrative, archiving the content pending the inevitable heat death of Storify, and having a simpler format, I am embedding the tweets and links here.

Video Samples

These three video examples from Patrick Lauke show the reCAPTCHA using three browser/AT combos:

  1. Windows 8.1, JAWS 16, Firefox.
  2. Windows 8.1, JAWS 16, Internet Explorer 11.
  3. Windows 8.1, NVDA, Firefox and Internet Explorer 11.

Articles / Posts

Derek Featherstone

Derek Featherstone turned around an accessibility review pretty quickly with On the Accessibility of Google’s No CAPTCHA and provided these results:

  1. We tested it without any assistive technology for simple keyboard use. Can I use the keyboard to check that checkbox, and can I see the keyboard focus to know where the cursor is? Yes, I can.
  2. We tested with a couple of screen readers (VoiceOver running on a Mac, Narrator on Windows 8.1, and NVDA on Windows 7). Does the checkbox get announced by the screen reader as a checkbox, even though it clearly is NOT a native checkbox? And does it work properly when checking off the checkbox using the keyboard by pressing the space bar or double-tapping on the touch screen? Yes, on both counts. Google added ARIA’s role="checkbox" to ensure that modern screen readers treat the span as a checkbox, and they allowed that span to take the focus using tabindex.
  3. We tested with Dragon NaturallySpeaking. Using Dragon, can someone look at the screen and say “Click checkbox” or “Click I’m not a robot” to effectively click the checkbox? Yes, on both counts.

Marco Zehe

Marco Zehe, who works on the Mozilla accessibility team, takes a different view in this post (in German) Warum die Zugänglichkeit von Googles neuer RECAPTCHA-Version kompletter Bullshit ist. In short, he notes it has all the code for accessibility, but in practice it doesn't quite work:

Während Googles neue Version von RECAPTCHA also rein vom Markup her die Voraussetzungen für Zugänglichkeit erfüllt, da dieses Kontrollfeld sowohl mit der Tastatur angesprungen werden kann als auch die richtigen Informationen an Screen Reader raus gibt, ist seine Zuverlässigkeit alles andere als gegeben, wenn man damit als Person mit einer Behinderung interagieren will.

Sina Bahram

Sina Bahram argues the CAPTCHA in general is a flawed premise (something with which Derek Featherstone agrees in his post) and so talks about the larger issues and how this reCAPTCHA implementation isn't necessarily any better, regardless of the accessibility improvements (embedded audio below, or you can listen to it directly at AudioBoom):

Edit (Dec. 7, 2014): Sina has posted a transcript of the audio.


The WebAIM mailing list also has a thread about the reCAPTCHA, some of which recaptures the commentary in the tweets following.

Twitter Conversation


No CAPTCHA so far seems better than reCAPTCHA, but appears to still be an accessibility barrier. The better approach still appears to be finding a way to avoid any CAPTCHA solution. I applaud Google's effort to improve the accessibility from the start, but it's clear it needs more testing — which is to be expected when rolling out such a dramatic change.


Update: December 7, 2014

Over at Web Axe, Dennis Lembree has shared his thoughts in the post Google’s No Captcha Shows Some Progress. He notes that No CAPTCHA fails with JAWS / Internet Explorer, requires JavaScript, and doesn't work on touch devices.

A deaf-blind user posted on WebAIM to note that No CAPTCHA doesn't work for him in either Firefox or IE11.