Just a click: The new reCAPTCHA API

Just announced today by Vinay Shet is the new reCAPTCHA API which is being called the “No CAPTCHA reCAPTCHA.” With the new system, many people might just click a checkbox rather than have to read and type distorted text. As just one part of determining if someone is a bot or human visitor, the movement of the mouse cursor within the reCAPTCHA area will be tracked to see if it has human-like motion.

A CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) is a test that is used to filter out bots and other automated agents to prevent spam and other malicious activity. There are many different types of CAPTCHAs, but one of the most common today is a text field and an image of scrambled text. The person reads the scrambled text and types it into the text field.

An example CAPTCHA.
An example of a scrambled-text CAPTCHA (Public domain image from Wikipedia Commons.)

CAPTCHAs can present difficulty to people with disabilities. This new click-a-checkbox CAPTCHA also is problematic to some users—especially if it were the only CAPTCHA method. Some people only access websites using a keyboard or keyboard emulator because of physical disabilities. People who are blind cannot see where to click with the mouse. People using Mouse Keys will not look like a regular mouse user. This problem can be mitigated by having an alternative CAPTCHA in a different modality for those users.

I have not tried any of the new reCAPTCHAs in the wild yet. I do know that Google has implemented increasing challenges with the new system, where a user with an “odd” checkbox click and telemetry will see an additional CAPTCHA challenge (such as an audio CAPTCHA or picking out the pictures of kittens). I would hope that there is a way to either bypass the click or at least “click” the checkbox using a keyboard, screen reader, or other assistive technology in order to get to the next CAPTCHA step.

Web Accessibility & Keyboard Access

Last week, Marieke McCloskey posted a web accessibility article on the Neilsen-Norman Group site: “Keyboard-Only Navigation for Improved Accessibility.” The article is very good; I wanted to make some general comments on it. The article had several points, which I will comment on in brief:

  1. Test using the site with keyboard. This is good advice, because often you cannot find some usability issues unless you actually try something yourself.
  2. Make sure that the keyboard focus is visually obvious. This is important because otherwise people who are using the keyboard (perhaps because they cannot physically use a mouse) cannot tell what they are doing. Browsers often have a visible highlight, but oftentimes the styling is overridden by web site designers who want a particular look and feel. I find myself irritated by this problem from time to time (when I don’t feel like switching from the keyboard to the mouse) when I cannot tell where tabbing went. Do not override the highlight unless you provide a highlight that is at least as obvious as the default when interactive elements are focused.
  3. Make sure all interactive elements are navigable. If an element is not navigable, then the person will not be able to tab to or otherwise focus on the element in order to interact with it. The element just sits there, taunting them. Native HTML elements are navigable by default, but scripted interactive elements based on generic HTML elements (such as a span or div) should have a tabindex or some other mechanism to make them navigable.
  4. Consider a link to skip navigation. Sites with navigation links and sidebars may have many things through which a user must tab before they can get to the main content of the site. While it is important for the person to be able to get to the navigation, it is very inefficient to have to tab through material that is on most pages. The article suggests using “Skip Navigation” links on a page. I would like to make a few additional comments on this suggestion below.

Alternative to Skip Links

The Web Content Accessibility Guidelines 2.0 (WCAG) are accessibility guidelines for web sites (and they also provide good guidance for documents and software). Guideline 2.4.1 from WCAG says:

Bypass Blocks
2.4.1 A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A)

Skip links are one way to do this, but are kind of old fashioned. They clutter up a page and clutter up the navigation order. A better technique that has pretty good support with modern browsers and screen readers is to use landmark roles which add semantics to a web page.

Landmark roles were introduced with Accessible Rich Internet Applications (ARIA). To use ARIA landmark roles:

  1. Ensure that the page has all information in containing sections. These sections might be <div>s or HTML 5 section tags such as: <section>, <main><nav><article><aside>, <header>, <footer>, and <address>.
  2. Make sure there is only one <main> section.
  3. Add the role attribute to each containing section and an attribute value from the list of ARIA landmark roles and other useful roles.
    • application
    • banner
    • complementary
    • contentinfo
    • form
    • main
    • navigation
    • search
    • article (non-landmark role)
  4. Make sure that the containing section tag matches a similar landmark role. ARIA has greater richness than HTML 5 does. So you would have sections like:
    • <main role="main">...</main>
    • <nav role="navigation">...</nav>
    • <aside role="complementary">...</aside>
    • <article role="article">...</article>
    • <header role="banner">...</header>
    • <footer role="contentinfo">...</footer>
    • <address role="contentinfo">...</address>

    and potentially a number of <div>s or <section>s with other landmark roles.

A screen reader user can navigate from landmark to landmark on a web page. This allows them to more easily navigate a page and go back and forth to the content in which they are interested.

More Information

Accessible Graphical Buttons in HTML

Picture of a push button.
Picture by flickr user chrisinplymouth.

With a recent project, I have been working again in HTML trying to make semantic and accessible mark-up for interfaces. One common type of user interface control is a graphical button, which has no text for a label.

My first thought and trial was just to include alt-text with the image that serves as the button like so:

<button type="button">
<img src="email.png" alt="E-mail" />

Here is an example:

This is short and semantically correct. In my first test, it worked just fine as the screen reader I was using read the alt-text of the image. It turns out that VoiceOver on iOS 6 did not do so well with this code—all it read was: “Button”

A Better Way

After doing a little bit of research, I found the recent article Making Accessible Icon Buttons by Nicholas C. Zakas. He suggested using the aria-label attribute on the button, which provides more reliable accessibility with different screen reader setups. So, this is better code to use for graphical buttons:

<button type="button" aria-label="E-mail">
<img src="email.png" alt="E-mail" />

Here is an example:

This works fine in VoiceOver. I was a little wary about double-labeling elements in case both sets of text are read. However, no screen reader I have tested double-reads “E-mail” from both the alt-text and aria-label.