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.

Sunday, November 30, 2014

Blue Beanie Day

Image as seen with three forms of colorblindndess
Image showing the pixel-art image of Jeffrey Zeldman in his iconic blue beanie (top left) simulating (clockwise) protanopia, deuteranopia, and tritanopia.

Blue Beanie Day, or for about 0.05% of the population with tritanopia/tritanomaly, Teal Beanie Day!

On Sunday, November 30, web designers and developers across the globe will celebrate Blue Beanie Day 2014, wearing a blue beanie to show their support for web standards. Join in!

[…] [S]porting a blue chapeau is a reminder that web standards—standards like semantic markup, neatly separated styles, and DOM scripting—are responsible for much of the work we do today.

This quote lifted from Blue Beanie Day 14: Toque ’em if You’ve Got ’em at A List Apart.

I'm a big fan of standards intended to support accessibility as well, such as WAI-ARIA and WCAG (which includes the success criterion addressing use of color).

No, I'm not taking a shot at Blue Beanie Day nor the intent behind it. My goal is to remind people that accessibility is core to the standards, and ignoring it is tantamount to ignoring the standards this day is intended to promote.

Images using CVSimulator app.

By the way, 0.05% of the United States population is 158,500 people. Small percentages of very large numbers are still large numbers.

Related

Tuesday, November 18, 2014

Don't Use Tabindex Greater than 0

Animated GIF showing the tab order on a page using the default Re-CAPTCHA, which sets a tabindex, forcing a keyboard user through six tab-stops to get to the Skip to content link.

Tabindex had the potential to be a useful attribute. A developer could set the order in which focus is moved on a page as a user tabs through the form (or links, or content). It became a stop-gap for forms and pages that relied too heavily on absolute positioning and didn't flow naturally. The problem is that it is often set by developers who don't have any idea of what the user expects.

This mis-use has effectively guaranteed that using tabindex values greater than zero is a bad idea. If, as a developer, you have to use tabindex on a form, then the page itself probably isn't laid out well and will only confuse keyboard users and, more importantly, users of assistive technology.

Browsers take any element with a positive tabindex value and promote it to the front of the pack for tabbing through the page. Only after a browser gets through all elements with a tabindex does it then fall back to source order. It doesn't matter if your tabindex is one million, it will still trump everything on the page that doesn't have a tabindex.

This is such a well-known issue that the W3C HTML Working Group is working on new language to deprecate values greater than zero. There is even a bug filed against the HTML specification to that effect.

For more detail I encourage you to read Léonie Watson's piece, Using the tabindex attribute.

Tabindex Best Practices

Here are some tips to use tabindex properly.

tabindex="-1"

Setting tabindex="-1" allows you to set an element's focus with script, but does not put it in the tab order of the page. This is handy when you need to move focus to something you have updated via script or outside of user action.

tabindex="0"

Setting tabindex="0" will take an element and make it focusable. It doesn't set the element's position in the tab order, it just allows a user to focus the element in the order determined by its location with the DOM.

tabindex="1" (or any value > 0)

Do not set a tabindex="1" or any value greater than zero (or any positive value).

The Example

The example in the animated GIF above is unfortunate in that the site developers themselves don't set a tabindex (I found this at User Experience Impossible: The Line Between Accessibility and Usability on the GSA's DigitalGov site). Instead, for reasons I cannot explain, they use a CAPTCHA on the comment form. The implementation they chose, however, inserts its own tabindex values.

This means that as the user starts tabbing through the page, he or she is first sent to the text entry field on the CAPTCHA in the comments section.

Even as a sighted mouse-user, I was confused how I got there as I tabbed into the page. It takes five more tabs to get to the link that allows the user to skip to the content (which appears first on the page).

This also creates a problem for a user who is filling out the comment form, as tabbing from the Name and then Email fields puts the user on the privacy link for the CAPTCHA, but not into the field where he or she can type the text to submit the form. Some users may never know there is a CAPTCHA there depending on how they got to the comment form.

Paul J. Adam shows the offending code in a tweet, which I will steal and display here since I'm too lazy to screen-capture it:

I don't want to beat up the DigitalGove folks, but this is a great example of how a perfectly functional page (regardless of how I feel about the hover versus focus styles) can be ruined by not testing it after adding third-party widgets.

Bonus: Don't Use CAPTCHA

There's a lot written about this. I'll just link to this from the W3C: Inaccessibility of CAPTCHA

Update: November 19, 2014 at 1:25pm

I still haven't heard back from the folks at DigitalGov on Twitter, but Jonathan Rubin from the GSA responded (though he did ping an account that hasn't tweeted in a month), I just haven't heard any more from him. I've also left a comment (pending moderation) on the site itself.

I discovered while trying to leave a comment that the ReCAPTCHA is served via HTTP while the page is served via HTTPS. One of my browsers (IE) blocks it by default because it's an insecure element on a secure page. That means I won't experience the tabbing problem, but it also means that I cannot leave a comment as the form silently breaks without the ReCAPTCHA. I've left a comment for that as well (but I didn't see a preview and I got no error messages, so, yeah).

Here's the rub — I don't want people beating up the DigitalGov team. That these folks have put forth such a good effort but fallen down on one issue is not uncommon. We all do that. I do it (last week Karl Groves discovered a CAPTCHA on this blog that I never saw). That I found it on a post about accessibility is unfortunate, but it also means the DigitalGov team needs to be more responsive when provided with clear technical solutions and learn to test after each feature addition. Like all the rest of us who work in or near accessibility.

Update: November 19, 2014 at 6:25pm

The comments I posted on the DigitalGov page are still in moderation queue, even though comments posted well after mine have been approved. You can see them still in moderation in the screen capture.

Given my suspicion that they won't be posted (since I've heard nothing back from the initial conversation with the Twitter account), I'll post the comments here. The first was a reply to a site admin following up on a comment from another user noting that the keyboard navigation of the page is broken. My second comment is a follow-up.

Screen shot of comments.
The content of my comments is in the page content.

The First Comment

November 19, 2014 at 12:44 PM

The ReCAPTCHA on this page uses a tabindex value. Since browsers honor tabindex values before falling to source order in the DOM, the very first (through fifth) tab stop on the page is the CAPTCHA. It takes six presses of the tab key to get to the “Skip Navigation” link. That’s the issue I suspect TRUEAXGUY is referencing.

I’ve mentioned this issue to DigitalGov on Twitter (https://twitter.com/ aardrian/status/ 534751243491901440), heard from Jonathan Rubin of the GSA on Twitter (https://twitter.com/ jonathan_rubin/status/ 534788879518539776), and used it as motivation on writing a post about tabindex best practices for accessibility: http://blog.adrianroselli.com/2014/11/dont-use-tabindex-greater-than-0.html

As I’ve said before, I am happy to help, but the easiest fix is to remove ReCAPTCHA or, failing that, go to line 449 of this page (I don’t know where you call it in your pre-rendered code) and remove this: tabindex: 4 (making sure to also remove the comma from the line before it so the JavaScript doesn’t break).

The Second Comment

November 19, 2014 at 1:24 PM

Also, the ReCAPTCHA is blocked by one of my browsers because it’s served as HTTP instead of HTTPS, while the page itself is served as HTTP. This means some users may never even be able to comment (no error messages are displayed on submission, it just silently fails).

Since you have moderation enabled, and since CAPTCHA is already a proven accessibility barrier, and since it’s messing with keyboard navigation, I strongly suggest you remove ReCAPTCHA altogether.

Update: December 3, 2014

Even Google wants to replace its ReCAPTCHA, acknowledging that it is clunky and ineffective:

Update: December 6, 2014

I gathered accessibility notes on the new reCAPTCHA from around the web and posted them: ReCAPTCHA Reboot

Saturday, November 15, 2014

WordCamp Toronto Slides: Selfish Accessibility

WordCamp Toronto 2014 logo.

As promised, slides from my talk this morning at WordCamp Toronto:

Ego-Building Tweets

I like audience feedback, moreso when it's positive. I've also added some general tweets about the accessibility track.

Other Talks

I spent Saturday in the accessibility track (I missed one talk, sadly). There was some overlap on general themes, which I think was good. Overall, anyone who visited one talk still got a common baseline, while those who stayed for the day had the core accessibility information reinforced across speakers.

I was thrilled I got to present in the same track as Billy Gregory and Karl Groves, also known as The Viking and The Lumberjack. These guys know their stuff.

Sunday, November 2, 2014

Learn to Do It Yourself

Unimpressed Willy Wonka says, 'Tell me more about how I can fix your code for free… instead of you learning a new skill.'

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:

Steve Faulkner pushes back:

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

Thursday, October 30, 2014

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

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.

Tuesday, October 28, 2014

HTML5 Is Now a W3C Recommendation

HTML5 logo — I am the 'alt,' not the 'title'

I was already pretty excited when I read on the W3C Accessibility Task Force mailing list that the formal objection against longdesc was overruled. But then thisHTML5 is a wrap.

I've seen some movement on the Twitters (and the W3C HTML Working Group mailing list) over the last week or so suggesting that there was going to be some announcement, but this tweet from HTML5_Chewbacca pretty much gave it away:

I don't speak Wookie, but I think he's pretty confident that HTML5 would be wrapped up before November.

Of course, I was literally at lunch when the email came through on the mailing list, as well as the tweet from the W3C. But since this post is more of marker for me to reference, I'm not bothering with meat here. I will, however, link to other posts on the web.

There's also this explainer video for those who may not be quite sure just how web standards are a good thing:

Five years ago today Google's CEO made predictions about where the web would be in five years. He did not predict HTML5 was going to become a recommendation today. And you trust this guy with your searches? Anyway, snarkiness aside, I think W3C Memes captures it pretty well with this image:

Image of main characters from the movie 'Desperado' walking away from a fireball after having dropped two hand grenades to evade their pursuers.
Photo happily stolen from W3C Memes.

Friday, October 24, 2014

Speaking at WordCamp Toronto 2014

WordCamp Toronto 2014 logo.

On Saturday, November 15 I will be kicking off WordCamp Toronto with my talk "Selfish Accessibility." In case you haven't been following my blog, I use the talk to make the case that supporting accessibility best practices is actually in your best interests as a user. Or I can let the event description explain it for me:

We can all pretend that we’re helping others by making web sites accessible, but we are really making the web better for our future selves. Learn some fundamentals of web accessibility and how it can benefit you (whether future you from aging or you after something else limits your abilities). We’ll review simple testing techniques, basic features and enhancements, coming trends, and where to get help. This isn’t intended to be a deep dive into ARIA, but more of an overall primer for those who aren’t sure where to start nor how it helps them.

What will attendees learn from this presentation?

  1. Recognize that they are all going to qualify as disabled users.
  2. Recognize that non-disabled users benefit from accessibility affordances.
  3. Perform simple accessibility testing.
  4. Have reference material and resources to continue self-education.
  5. Write code that uses ARIA properly.
  6. Write basic HTML that isn’t a barrier to accessibility.
  7. Apply these skills to any platform.

While I may start off the accessibility track on Saturday, there are talks all day Saturday and all day Sunday. It's a full plate of great content — some of which is from speakers I have seen before, so I know it will be good. Check out the schedule to see what's available.

Registration for the weekend is only $30, so you may want to register now to make sure you get a spot. Whether or not you can make it, you'll be able to follow tweets from attendees (and organizers) on Twitter with the hash tag #WCTO.

The event is taking place a few miles to the left of downtown Toronto at at Humber College’s Lakeshore Campus in the media study building (building L):

Tuesday, October 21, 2014

NAGW Slides: Responsive Web Design Primer

I just finished a webinar for the National Association of Government Web Professionals where I provided an overview of responsive design. I always struggle when I cannot see the audience, but as always my ego carries me through to the end. The slides are embedded here for any and all to see.

There are links peppered throughout, but there are so many more I could add. Feel free to suggest more if helpful.

Selfie
View from my side as I ooze with confidence right before the talk.

Monday, October 20, 2014

CDC Ebola Response on Twitter Excludes Blind

Image taken from a CDC tweet to show contrast.
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):

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):


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