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.


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.


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.


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 ( aardrian/status/ 534751243491901440), heard from Jonathan Rubin of the GSA on Twitter ( jonathan_rubin/status/ 534788879518539776), and used it as motivation on writing a post about tabindex best practices for accessibility:

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