Web developer, writer, speaker. Co-founder of his company Algonquin Studios as well as evolt.org. Has co-written “Usability: The Site Speaks for Itself,” “Web Graphics for Non-Designers,” and “Web Professional's Handbook.”
The Paciello Group will be holding a full day of free webinars on Global Accessibility Awareness Day. That's 24 straight hours of talks, starting at midnight (GMT) on Wednesday, May 20 through through midnight (still GMT) on Thursday, May 21.
I'll be giving my world-renowned (not really, but at least it's world-traveled) talk Selfish Accessibility at 2:00AM GMT (10:00PM EDT on the night of Wednesday, May 20). I'm third in the queue and will already be following two great speakers. The abstract is posted on the Inclusive Design 24 site.
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.
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.
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.”
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.
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.
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
If you are a web pro then it is likely that you heard that Google's search results were going to change based on how mobile-friendly a site is (you probably heard a couple months ago even). This change took effect yesterday.
As with almost all things in the tech world that affect clients, the press hit yesterday as well, and today clients are looking for more information. Conveniently, our clients are golden as we went all-responsive years ago.
If you already built sites to be responsive, ideally mobile-first, then you needn't worry. Your clients have probably already noticed that the text "mobile-friendly" appears in front of the results for their sites in Google and have been comforted as a result.
If you have not built sites to be responsive, or have had no mobile strategy whatsoever, then you may be among those calling it, or seeing it referred to as, mobilegeddon. A terrible name that clearly comes from FUD (Fear, Uncertainty and Doubt).
If you are someone who relies on a firm to build and/or manage your site, then you should also beware the SEO snake oil salesman who may knock on your door and build on that very FUD to sell you things you don't need.
From Google Webmaster Central
For that latter two cases, I have pulled the first three points from Google's notes on the mobile-friendly (a much better term) update. I recommend reading the whole thing, of course.
1. Will desktop and/or tablet ranking also be affected by this change?
No, this update has no effect on searches from tablets or desktops. It affects searches from mobile devices across all languages and locations.
2. Is it a page-level or site-level mobile ranking boost?
It’s a page-level change. For instance, if ten of your site’s pages are mobile-friendly, but the rest of your pages aren’t, only the ten mobile-friendly pages can be positively impacted.
3. How do I know if Google thinks a page on my site is mobile-friendly?
Individual pages can be tested for “mobile-friendliness” using the Mobile-Friendly Test.
From Aaron Gustafson
Aaron Gustafson put together a simple list of four things you as a web developer can do to mitigate the effects of Google's changes, though the simplicity belies the depth of effort that may be needed for some sites. I've collected the list, but his post has the details for how to approach each step:
Embrace mobile-first CSS
Focus on key tasks
Get smarter about images
Embrace the continuum
What Is Your Mobile Traffic?
I've been asked how to find out how much traffic to a site is from mobile users. In Google Analytics this is pretty easy:
Choose Audience from the left menu.
Choose Mobile once Audience has expanded.
Bear in mind that this just tells you where you are today. If that number drops then it may be a sign that your mobile strategy isn't working. At the same time, if that number is already low then it may not drop any further owing to unintentional selection bias in how your pages are coded.
Oh, By the Way
Google isn't the only search engine. When I mentioned that on this blog before, Google had 66.4% of the U.S. search market. As of January 2015, that's down to 64.4%. Bing is up from 15.9% to 19.7%.
Google Sites led the U.S. explicit core search market in January with 64.4 percent market share, followed by Microsoft Sites with 19.7 percent and Yahoo Sites with 13.0 percent (up 1.0 percentage point). Ask Network accounted for 1.8 percent of explicit core searches, followed by AOL, Inc. with 1.1 percent.
While I Have Your Attention
Two days after the initial announcement of this change, word also came that Google is working on a method to rank pages not by inbound links, but by trustworthiness, in essence by facts.
When this finally hits, pay attention to those who refer to the change as Truthigeddon. Be wary of them.
Alt_Text_Bot uses an API from CloudSight to help describe images submitted in tweets. Users simply need to mention @alt_text_bot in a tweet with an image (the tweet must be part of the image, not in a Twitter card or via a link) and Alt Text Bot will respond with a description.
It has some limitations. The biggest is the character limit within Twitter. Converting a chart to text, for example, is a great idea, but the character limit of Twitter precludes you from getting much value and descriptions can be truncated.
Another is probably from the CloudSight API. If an image is tweeted twice (such as a retweet), you might get two different descriptions (as this first one demonstrates, and then this second one). On top of this, not all images are very clear and context is hard to convey, as in this one showing wheelchair demonstrators in Seoul.
Regardless, given the current state of accessible images on Twitter, this tool is awesome. As I write this I see more and more people testing Alt Text Bot, so I expect that, even if this is just a proof of concept, more good things will come as a result.
The next image is me being excited about this, along with both descriptions that Alt Text Bot provided.
Yesterday I presented a stripped-down version of my Selfish Accessibility talk at Buffalo Unconference. With an unknown audience and a 20 minute timeline, I gutted most of the technical bits and focused on my thesis. I think it was well received.
At the end of the talk, I pointed people to the version of this talk I gave for Avega Group last month in Stockholm, as it has (many more) slides (with more detail) and video of me rambling. That longer talk is a bit of a disservice to those who don't want to hear me drone on for an hour and a half as well for those who aren't technical.
With that, here are the slides from yesterday in all their concise glory.
The conference produced just one tweet to satisfy my ego:
Now that feature has been formalized. Users should see it when retweeting a tweet as the option to quote a tweet (which previously would just wrap the original tweet in quotes).
This can be a boon to Twitter image accessibility, allowing alternative text to wrap an image tweet (see my post on existing techniques). Except for a few points:
Twitter's (current*) prohibition on retweeting oneself means that users cannot easily quote their own tweets to add alternative text — at least not in the Android app nor on the web. TweetDeck allows it, so perhaps we'll see it in the app or web site.
Because a quoted tweet is not a reply, it doesn't show up in the list of replies when viewing the original image tweet. This means a missed opportunity to be associated with the alternative text when viewed on its own.
When viewing the tweet providing the alternative text (as a standalone tweet, not in the timeline) in the Android app, the image within the quoted tweet is not displayed.
Embedding a tweet that acts as alternative text doesn't show the original quoted tweet (nor its image). There isn't an option to embed media, so web page authors will likely embed the original image tweet instead of the alternative text tweet. You can see this example below.
Twitter is missing an opportunity to provide an interface that prompts users to provide alternative text. This might help stem the inconsistent efforts from those who want to provide accessibility (such as 18F's noble but under-informed efforts).
The first image shows a tweet quoting an image tweet when viewed in the timeline (the quoted tweet's content is visible). The second image shows a tweet quoting another when viewed on its own, demonstrating that the quoted tweet's content isn't displayed at all. Note in both views that I cannot retweet my own tweet (the option is disabled).
Cannot easily use new @Twitter tweet quoting on web nor app. Doing this via TweetDeck.
(alt:CSUN cert of attendance) https://t.co/Onn99uUIfg
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.
In addition to the slides, I've embedded video of my talk and way too many tweets after that.
Video
Impressing everyone on the internet, Paul Klipp has already gotten videos from ACE! posted less than 24 hours after the event ended. That's impressive. I understand his tactic is to upload lower resolution videos immediately and then slowly replace them with higher resolution videos. Depending on when you see this, it may still be the low-res video.
Tweets
Tweets from ACE! that satisfy my ego, show me in a photo, or might be funny.
I've received the audience feedback from my talk and overall was pleased. 17 people responded (out of what I estimate was ~40+ in the room) with the following rankings:
Loved it! 10
Liked it: 2
Meh: 4
Didn't like it: 0
Hated it! 1
Of those 17, 10 left comments (which I greatly appreciate!). Sadly, the one Hate it vote did not leave any comments.
Liked it: Too basic for me, but nice examples of disabilities.
Loved it! I loved the idea how to easily test your apps.
Loved it! Great that this topic emerged.
Loved it! Great approach to creating sites/apps friendly for impaired.
Loved it! Full of very practical suggestions. Thanks for including it.
Loved it! Content that usually doesn't get a forum.
Meh: Interesting, however I won't get a chance to use what I learned.
Loved it! Interesting point of view. I did not consider accessibility during software design. I should start.
Liked it: Most important is to think about problem, not about product/project.
Meh: Nicely said, but too short.
The two Meh comments are mostly out of my control. I was given a 30 minute slot, which I agree is too short for all that can be said on the topic. As for the commenter who claims he/she won't be able to use it, I feel that the testing parts of my talk at the very least are in everyone's reach, so I think it comes down to deciding to use it. Even if only to troll the Virgin America site.
Both typefaces claim that heavier strokes on the bottom prevent dyslexic readers from flipping the letters when viewing them. The original caption: A heavier bottom is used to show which way is supposed to be down.
I've been writing this post in fits, so it may be a bit disjointed. I started it on my flight home from CSUN, and continued to work on it on subsequent flights. Apologies if it's a bit chaotic.
TL;DR: Typefaces designed to help dyslexics have no effect.
I'll list information about the two typefaces that I am aware of (which are designed explicitly for readers with dyslexia), as well as notes from the talk at CSUN and a couple other examples.
Typefaces
I am aware of two typefaces that are designed with dyslexic readers in mind.
OpenDyslexic
Open Dyslexic is an open source typeface for readers with dyslexia. The rationale behind the design:
OpenDyslexic is created to help with some of the symptoms of dyslexia. Letters have heavy weighted bottoms to indicate direction. You are able to quickly figure out which part of the letter is down which aids in recognizing the correct letter, and sometimes helps to keep your brain from rotating them around. Consistently weighted bottoms can also help reinforce the line of text. The unique shapes of each letter can help prevent confusion through flipping and swapping.
Dyslexie
Dyslexie is a paid typeface (free for home use). The site references research that supports the following claim:
Representative research among many dyslectics has shown that the font Dyslexie actually helps them with reading texts faster and with fewer errors.
I would like to note that copying that text directly from the browser wasn't easy. The use of Cufon to embed the typeface drops each word into its own element that itself hides and replaces the raw text in a canvas element. I'm sure you can imagine how much that offends me.
The following video explains the idea behind the typeface:
Study: Can a font improve reading?
The latest study to suggest that typefaces designed to aid reading for dyslexics had little to no effect was presented at CSUN this past week. As I noted on Twitter, I already had an idea what the results would be, and I came away feeling validated.
The study hasn't been pubished yet and I saw its first general presentation. The study was conducted at Mount Allison University, a 2,500 student college with 215 full-time students with disabilities. 50% of those students are classified as having a learning disability.
The questions asked by the study:
Do the style of the letters on a page mean that you read faster and make fewer errors?
Do persons with LD [learning disabilities] using this font read faster and make fewer errors?
The typefaces (Open Dyslexic and Dyslexie) make claims about their benefits, aggregated in the presentation as:
Students with surface dyslexia experience letters flipping and moving around; Letters needed to be bottom heavy to prevent them from moving around
New font would increase reading speed
Will also increase accuracy (fewer errors)
Will decrease reading stress
Widely promoted to on-line uses and in word processing (Instapaper, iPad, an app)
Strong anecdotal feedback
The presenter outlined some literature references, the procedure the team followed to perform the study, the nature of the participants (and control group), and the overall results.
The first bullet in the summary wraps it up nicely:
The font does NOT improve reading speed or accuracy for students with LD.
An interesting note from the study was that half of each group (50% of control, 57% of LD group) said they would consider using the font and were then shown how to access it (download and install it, which I assume was Open Dyslexic). In a follow-up, none of those participants were using the font.
Another interesting point was that 40% of the control group and 48% of the LD group thought they performed better when using Open Dyslexic, though that was not the case.
As anyone who's done user testing knows, it's not uncommon for users to report one thing while doing or thinking another, so I consider this to be anecdotal reinforcement that the typeface had no benefit for users.
Study: Good Fonts for Dyslexia: An Experimental Study
In late 2013 I found a write-up on a Spanish study that reviewed which fonts were easiest for readers with dyslexia. The post summarizes the study:
Based on the evaluation of 48 dyslexic subjects ages 11-50, reading 12 texts with 12 different fonts, they determined that reading performance was best with sans serif, monospaced, and roman fonts used in the study. They also found that reading was significantly impaired when italic fonts were used.
[…]
Use of the OpenDyslexic font did not enhance text readability or reading speed. The study participants strongly preferred Verdana or Helvetica over the OpenDyslexic alternative.
For those of us who build applications and sites with content of any length (whether instructions for shopping carts or rant-laden long-form articles), I have found a few techniques are generally agreed upon by the community (feedback is welcome!):
Avoid justified text.
Use generous line spacing / leading.
Use generous letter spacing.
Avoid italics.
Generally use sans serif faces.
Use larger text.
Use good contrast.
Use clear, concise writing.
This generally follows rules for good typography.
You may have heard that Comic Sans is easier for readers with dyslexia to understand, but so far that evidence appears to be anecdotal. Certainly not enough to warrant punishing all your other users.
If you read an article that suggests users with dyslexia see letters flip or rotate, then be wary. Not only was this assertion challenged by participants in the study reported at CSUN, but generally the participant reaction was anger. The flipping/rotating may be a myth perpetuated by those without dyslexia in an effort to make sense of its effects.
Update: March 26, 2015
In a post from 2011 (Dyslexia, Fonts & Open Source), Mike Gifford outlines some of the issues related to supporting readers with dyslexia, including typefaces.
I'll fill this up with notes and other content later, but in the meantime here are the slides from my talk this morning:
I've written a bunch of handy stuff on print styles, here are some links (or you can see all posts tagged print on my blog) along with other resources (most of this is referenced in my slides):
I got feedback from my talk, and it was overwhelmingly positive. Consider mine was the first lightning talk of the first session of the first day immediately after the keynote, I'm just pleased people took a moment to vote.
Voting consisted of asking attendees to drop a colored card into a basket representing my talk. There were three options. I got 15 green cards (it was amazing), 4 yellow cards (it was okay), and no red cards (I didn't like it).
Only one person left a comment, which was Talked too fast. I cannot disagree with that. With 10 minutes to cover 42 slides and do so to an audience of non-native English speakers, I'm thrilled I only received that comment once (though I suspect many others agreed).
I'll be spending much of March bringing my shining personality to Europe, partially in the form of speaking engagements. The first one I can announce is the sixth annual ACE! Conference in Krakow Poland on March 16 and 17. Somewhere within that two day conference I'll be talking about accessibility.
There is a growing list of great speakers, and I'm pleased to be included among them. At least until they discover I'm a fraud.
If you are familiar with ACE!, then it's worth noting this year a separate track has been added focused on building better software. If you are unfamiliar with ACE!, then I will let the organizers speak for themselves:
ACE! is the largest regional conference of its kind in Central Europe, attracting people from all over the region.
We're really excited about ACE! 2015 which combines two one-track conferences into one. The Building Software Better track includes the traditional ACE! content such as agile, lean, Scrum, Kanban, and other tools and methods for improving the software development process. This year we're adding a Building Better Software track that features Lean Startup, LeanUX, Design Thinking, and Customer Development topics. We're also adding a workshop track so that attendees can apply new skills and experiment with new ideas. It's going to be the best ACE! yet!
You can stay abreast of new speaker announcements and other news from the conference by following @aceconf on Twitter.
As the conference site gets updated with this year's logo and the abstract from my talk, I plan to post it here.
I've never been to Poland, and I am hearing nothing but good things about Krakow (not just from its tourism board), so I am really looking forward to visiting.
The conference will be held about 5km from the city center, so if you're nearby you can pretty much include my talk in your tourism walk for the day. I've embedded a map for my own benefit:
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 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.
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.
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 bit.ly 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.
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.
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.
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:
Windows 8.1, JAWS 16, Firefox.
Windows 8.1, JAWS 16, Internet Explorer 11.
Windows 8.1, NVDA, Firefox and Internet Explorer 11.
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.
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.
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.
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):
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.
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.
The headline really captures it all.
