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 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.

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.

Update: April 8, 2015

In my post Twitter (Accidentally) Takes Step Toward Accessible Images, I discuss how Twitter's new quoting feature can be used to help make image tweets more accessible.

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 evolt.org 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

ReCAPTCHA Reboot

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.

WebAIM

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

Twitter Conversation

Conclusion

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.

Related

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.

Monday, December 1, 2014

Web Development Advent Calendars for 2014

For a few years now web developers around the world have celebrated Saturnalia Christmas with advent calendars covering topics related to the web. Some come and go, but you'll probably recognize a few regulars on this list.

I may have missed some, so please pass them along if you know of any. As I learned in prior years where I have tracked them, I don't know them all on December 1, and update accordingly. Some of this is because the sites don't promote the new calendar on the home page.

1. 24 Ways

24 Ways, the one that most of this think about for web development calendars, is back again. It's been going strong since 2005 and based on its history this year should have some good articles.

2. Perl Advent Calendar

Perl Advent Calendar goes all the way back to 2000 (and back then looked a bit more like a traditional advent calendar, too) and has been dispensing tips for Perl developers ever since.

3. 24 Jours de Web

24 Jours de Web is starting its second year as an advent calendar for web folk. Written in French, it is clearly primarily targeted at French speakers, but a round of Google Translate will open it up to far more readers (like me).

4. UXmas

UXmas is an advent calendar aimed at the user experience community. Coming from Australia, American readers may be thrown just a bit by the schedule. The calendar promises everything from sketches, to articles, to tools, to videos.

5. Webkrauts

Webkrauts has an all German advent calendar, and it also dates back to 2005. It covers general web topics, but being in all-German readers like me will benefit from a Google Translate version of the page.

6. Web Accessibility Advent Calendar 2014

Web Accessibility Advent Calendar 2014 is in Japanese, and thanks to the wonderful powers of Google Translate, I can tell you that it is a calendar to make the talk about Web accessibility (based on this statement: Webアクセシビリティに関する話題でつくるカレンダーです。). If you know Japanese, I welcome any corrections. The site Adventar.org appears to host other advent calendars, some about web technologies, some about ramen.

7. 24 Pull Requests

24 Pull Requests is less an advent calendar than it is an effort to mobilize developers. The goal is to get developers to send a pull request every day in December (up to Christmas), thereby supporting your favorite open source projects. There are even Coderwall badges for those who collect those sorts of things.

8. SysAdvent

SysAdvent is targeted to systems administrators, but there is a some cross-over to web developers. It has posts dating back to 2008, so there is plenty of good material there if you're too impatient to wait for each day to be revealed.

9. Lean/Agile Advent Calendar

Håkan Forss's lean/agile calendar was recommended to me by Martin Burns, to whom I generally listen on this topic. Håkan is an Accredited Kanban Trainer (AKT) and a Kanban Coaching Professional (KCP), and his first post seems pretty good, so I've added it. Also, LEGOs.

10. Performance Calendar

Performance Calendar hails this as the speed geek's favorite time of the year, ostensibly because of the tips it has been offering each December since 2009. It isn't just server optimizations you'll find here, so don't shy away because you're not a system admin. While I had it last year, it hadn't launched when I posted this, so I've rectified that.

11. Free Font Calendar

The Free Font Advent is providing information on and links to, you guessed it, a free font every day. The site is in German, but Google Translate will be more than enough to get the narrative written for each typeface. I picked this one up from Deborah Edwards-Onoro's advent calendar post.

12. Amazon Web Services Calendar

AWS Advent is dedicated to sharing information on features and services available from AWS. If you are an AWS user and have something to offer, as of this writing there are still five slots open for contributions. I also picked this one up from Deborah Edwards-Onoro's advent calendar post.

Not Web Related

The Royal Institution has something called Things to Do with Stuff that might be like an advent calendar, given this statement: Throughout December inspired by the 2014 CHRISTMAS LECTURES, we're releasing little nuggets that'll encourage you to interact with and understand the tech that surrounds us. The very first item is how to make a movie projector with a smartphone, a magnifying class, and a box.