Karl Groves

Tech Accessibility Consultant
  • Web
  • Mobile
  • Software
  • Hardware
  • Policy
+1 443.875.7343

18 Years in: The basics still matter

I got into web development in the late 90s. By that time, the Web Accessibility Initiative was well on its way to trying to make the web more accessible. In that time we’ve seen the rise (and fall) of many new technologies on the web and many new devices used to consume and create web content and yet accessibility is still an area that sees little attention in the mainstream.

For me, seeing accessibility talks at conferences that present the basics really bums me out. I often tease my good friend Billy Gregory for doing "basic" presentations. I’ve seen those types of presentations a gazillion times and personally wish there were more presentations on bleeding edge tech like JavaScript MVC frameworks and Web Components. I shy away from them myself and shy away from writing about things that are "basic" on my blog. Maybe it is a little egotistical, but I’d rather focus my time on answering hard questions.

On February 28, 2015, at Accessibility Camp Bay Area I will be doing a talk on the basics

Why? Because the basics are still a big deal. By the time Accessibility Camp Bay Area rolls around, Tenon API will have tested a half-million distinct URLs. The data we will have will be statistically significant and it shows quite clearly that web developers still get the basics wrong.

Join me February 28, 2015, at Accessibility Camp Bay Area where I will discuss the 10 most frequent accessibility issues and how to avoid them.

I’m available for accessibility consulting, audits, VPATs, training, and accessible web development, email me directly at karl@karlgroves.com or call me at +1 443-875-7343

To Hell With Compliance

A few weeks ago, Asa and I added a page to Tenon’s documentation that lists What Tenon Tests in reaction to questions about “How much WCAG coverage” Tenon has. I had already covered, at a high level at least, what can be tested and how quite a while ago and, while Tenon only tests a subset of that, it also serves as a useful reminder of what sort of coverage you can expect from an automated tool. The page is really cool – it is driven by the actual tests inside Tenon so that it is always up to date and accurate. The process of creating that page on what Tenon tests also reminded me of my general disdain for the word “Compliance”. Compliance, you see, is synonymous with doing the bare minimum for users.

Here’s an image that comes to mind whenever I hear “Compliance”. Sure, this ramp has a pole in the middle of it, but hey, its a ramp right?

Many people will see that image and say that the ramp above is not compliant, because the pole is in the middle of it, rendering the ramp unusable. In fact it violates ADA guideline 4.8.3 for ramps, but I still love the analogy with WCAG “compliance”.

1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. (Level A)

The above quote, from WCAG 2.0, discusses non-text content. The actual success criteria content is longer but not any more detailed. Of course there’s also the Understanding SC 1.1.1 and How to Meet WCAG 2.0. These last two documents are only informative in nature, anyway. Regardless, they’re all written in standards-speak and none of them explicitly state what I think is the most important part of this Success Criteria: that the equivalent to the non-text content must approximate, as closely as possible, the purpose and meaning of the non-text content! There are no failures listed that say “failure due to using a non-equivalent alternative” though admittedly G94 does discuss equivalence. In any case the normative information doesn’t discuss the quality of the alternative. Normative content on conformance contains no discussion of quality user experience, either. In fact, WCAG’s own introduction says:

Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas.

But this post isn’t about WCAG. I fully believe that it is the intent of WCAG to improve user experience and that by following WCAG the users’ experience will be better than it would had WCAG not been followed. That said, compliance with WCAG is not quite the same as usable by persons with disabilities as evidenced by the quote above. WCAG compliance isn’t “the goal” but rather one of many means toward the goal of an accessible user experience. As a standard that seeks to codify what is quite often subjective in nature, WCAG is excellent. But, it is exactly this subjectivity that makes WCAG so challenging and so different from other standards. This subjectivity is what causes people to do only that which is the absolute bare minimum necessary to achieve what they want to call “compliance”.  This bare minimum attitude misses the point entirely, even if your goal is only to mitigate legal risk.

These express terms of the ADA provide plaintiffs several alternative bases upon which to state a claim regarding the inaccessibility of Southwest’s Web site: (a) the Web site is a service, advantage or privilege of Southwest’s travel service, and the Web site’s inaccessibility constitutes a prohibited intangible barrier to that service, advantage or privilege for persons with disabilities; (b) the Web site is a method of providing the travel service’s information to the public, and the Web site’s inaccessibility constitutes a failure to provide auxiliary aids and services necessary to ensure that the information is effectively communicated to persons with disabilities; (c) the Web site’s inaccessibility imposes a prohibited eligibility criteria because it requires people to be able to see text on a computer screen in order to access benefits of Southwest’s travel service; and (d) Southwest’s practice of posting information on its Web site in an inaccessible manner denies persons with disabilities the right to participate in or benefit from the services, privileges or advantage of Southwest’s travel service. ADA Friend of the Court Briefs Filed for Access Now v. Southwest Airlines

What you will notice if you peruse the List of Web Accessibility-Related Litigation and Settlements is that few, if any, mention WCAG compliance in the complaints. When they do mention WCAG, it is merely used to strengthen the complaint. The bulk of the legal complaints revolve around the fact that real users (the complainant) is prevented from performing core system tasks due to the system’s lack of accessibility. To this point, the site’s WCAG compliance doesn’t matter except as it contributes to bolstering the legal complaint. What truly matters, even when attempting to mitigate legal risk, is how usable the system is for actual users.

What this means is that if you think you can do only the bare minimum and call it “compliant”, you’re mistaken. What you need to be concerned with is the experience of the user: give a damn about what you’re doing, and make it usable. Then you’ll be compliant.

I’m available for accessibility consulting, audits, VPATs, training, and accessible web development, email me directly at karl@karlgroves.com or call me at +1 443-875-7343

You don’t have accessibility problems, you have quality problems

On my site and on Twitter, I try to exude positivity and pragmatism. I try to tone down my admittedly strong personality as a way to ensure that what I write is well received. Sometimes I succeed. For the most part I tend to frown upon random bitch sessions about how bad everything is on the web. Complaints do not equate to solutions and solutions are what matter, as I’ve fondly alluded to before:

Today I’ve finally had enough and its time we all face the blunt and honest truth: your code sucks. Yes, yours. Stop looking around, I’m really talking about you. Oh, you’re a hotshot developer from a big company? You have 10,000 followers on Github? Good for you. That plus $3 will get you coffee at the nearest Starbucks while you contemplate how this blog post applies to you.

For the last decade my job has been, in one way or the other, to help make websites, web-based applications, SaaS products, desktop & mobile software, and mobile websites more usable and accessible for all. I love what I do because at the end of every day I feel like I’m making a tangible difference in the world. I get to work with big important clients all over the world and if each of them implements even a few of my recommendations, real users of their systems will find those systems easier to use. Hell yes! To paraphrase John Foliot, what I’m trying to do, ultimately, is put myself out of work. If those of us in the accessibility field are successful, we’ll eventually work ourselves out of a job. And every single one of us will jump for joy. The thing is this: so long as developers refuse to give a damn about the quality of their work we will have unbelievable strong job security.

Many developers, including those working for some of the biggest web agencies and biggest companies on earth, appear to have very little understanding of how HTML, CSS, and JavaScript contribute to how an object is created in the browser. They don’t really understand anything beyond the superficial appearance on screen and whether you can interact with it the way they would interact with it. Everything else is out of sight, out of mind. Most developers I’ve come across in my career are self-taught. They learn what they’re expected to learn for their specific role and that usually isn’t accessibility.  That said, your ignorance doesn’t absolve you of the responsibility of doing a good job and accessibility – like security, SEO, cross-platform reliability, and meeting stated business requirements – is part of doing a good job. You don’t know how to do accessibility? Learn it. This is the same expectation people have of you when it comes time to introduce a new framework, new toolset, new library or whatever into your development environment.  In fact, that’s probably how you’ve developed all of your skills, isn’t it?  Somehow expecting developers to create a quality user experience is seen as an unreasonable extra effort. It isn’t. It is part of doing a good job. It is part of caring about what you do, because you care about how people interact with your work – and if you don’t care about the quality of your work, why bother doing it?

I’m available for accessibility consulting, audits, VPATs, training, and accessible web development, email me directly at karl@karlgroves.com or call me at +1 443-875-7343

Ridiculously easy trick for keyboard accessibility

One of the more frustrating things about accessibility is how ridiculously easy most things are to do. While most developers tend to see accessibility as nebulous and time consuming, the truth is some of the most impactful issues are actually easy to deal with. As a case-in-point: consider simple keyboard accessibility for custom controls otherwise activated by click. For the <button> element, you get free accessibility. It appears in the tab order and reacts appropriately to both click and keypress via the enter and spacebar. This is not the case for custom controls, such as those created with DIV and span. Typically you’ll see developers do something like this:

$('#fake-button').on('click', function() {
    //do stuff

The problem with the code above is that it only works when the user clicks the mouse button. So for whatever this button does on click, it absolutely does nothing when the enter key (or space bar) is pressed, which is how one expects to interact with buttons via keyboard. The solution is, obviously, to check for keypress too. BUT don’t do this:

$('#fake-button').on('click keypress', function() {
    //do stuff

That will trigger on any keypress, including the TAB key. For a keyboard user that would be a bit like triggering on mouseover. Instead, you need a function to check the specific key(s):

function a11yClick(event){
    if(event.type === 'click'){
        return true;
    else if(event.type === 'keypress'){
        var code = event.charCode || event.keyCode;
        if((code === 32)|| (code === 13)){
            return true;
        return false;

That function returns TRUE on either click or whenever the space bar or enter key have been pressed. Now all you need to do is this:

$('#fake-button').on('click keypress', function(event){
  if(a11yClick(event) === true){
    // do stuff

Given how simple this is, developers really have no excuse for using only ‘click’ on controls.

I’m available for accessibility consulting, audits, VPATs, training, and accessible web development, email me directly at karl@karlgroves.com or call me at +1 443-875-7343

The no-CURL way to submit a request to Tenon API

A few months ago, I posted Tutorial: Creating a PHP class to use with Tenon.io. Someone asked me “What about servers that don’t have CURL? Here you go. Use the class in that post, but swap out the submit() function for this:

function submit(){

    $content = http_build_query($this->opts);

    $options = array(
        'http' => array(
            'method' => 'POST',
            'content' => $content

    $context = stream_context_create($options);
    $this->tenonResponse = file_get_contents($this->url, false, $context);

In fact, using streams may even be faster than CURL!

I’m available for accessibility consulting, audits, VPATs, training, and accessible web development, email me directly at karl@karlgroves.com or call me at +1 443-875-7343

This one secret will save you $100,000 on accessibility

I’ve historically been very critical of the various Business Case arguments for accessibility given their lack of actual evidence. There’s one business case argument that I think is rock solid: The cost of remediation.

The cost of remediation actually has two faces: The actual time-on-task it takes to fix issues, of course, but also the lost opportunity dollars that come from development staff time being diverted to bug fixes rather than being spent on new features. We’ll skip past the opportunity cost for now because the actual remediation cost is enough to get our point across anyway.

average cost per defect = ((number of devs * number of hours ) * fully loaded dev cost per hour) / total bugs to be fixed

The above gives us the average cost per defect. It is mostly dependent on two factors: time to fix the average bug and the number of bugs fixed. The fewer bugs fixed will raise the cost-per-bug, as the typical case is that developers can (and will) be able to fix multiple bugs of the same type rather quickly. But there’s no getting away from the fact that the more bugs to fix, the more money it will cost.

So what’s the cost? That depends a lot on how accessible you are starting off! Across 800,000 tested URLs, Tenon.io has logged an average of 42 accessibility issues per page. This number is statistically significant and automatically-testable accessibility issues don’t make up the entirety of possible issues. This indicates that the full sitewide remediation of all issues could be very expensive and time consuming. In fact, the $100,000 number in this post’s title isn’t made-up. It is actually an estimate of the cost to fix bugs on a project I’ve worked on.

Of course, there’s the option of not fixing the bugs. There may be instances where, through effective prioritization, we decide not to fix some issues. The overall truth remains that avoiding the bugs in the first place is by far the cheapest. The ROI argument here is easy: how many bugs we can/ should avoid, what are their costs to fix and – while we’re at it – what amount of Risk are we avoiding?

Doing it right the first time has instant ROI.

I’m available for accessibility consulting, audits, VPATs, training, and accessible web development, email me directly at karl@karlgroves.com or call me at +1 443-875-7343

The form field validation trick they don’t want you to know

Yes, that was a purposefully click-bait headline.

One of the most frustrating things for users is unclear or unintuitive form constraints. My personal pet peeve are phone number, credit card, or SSN/ EIN fields which ask for numeric-only entry. While it may very well be necessary that your field use only numeric data, you don’t have to offload that requirement to the user. If, for instance, your field collects a North American telephone number, you know that a valid telephone number consists of 10 numeric characters. Instead of offloading the numerics-only constraint to the user, you can easily and simply strip the non-numeric characters yourself before then validating the string length. This seems far more intelligent and certainly more user-friendly.

Here’s how

Because so many things require string manipulation most, if not all, programming languages have some mechanism of finding, substituting, or removing sub-strings, often through the use of Regular Expressions. Here are some examples, shamelessly stolen from Code Codex:


#include <string.h>  
while (i != strlen (buff))  
    if ((buff[i] >= 48) && (buff[i] <= 57))  
        buff_02[j] = buff[i];  


removeNonNumbers :: String -> String
removeNonNumbers = filter Char.isDigit


static String numbersOnly(String s) {  
    return s.replaceAll("\\D","");  


s.replace(/\D/g, "");


s{\D}{}g; # remove all non-digits


preg_replace('/\D/', '', $string);  


import re  
re.sub("\D", "", s)  


s.gsub(/\D/, "")
I'm available for accessibility consulting, audits, VPATs, training, and accessible web development, email me directly at karl@karlgroves.com or call me at +1 443-875-7343

(re) Announcing A11yBuzz.com

On July 30, 2011 I posted My Challenge to the Accessibility Community: We Need an Accessibility Body of Knowledge in which I lamented:

The fact that there is no single source to get good, clear, peer-reviewed information on this topic is, in my opinion, a very huge barrier which prevents “outsiders” from participating in accessible development.

The post was received favorably by some in the accessibility community who agreed. Others felt differently, asserting that there’s already a lot of information sharing happening on the web as a whole. Private discussions took place among those who were interested in this idea but ultimately no direct action was taken to actually put together a single, cohesive body of knowledge.

In response, I created A11yBuzz as a way to crowdsource a single resource for accessibility information on the web. A11yBuzz was released for public use on January 01, 2012. But, it was never really finished. I wanted to add features that allowed for entries to be voted on and reviewed. At CSUN 2013, Mike Guill and I presented a redesigned version of A11yBuzz which had these features. Unfortunately that version was never finished, either. Mike had a series of relocations, and a new adoption. I had shifted all of my energies to Tenon and A11yBuzz just withered away.

This August, Joe Dolson and I talked about re-launching A11yBuzz as a complete refactor based on WordPress. Joe completely ran with it, using Mike Guill’s redesign and my Day One Theme as a starter as well as some of his WordPress plugins and custom programming, Joe has done an amazing job.

The rest is up to you, my accessibility friends! For the site to be successful, it needs contributions. At this point, the site has a pretty good number of resources on accessibility, but it could be better. To achieve that goal, we need more contributions. If you want to contribute, go to A11yBuzz.com and register to help!

I’m available for accessibility consulting, audits, VPATs, training, and accessible web development, email me directly at karl@karlgroves.com or call me at +1 443-875-7343

One. Simple. Question. (and a follow-up)

Several weeks ago, Bryan Garaventa made a post to the WAI-IG mailing list. The email thread went somewhat sideways, because some list members didn’t “get it” but it died down quickly enough. AccessIQ reignited the issue, wondering “…do web accessibility professionals have a sense of humour?” My response? Clearly the answer is NO. Even when a blind guy (Bryan) tries to make a point through humor, people in the accessibility community go on a ragefest about people “making light of accessibility”.

Instead of productive, collaborative discussion about bringing accessibility into the mainstream, accessibility people are too busy fighting with each other and using social media as a sounding board to name and shame everyone whose products aren’t perfectly accessible. I’ve said it before, we need to put the pitchforks down. We need to understand “perfection” isn’t possible and work on making “better” happen instead. For this, I propose we begin focusing on two very simple questions:

Do you agree that it is acceptable to prevent certain classes of users from using your ICT product or service?

This requires only a one word answer: “Yes”, or “No”. I’ve asked people this question before and I often get answers other than Yes or No. People will say “But that depends on [any number of red herring conditions]” and I always try to redirect to the original question. To move the conversation forward, we need to know whether the other person thinks its OK to discriminate. Hint: Nobody thinks that is OK. Or, at least, they won’t admit it in public.

Follow-up: What can you do now to ensure that access for all people is improved?

From there, we can assume that the other party is prepared to move forward with accessibility. We don’t need to continue rambling on about the various reasons why accessibility is good. We’ve gone past that and now its time to act.  But, it isn’t reasonable to expect perfection immediately. It also isn’t reasonable to expect that the necessary resources and knowledge will just magically appear out of nowhere. So the follow up is: given your current knowledge and resources, what action can be taken immediately that will deliver a demonstrable positive result for users? Incremental betterment is far better than impatient expectations of perfection. As we make improvements to what we do and how we do them, we can make things better.

While I’ve previously spent a lot of time writing about selling accessibility I really think the most effective approach is to limit the “selling” to one question. We don’t need to sit there and spin our wheels with red-herring distractions like ROI. Is it right to discriminate or not? No? Awesome. Now what are we going to do now to make sure we don’t discriminate? Do that.

Stop selling. Start leading

I’m available for accessibility consulting, audits, VPATs, training, and accessible web development, email me directly at karl@karlgroves.com or call me at +1 443-875-7343

Longdesc – Where are the alternatives?

Non-text Content is “any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language”. Mostly what comes to mind when discussing non-text content are audio/ video content, images, or other graphical content not necessarily image-based. WCAG 1.1.1 Calls for alternatives for non-text content. For basic images, presented in the <img> element, the ‘alt’ attribute is the most-frequent means of providing an alternative. The content you place in the ‘alt’ attribute may vary depending on the image and context but generally “…the general consensus is that if the text alternative is longer than 75-100 characters (1 to 2 sentences), it should not be considered a short text alternative and should not be presented using the alt attribute or the figcaption element…”. In the vast majority of cases, that amount of text should cover you rather well in providing a good, clear, and concise alternative for the image. But what if the image is complex? What if the information portrayed in the image can’t be described effectively in 75-100 characters? One suggestion is to use the longdesc attribute.

Historically, support for longdesc has been rather spotty. Back in 2000, WCAG 1.0 recommended using longdesc, but also acknowledged the lack of browser support and also recommended the use of what was called a D link. In practice, the D link probably saw more popularity than longdesc and its recommendation was pretty pervasive.

Over time longdesc support among user agents has improved, having been added to Opera, IE, and Firefox. Movement toward supporting longdesc has been made by Chrome’s dev team. Screen readers such as JAWS, Window-Eyes, NVDA, and Orca support it, as do many authoring tools. That hasn’t stopped the pushback on longdesc and Apple has stated they have no plans to implement longdesc.

longdesc (as implemented) is a poor solution to a real problem

There should be no argument in anyone’s mind that there’s a real issue that needs to be addressed: effective and informative alternatives to complex and/ or detailed non-text content. There are loads and loads of images on the web which convey things like charts, graphs, and diagrams. How do you describe, in 75-100 words, the components and operation of a 4-stroke engine?

Example complex image: cutaway of 4-stroke engine

Easy. You can’t. There may be other ways to describe this, such as in the same page as the image. Try getting that one past the content people. But longdesc – in its current form – is a crappy way to do this. See, the problem with longdesc is that it is basically only useful for screen reader users. Longdesc essentially locks out sighted users entirely. The image with longdesc isn’t placed in the tab order and there’s no visual affordance provided to indicate the existence of longdesc. Firefox’s implementation provides access to the long description via the context menu which is great if you knew the image has a long description, which you likely won’t if you’re not a screen reader user. As it stands, longdesc is wholly useless to people with cognitive disorders, which is another population that could seriously benefit from long descriptions.

Where are the alternatives?

Ultimately, I have to agree with many of the criticisms of longdesc. But that doesn’t mean I agree with the notion of just doing nothing, either. The fact remains that some images require longer descriptions than the 75-100 characters available to the alt attribute and despite the protestations of longdesc’s detractors, there don’t appear to be any proposed alternatives for implementing a mechanism of supplying long descriptions for non-text content, beyond saying “Fuck it, leave it to the web authors to figure that out”.

Two ideas

Unfortunately, that’s where we are right now if we want a viable means of supplying long descriptions. With Safari/ VO support out of the picture, we can’t rely on partially supported features. Or can we?

See here’s the thing about HTML: You can actually put whatever you want in your markup. You can make up your own elements or attributes, you can even add bogus values in attributes. That doesn’t mean it’ll do anything, but you can put it there. For instance, you can add the old <blink> tag to your page, but it won’t actually blink anymore in any major browser. Similarly, you can still add longdesc to your images. The attribute will still be in the attributes node of the image object. Because it is in the DOM you, the developer, can do something useful with it. Here are two possible ideas:

Dirk Ginader’s longdesc plugin places an unobtrusive icon over the image which represents a link to the long description. Activating the link replaces the image with the long description. Dirk hasn’t done much continued development on the plugin, but its a great starting point and I like the concept.

Today, I created a new Polymer-based Web Component called image-longdesc. It is basically just a different approach to my image-caption component. It places a link to the long description under the image. Remember my 4-stroke engine example? Here it is with a caption and longdesc link:

Screenshot: Prior engine example as a web component with caption and longdesc link under the image

Are these ideas perfect? I don’t know. What I do know is that we’ve yet to see longdesc’s detractors come up with any viable alternatives that address the very real need for suitable alternatives to complex non-text content.

I’m available for accessibility consulting, audits, VPATs, training, and accessible web development, email me directly at karl@karlgroves.com or call me at +1 443-875-7343