Karl Groves

Tech Accessibility Consultant
  • Web
  • Mobile
  • Software
  • Hardware
  • Policy
Telephone
+1 443.875.7343
Email
karl@tenon.io
Twitter
@karlgroves

Accessibility Business Case: Spending your money intelligently

Frequent readers know I write a lot about the business case for accessibility. In fact, 5 years ago I published a series of posts called Chasing the accessibility business case. The first post in the series outlined the core considerations for building a business case. In general, the value of an effective business case should be measured against one metric: Profit. Profit is Income minus Expenses. If your business case can’t be articulated in a way that shows that it increases profit, it isn’t a business case. The more profit, the stronger the business case.

There are scores of other KPIs that you may want to measure as a business, but most of those that contribute to a “business case” are really more granular measures of income and expenses. For instance, one of the metrics we measure at Tenon is called “CLV” or “Customer Lifetime Value”. This is a measure of how much income is derived per user during their relationship with Tenon. We can increase CLV by keeping our customer happy so they stay longer or by increasing the amount we charge to each customer (or both, of course). But CLV doesn’t provide a full glimpse into income. For instance, adding more customers doesn’t necessarily mean extra income if the CLV goes down. Also, if CLV goes up we can make more money with less users. CLV is a useful metric though. Increasing CLV is a good way to improve income, especially if CAC (Customer Acquisition Cost) lowers or stays the same. Lowering CAC, increasing CLV, and growing the number of total customers is the ideal situation for a company like Tenon.

Increasing income doesn’t happen on its own. Marketing and sales are vital to a business’s existence. This is why the Customer Acquisition Cost is so important. For instance, if your company spent $2.5 Million on a billboard in Times Square how many customers would you get from that? More importantly, would the revenue from those customers meet-or-exceed the $2.5 Million you spent to get them? Then there is perhaps the most important consideration: could you spend less money to get the same amount of customers? 

What does this have to do with accessibility?

Accessibility costs money. I believe that making things accessible should be required because it is the right thing to do. At the same time we must acknowledge that doing so costs money, both directly and indirectly. This is the problem that others attempt to address with their various business case arguments. Our existence, as either internal or external accessibility persons, costs money. Our work costs money. Implementing our recommendations cost money. What the company invests in us must have a return value. That return can be in the short term or the long term, but one thing is certain: expenses that don’t provide value are sure to be eliminated.

As a business owner myself, every penny I pay to another human to do work must have a benefit that is equal-to-or-greater-than the amount I pay for their services. That can be a short-term benefit or a long-term benefit and choosing to not do something could be just as beneficial as doing something. The time necessary to get something done has value, and the time during which nothing gets done has value.

So if a consultant is billing me $200 an hour and doing 100 hours of work, I’m paying a total of $20,000. My primary concern is whether am I going to get at least $20,001 in ROI from that work. Can I spend $20,000 on something else and get higher ROI? Can I get that ROI in less time? During that 100 hours am I also incurring other costs along the way? How long will it take to recoup those other costs? Can I get the same benefit at a cheaper cost?

This dance between cost vs. benefit occurs at every level and every department across the organization and the importance of this is amplified in the private sector. Every single person involved in accessibility should be able to answer to the specific business value they offer to their employers. This is where experience and knowledge must translate into action. This is why the accessibility consultant must be the absolute best at what they do and what they deliver must be immediately actionable. Massive reports are out, close integration with the team is in. Accessibility professionals must be leaders and agents for positive improvements by providing guidance that is immediately actionable by their customers. Not all accessibility problems are equal and the customer deserves the ability to prioritize accordingly.

The new contract between consultant and client

I’ve already touched on this a bit in the post “Accessibility consulting is broken“.The consultant must understand that they’re being paid to understand the customers’ environment and problems and that they must offer the most effective advice and service. The customer has chosen the consultant over all of their other options, because the customer believes that the consultant can help them address their accessibility problems and that addressing those accessibility problems has a value greater-than-or-equal-to the consultant’s fee. If that consultant was a developer, the customer would have long term benefit from the deliverables in the form of working code. In other words, if the customer’s software has bugs or needs new features, a developer can write code that fixes those bugs or adds those features.

What often gets delivered by a consultant is an “audit” – a long form document outlining all of the places where the customer’s current system needs to be improved in order to become accessible. I’ve worked for 4 of the biggest accessibility consulting firms and have seen the work of many others. Everyone does auditing in their own unique way. Each has varying degrees of detail and advice. All of them, of course, hope that their audit deliverables provide sufficient guidance to assist the customer in remediating their systems. But is an audit what clients really need?

What is the real value of an audit? How immediate is the return on that investment? All consultants will boast of the qualities of their audits and the skills of their reviewers, but is an audit actually what a customer needs? How valuable is that big pile of paper you get? How soon can that audit become actionable by internal development staff? More importantly: how many times was a customer sold an audit merely because that’s what they thought they needed?.

Maybe the customer got that idea from their lawyers, which is increasingly the case these days. Or maybe they got that idea because they read about accessibility audits on some blog post somewhere. Maybe they think that’s what they want because they don’t know any better. Regardless of why they got that idea, the consultant should first get a real understanding of what the customer needs before selling anything to them.

A skilled consultant will already have enough experience to know – at a high level – what most customers will need in a first engagement. In fact, a skilled consultant can tell you these things before they even look at your software that your design, QA, and development practices don’t include accessibility. A skilled consultant can tell you that even though you might have great developers on staff, they know far less about accessibility than they think they do. A skilled consultant can tell you that there are important internal challenges preventing long-term success in accessibility. (see “Ten blunt things…”). Furthermore, a skilled consultant should be able to predict, even after a cursory glance, what types of accessibility issues your system probably has. An audit would serve to merely document specific instances of those predictable issues.

The new contract between consultant and client must take into consideration the fact that the client needs and deserves a level of service that makes the greatest improvement possible in the shortest amount of time. Maybe that is an audit. Maybe not. Maybe that is training. Or maybe it is having the consultant roll up their sleeves and start writing accessible code. Chances are, the real solution is going to be a mixture of all of these. One thing’s for sure: selling the customer something they think they need vs. what they actually need is poor service. In my opinion, so is just delivering an audit.

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

Utilitarianism, Pragmatism/ Practicalism, and Perfection

I feel strongly that every person has an intrinsic sense of what is “right” and what is “wrong”. Parents can observe this in their children when they’re very young. Take a toy away from a toddler and the result will be a howling child. Sigmund Freud would identify this as the ‘Id’ in action. The child’s desire keep that which is theirs is disrupted. No longer having the thing they want is an injustice where justice, in this case, is having what they want. As the individual develops, outside forces influence the developing child’s sense of right and wrong to evolve. The values of our parents, our peers, and society as a whole, influence that evolution. Our own experiences, the influence of those values, and forces like pleasure, pain, power, and weakness combine to steer each person’s moral compass. When value systems differ, conflicts arise.

In philosophy, ethics is a field in its own, tackled earliest by people like Confucius and Socrates – the former being one of the first to express what those of us in the West refer to as the “Golden Rule”. Nietzsche, on the other hand, would classify the Golden Rule as an expression of “Slave Morality”. Good arguments abound for everything from Stoicism to Anarchism. Ethical philosophies range from pessimistic about human nature to optimistic and idealistic.

For myself, I’ve landed on Utilitarianism as an ethical philosophy:

  • Achieve the greatest overall pleasure
  • Avoid the most overall pain

Utilitarianism is not simply a quest for pleasure. It is not Cyrenaic hedonism where immediate gratification is the only goal. Personal pleasure is only part of the story. “It is the greatest happiness of the greatest number that is the measure of right and wrong”, says Jeremy Bentham. In other words, the amount of pleasure attained and the amount of pain avoided is how we measure the utility of an act. In other words, “Good” is synonymous with pleasure and “Bad” is synonymous with pain.

  1. Achieve the most pleasure for the self, while creating the least pain for the other
  2. Achieve the most pleasure for the community, while creating the least pain for the state
  3. Achieve the most pleasure for the state, while creating the least pain for the country
  4. Achieve the most pleasure for the country, while creating the least pain for the continent
  5. Achieve the most pleasure for the continent, while creating the least pain for the globe
  6. Achieve the most pleasure for the globe.

An end goal of maximizing pleasure may seem extremely simplistic. How can you accomplish hard things if you only focus on what feels good? Anyone who’s gotten drunk, done drugs, or had sex knows what “feeling good” really feels like. Although I’ve never done hard drugs, I’ve heard plenty of people talk about what an amazing ride cocaine or heroin are. So why don’t I just kick off a heroin habit? Because maximizing short-term pleasure in that way risks long-term pain. Those same people I know who tell stories about doing hard drugs also have their own stories to tell about intense long-term pain: homelessness, overdoses, and death. Three of my best friends in high school wound up homeless and another three overdosed and died. Clearly focusing on the short-term without considering the long-term is a terrible idea.

Pragmatism/ Practicalism

A lot of times when people mention the word pragmatism, they really mean practicalism – that an action should be chosen based upon what choices are realistic. In other words, people who say they approach things pragmatically most often mean that they choose to do what is realistically achievable given the current situation. In theory, this seems like an excellent approach. Instead of seeking “perfection”, the practicalist chooses some progress over no progress. “The Perfect is the enemy of The Good”, says the practicalist. Unfortunately, the end result isn’t that the best possible action is chosen but merely the “good enough”. The practicalists resign themselves to moderate short term success in order to wholly avoid the pain of conflict. Being resigned to the idea that they’ll never achieve perfection, they abandon the idea altogether and accept whatever they can get right now.

Perfection should always be the goal

The utilitarian knows that they may not ever be able to achieve perfection but that the goal of maximizing pleasure while minimizing pain is still one worth pursuing at all times. Giving up is not – ever – an option. Achieving the best possible outcome may be an incremental effort and may take a very long time. There may be setbacks and there may be times when the pain is more than the pleasure. None of this makes accepting compromise anything more than a temporary option. This is exactly why I do what I do for a living and what drives a majority of my own decisions.

Utilitarianism in action

One example of this can be seen in Tenon‘s prioritization algorithm. Whenever tests are run by Tenon, each individual result is scored based on a handful of factors:

  1. Impact on the user
  2. Impact on the interface
  3. Ease & speed of repair

Each of those factors is weighted in a way that provides an appropriate level of gravity to each one, with “Impact on the user” given highest importance. The end result is a ranked list of issues that, when used to steer remediation, will result in the greatest positive impact for users in the shortest amount of time. In other words: by fixing the highest impact issues is the same as “maximizing pleasure”.

Making these changes with the least impact on the interface and highest ease & speed of repair is the same as “minimizing pain”. In this way, every single time a test is run, all of the issues are scored to make it very clear which things must be fixed first. Incrementally the system becomes improved by always focusing on the most important stuff first. This doesn’t necessarily achieve perfection. There will always be other things that happen along the way, up to and including completely replacing the system with a new one. But until that time comes, we can continue to push forward by maximizing the positive impacts of our efforts.

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

5 Approaches to Dealing with 3rd party (in)accessibility

I have an embarrassing confession to make. Tenon has accessibility problems. Some of them are our fault. Some of them are based on conscious decisions. Some of them are due to our use of 3rd party content and controls. But regardless of where the issues come from, once they’re on our system they’re ours to deal with. Let’s talk about 5 ways you can deal with inaccessible code.

Before I continue, I want to point out one option that isn’t listed below: “Leave it as-is”. Historically, legal cases around inaccessible ICT have mostly exempted third party content, but that often depends on the nature and source of the third party content. Platform accessibility issues are never exempted as far as I know. So if you’re an e-retailer being threatened with a lawsuit, you can’t deflect liability over to your vendor if their platform is the basis for your entire presence. As a general rule: that which is hosted on a domain that you own is your responsibility.

If it is already on your system

Remove it

One of the biggest sources of accessibility issues on the Tenon website was the “McAfee Trustmark” we had in the footer of each page. The intent for having it there was for visitors to know that we take security seriously. Unfortunately, it doesn’t appear that the folks at McAfee took accessibility seriously. The service itself is pretty cool but at $149 a month, it didn’t add much value. Add the non-existent value to the accessibility issues, and it was an easy decision for us. We took it off and removed a pile of accessibility issues. If a feature doesn’t have a direct user benefit and has accessibility issues, the decision is easy: dump it and move on.

Replace it

Sometimes you can’t just decide to do away with a feature altogether. When it comes to widgets and add-ons to sites based on WordPress or Drupal, there are often alternatives available that you can try. Another case where I’ve seen this work is with features that allow you to add your company’s job postings. Often the best approach is just find a replacement that meets your business goals in a more accessible manner. This approach obviously means you’ll need to invest a fair amount of time searching for an accessible alternative but let’s face it, that’s an exercise you should’ve done the first time around.

Fork it and fix it

On the homepage of Tenon, we use Code Mirror. We discovered some issues with keyboard accessibility and created our own fork to fix them. Some issues remain that we want to fix before issuing a pull request. For now, we have at least made some improvements and are planning on doing more. At times this approach may help deal with immediate issues but it can also lock you into your own forked version. The absolute best approach in this case is to issue a pull request with your improvements. This not only helps you and your users but also helps others who are also using the same product.

Improve it after the fact

What if what you’re using isn’t open source? What if your vendor has no plans to improve their product? It may be possible to add JavaScript to your site that fixes existing problems in code you don’t own. This is actually something I demonstrate at The Mother Effing Tool Confuser. At a high level, if you need a quick fix for a known issue you may be able to add some JavaScript to fix the issue. This is the basic principle behind Deque’s Amaze product. SSB BART Group has a similar product, and Simply Accessible does custom “overlay” work for customers. One of the big downsides of this approach is that it is incredibly brittle. If you make any changes to the underlying code, you’ll undo the “fix”. Simply Accessible are very transparent in disclosing this for customers and up front about the fact that this is a temporary approach, which I think is awesome. This is definitely an effective short term approach.

Push on the Vendor

Over at the Tenon blog, I documented this a little bit when I discussed build vs. buy is even harder when you care about accessibility. In our case, Intercom.io is an extremely valuable service for use to help our customers. At the same time, we recognize that providing excellent customer service in real time is an important differentiator. No other accessibility tool vendor allows you to talk to support staff directly in real time. A large number of customers have told us that this level of support solidified their decision to go with Tenon. Intercom has had a direct ROI for us. Nevertheless, we can’t just look the other way on the product’s accessibility issues. We’ve communicated our concerns with the vendor and will continue to do so until either they address accessibility or there’s a suitable accessible alternative. We’ve even toyed with the idea of making our own.

Avoiding the problem

Of course not choosing the inaccessible product is the best approach. Unfortunately, most people don’t realize the product is inaccessible until it is too late. One of the ways that people in the public sector have tried to deal with this is by requiring a document like a VPAT or GPAT. Vendor statements on accessibility are often laughably poor and may not even exist. This leaves you with only one choice: Test it yourself or have someone else test it. Yes, I’m suggesting that you test someone else’s product before you choose it – the same as you would to verify that it meets your business needs, privacy needs, and security needs.

Determining the level of effort you expend on doing this testing is proportional to your exposure to risk and how much impact the specific product will have on that risk. In many cases, you can get a good idea of how accessible the product is by doing only a handful of tests. The results of such testing will be less-than-scientific, but will definitely give you a strong understanding of whether you should bother moving forward with that product or look elsewhere. Once you’ve narrowed down your choices, you can decide whether a full-blown audit is warranted.

It is impossible – and a horrible business decision – to roll your own code for every system you use and every piece of functionality on that system. A lot of things go into deciding what 3rd party product you should use. Accessibility needs to be one of those things you consider strongly, especially in the United States where litigation is happening at an unprecedented pace. There’s no such thing as “perfect” accessibility, but hopefully this post helps provide guidance in choosing the right product and how to deal with any lingering accessibility issues once the choice has been made.

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

Accessibility Lawsuits, Trolls, and Scare Tactics

There has been a lot of discussions in Web Accessibility circles around “ADA Trolls” this year. The massive uptick in web-accessibility related lawsuits that began around October 2015 is certainly a new trend in this space. While lawsuits around web accessibility are certainly not new, the frequency and volume we’ve seen in 2016 definitely is.

A few days ago, 60-Minutes aired a segment on what they refer to as “Drive-by Lawsuits“. In reaction, Lainey Feingold framed the segment on 60-Minutes as a “Hit Piece” – and rightly so, in my opinion, because it gave the impression that people with disabilities are being used as dupes for unscrupulous lawyers.

Not even a few days old, the 60-minutes segment is already being used to argue against making websites accessible

There are a lot of scum bag lawyers taking advantage of these laws and are actively going after small businesses that are “not in compliance”.

David Bekhour’s response to the 60-Minute segment Anderson Cooper: What Were You Thinking? is a must-read, but I’d like to also throw a few brief thoughts into the mix.

The Objective Facts about Drive-by Lawsuits and Trolling

In the United States, a few dozen ADA-related lawsuits are filed in US Federal Courts every day. (Search PACER for Case Type: 446 American with Disabilities and 42:12101 Americans w/ Disabilities Act (ADA)) for a list. If you were to download a full list of all of those lawsuits, you’d begin to see a handful of names appear repeatedly throughout the list. Some of those repeat names will be Plaintiffs’ attorneys. Some of those repeat names will be the plaintiffs themselves.

Making a judgment about which of the law firms listed are engaging in “drive-by” lawsuits simply by their frequencey of appearance would be making a hasty assumption. Law firms or even individual lawyers within law firms often specialize in specific practice areas. For instance, when my wife and I needed a lawyer to deal with our daughter’s IEP stuff, we went to a lawyer who specialized in that area. It would be silly for me to hire that same lawyer for doing contract negotiation stuff for Tenon, because that’s not her area of expertise. Similarly, there are lawyers who specialize in Disability Rights. There’s even a Disability Rights Bar Association:

The Disability Rights Bar Association (DRBA) was started by a group of disability counsel, law professors, legal nonprofits and advocacy groups who share a commitment to effective legal representation of individuals with disabilities.

The lawyers listed in PACER as having filed the suits are likely to simply be doing what lawyers do for any other type of lawsuit. Lawyers, at least in my experience, are generally not quick to file suit. Some are, of course, but usually there’s a lot of other stuff that has happened before the suit was filed. Strategically-speaking trying to resolve a conflict before filing the suit is a much smarter approach to victory. Simply put: there’s no reason to believe that a plaintiff’s lawyer is engaged in “drive-by lawsuits” simply because a firm that specializes in disability rights has filed a lawsuit.

When it comes to the named plaintiffs themselves, that might be trolling. Looking at the list of lawsuits, you will see certain plaintiff’s names very frequently. Some law firms file suit on behalf of the same plaintiffs over and over. The 60-Minutes piece discusses some of this, and I have to admit that this definitely gives the impression of unscrupulousness.

The missing pieces to truly understanding the situation

In other words, even if we assume that each Defendant in the ADA suits was unique, less than 0.5% of retail businesses or restaurants were sued in 2016. They were sued by 0.003% of the population of people with disabilities. No matter how you use the numbers above, there’s no support for any claim of an epidemic of ADA lawsuits sweeping the country. Yes, there are some people who are clearly trolls. I think it is safe to say that the folks who’ve filed > 50 lawsuits this year are probably trolling. They account for 1.8% of the plaintiffs. On that basis alone, 60-Minutes should be ashamed for being sensationalist in its reporting.

I realize the above doesn’t address the epidemic of threats and shakedown letters around Web Accessibility over the past year. No data exists to provide exact numbers on this activity, but I assume less than 1000 of those demand letters have been sent. Even if we doubled that to 2000, that’s still around 0.01% of the websites in the United States.

Accessibility Matters

Since my site is mostly about web accessibility: If you don’t have to use the Web with a screen reader or without a mouse, you really don’t know what it is like for people with certain disabilities to try use most websites. If you don’t believe what I say about the difficulties, unplug your mouse for the day. Still not convinced? At Tenon, we’ve been inspired to do some investigating into error patterns and will be sharing some of our findings at CSUN 2017. Nater Kane and I will be presenting on Data-Mining Accessibility: Research into technologies to determine risk and Job van Achterberg will discuss Automatica11y: trends, patterns, predictions in audit tooling and data based on data from the world’s top websites. Below are just a taste of the findings that will be shared at CSUN:

  1. There are nearly 70 automatically detectable issues on each page of the web – before accounting for contrast issues
  2. Color contrast issues are, by far, the most pervasive issues
  3. 28% of all images on the web have no alt attribute at all.
  4. Another 15% of alt attribute values are completely worthless things like “graphic”
  5. role attributes, when used, are equally likely to be used wrong – for arbitrary string values that have no basis at all in the ARIA specification
  6. 81% of buttons on the web have no useful text for their accessible name

Beyond raw numbers, it is important to remember that this is a civil rights issue and accessibility both in the physical world and on the Web is, in a word: abysmal. There is no epidemic of people with disabilities going from website to website suing people. The epidemic is that we’re 19 years after the formation of the Web Accessibility Initiative and yet developers at the largest websites in the world can’t figure out the alt attribute or how to put meaningful text in buttons. Because if you do get sued, nobody will have pity on you for doing subpar work.

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

5 talks in 6 days in 3 countries starting this Saturday

Holy cow. I can’t believe it. Tomorrow I start a trip that has been several weeks in the making. Now that it is around the corner I’m both excited and anxious! Even more, I’m truly humbled that such a trip is even possible.

Each of these events are open to the public. If you’re in one of these cities, I hope to see you!

  1. November 5, 2016 – Toronto, Canada (9am – 5pm)
    Accessibility Camp Toronto (#a11yTO)
    OCAD University – 100 McCaul Street, Toronto Canada
  2. November 7, 2016 – Berlin, Germany (Noon – 5pm)
    Accessibility Club #4
    Contentful – Ritterstraße 12 10969 Berlin Germany
  3. November 8, 2016 – Amsterdam, Netherlands (6pm – 9pm-ish)
    Fronteers Monthly Meetup
    Desmet Studio’s – Plantage Middenlaan 4A 1018 DD Amsterdam Netherlands
  4. November 9, 2016 – Düsseldorf, Germany (5pm – 8pm)
    Trivago Academy
    Trivago – Bennigsen-Platz 1 40474 Düsseldorf Germany
  5. November 10, 2016 – Nürnberg, Germany (Noon – 5pm)
    Accessibility Club #5
    tollwerk – Klingenhofstraße 5 90411 Nürnberg Germany

Some tough love: Stop the excuses, already.

Over a year ago, Dale Cruse called me “militant” about accessibility. I know I use strong language at times, but I actively try to have a softer touch. I think he meant it kindly anyway, but I worried a little. “Do I come off too strong?” I wondered. I get a lot of compliments on my blog, so I felt conflicted. Could I be alienating people, too? I think about this kind of thing a lot, actually. But maybe the truth is that others in the accessibility field aren’t confrontational enough.

Today, UC Berkeley posted A statement on online course content and accessibility which contains the following paragraph:

In many cases the requirements proposed by the department would require the university to implement extremely expensive measures to continue to make these resources available to the public for free. We believe that in a time of substantial budget deficits and shrinking state financial support, our first obligation is to use our limited resources to support our enrolled students. Therefore, we must strongly consider the unenviable option of whether to remove content from public access.

The statement by UC Berkeley’s Public Affairs department is, in a word: Bullshit. It is bullshit aimed at making it seem as though accessibility is burdensome and that somehow accessibility requirements are vague.

They say, early in their statement: “Despite the absence of clear regulatory guidance, we have attempted to maximize the accessibility of free, online content that we have made available to the public.” (emphasis mine).

The implication that accessibility for online content is a new topic in higher education – and therefore something UC Berkeley didn’t know about – is a fabrication. As many of you know, I maintain a list of web accessibility related litigation and settlements. The first time the DoJ sued a Higher Education institution was in 2003. NFB sued a handful of schools in 2009. The DoJ and US Dept. of Education’s OCR have been very active over the last few years – enough so that it is a very frequent topic of conversation at accessibility conferences.

If for some reason UC Berkeley needs to “implement extremely expensive measures” to retroactively make this online content accessible after the fact it is because they didn’t give a shit about accessibility from the beginning. That’s their fault, plain and simple, and has nothing to do with any sort of new requirements.

It is time for some tough love

The first version of WCAG came out in 1998. WCAG 2.0 came out in 2008. If you do work for the US Federal Government, Section 508 came out in 1998 and the new version is due soon. At this point, this isn’t new. These requirements aren’t new. The methods of achieving compliance isn’t new. The core Web technologies necessary to make web content accessible are not new. The needs of users with disabilities aren’t new. If any of these topics are new to you, that’s fine. Fucking learn them.

Do you know what union electricians do whenever a new electrical code comes out? They hold classes and learn them. Do you know what accountants do when new tax laws come out? They go to classes and learn them? Why? Because knowing what the hell you’re doing is important to doing a good job.

Whether you like it or not, your company or organization is required by law – explicitly stated or not – to provide ICT products and services that are accessible to people with disabilities. If your work is not accessible, it does not meet the necessary quality standards. Learn how to do it and stop making excuses.

Get your VPAT/ GPAT in a hurry

I get several emails per month from Government Contractors looking for help writing a VPAT or GPAT document. Chances are this is the result of good SEO on my blog post Why a Third Party Should Prepare Your VPAT/GPAT. Unfortunately a lot of these contacts follow this pattern:

Hi Karl, I’m from XYZPDQ Corp. and we’re getting ready to submit an RFP response to the ABC Agency and they’re asking us for a VPAT/ GPAT. The responses are due in 3 days. Can you help us?

I got 3 such emails this past week, one of which on Sunday, with a due date for their proposal being, apparently, that evening.

The short answer to this is “No”.

There’s another point that needs to be made, however, about why this is a really really bad idea. If someone tells you they can turn around a VPAT or GPAT in that amount of time, RUN. They are going to risk not only the contract but possibly a load more.

Why turning around a VPAT/ GPAT in a hurry is a horrible idea

Everything I said in the original posting is still true.

  • Preparing a VPAT/ GPAT requires extensive knowledge of Section 508
  • The information in the VPAT must be based on comprehensive review
  • The information in the VPAT should be as objective and unbiased as possible
  • The VPAT becomes part of the procurement

First, the kind of person with enough skills to fill out a VPAT/ GPAT correctly does not have the time to interrupt whatever they’re doing to write up a VPAT/ GPAT. This is especially true since accurately writing the document needs to be based on a comprehensive review. The time to write the VPAT/ GPAT itself might only be a day (or less) but that’s only after the comprehensive review. Depending on the nature of the product, that comprehensive review may take days or even weeks.

The last point in the list above is the most important one. When you submit the VPAT/ GPAT as part of your proposal, it becomes part of it. It should tell you something that when VPATs are filled out at companies like Oracle, they are all reviewed by lawyers before they’re able to be used.

Many people believe that Section 508 requires the government to ensure all of its ICT is accessible. This is a bit of an un-nuanced perspective. Section 508 declares that the government purchase the most accessible product that meets business needs. If there’s only one product that meets business needs and is horribly inaccessible, Section 508 doesn’t prevent them from buying.

Given the above, imagine the following scenario: The government issues an RFP for a type of software that multiple vendors can provide. You submit your response and it includes a VPAT that declares a very high level of compliance with Section 508’s technical provisions. All other things being equal, the agency chooses your product over the competition due to your product’s higher level of accessibility. There’s only one problem: your VPAT isn’t accurate. Come time to deploy the software throughout the agency, it turns out that blind employees can’t use the software at all. Now what happens?

There are a couple of ways that could play out, and most of them are very unpleasant.

  1. The agency can cancel the contract
  2. The agency can refuse to extend the contract when it comes time to renew
  3. The agency can sue you to compel you to meet the claims of your VPAT

Of course there’s always the chance that nothing happens. That depends on the size of the contract and amount of impact the non-compliant system has on the agency. One thing is for sure, once the agency starts getting complaints from employees, you’re going to have a headache on your hands that won’t go away.

Still need the VPAT/ GPAT in a hurry?

I definitely understand the need to get your RFP submission in on time. At this point, you’re probably the only person with the necessary product knowledge to fill out the document. I recommend that whatever you do, you’re honest in your response. Here are some hints.

  1. Do not claim your product “Fully Supports” a provision unless you know for a fact that it does. “Fully Supports” should be reserved for cases where you know that the provision applies and that your product meets all requirements for conformance.
  2. If you have any evidence that your product doesn’t support 100% of the requirements (but supports some) then the answer is “Partially Supports”. Add comments to disclose the problems you’re aware of.
  3. If you have any evidence that your product fails the requirement (or fails more than it meets) then the answer is “Does not support”. Again, add comments to disclose the problems you’re aware of.
  4. If you know that a provision does not apply at all, the answer is “N/A”

In the explanations column, provide honest, concise information to backup your support claim. If you don’t know the answer or don’t understand the requirements for a provision, you’ll need to craft an honest declaration of this rather than make something up.

Final word on your urgent VPAT/ GPAT

Honesty, transparency, and accuracy are the key to avoiding problems. Your next step is to find someone to do an informed assessment and write an accurate VPAT. Do it now instead of waiting until the last minute.

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 best salesman I’ve ever met wasn’t a salesman

I don’t think I’ve met anyone who owns their own business who is truly satisfied with how much they’re selling. For Tenon, sales means new features, so when I’m looking at a backlog of awesome ideas I’m also calculating the time & money it would take to develop those ideas. More sales means more money which means more features. Figuring out the right sales and marketing approach is something I wish came easier. Thinking about this recently I was reminded of the best salesman I’ve ever met.

I worked for Bill Killam from 2004 – 2007. Bill runs a small usability consulting firm called User-Centered Design. Bill had worked for UserWorks for a while and had chosen to go solo. Our paths crossed when I was E-Commerce Manager for NASA Federal Credit Union. I was shopping around for some usability help on our website. I had been extolling the virtues of usability for a while but nobody would listen. Suddenly the CEO of the Credit Union came across an article on usability and now wanted to make the website more usable. Bill Killam was one of many usability consultants I contacted off the UPA directory to get a quote.

I must’ve sat through a half-dozen calls discussing what I wanted to do with the website and hearing pitches from sales people. Each sales person followed up with a big fancy presentation brief and a detailed quote. After talking with Bill, he sent over a plain text email. His email contained a paragraph of about 100 words describing what he thought I should do and a price for what that work would cost. No fancy sales pitch, no presentation, no fat project brief. All steak, no sizzle. Sales people might read the above and cringe. Bill himself might read the above and cringe. But to me it was pure genius, because he was the only person I talked to in that process who actually demonstrated to me that he listened to my problem and in that single plaintext email he related to me how his deliverables would address my problem.

Ultimately, I didn’t end up using Bill for the work on the Credit Union website. Instead, I went to work for him. A few months after I started that search for a Usability consultant to help on the Credit Union’s site, Bill hired me to do development work and in that time I got to see multiple examples of his incredible sales skills.

The thing was, Bill actually never really thought of himself as a salesman, which is why he was actually so good. Instead, he was a problem solver. He never tried (at least not that I could tell) to persuade anyone to do anything. He never “pitched” people. Instead, he went into sales meetings almost like it was a project kickoff meeting. He didn’t just “assume the sale”, he actually went into the meetings with the perspective that he already had the gig, he just needed to scope it out properly to give them the right price. He never went into long-winded dialogs filled with superlatives. He never droned on about features and benefits. He listened to the customer, learned what their problems were, and proposed ways to solve those problems.

Sales people are too quick to treat a sales call as an event where they must head off any objections. They think they need to convince the customer to buy. They interrupt customers as soon as they see an opportunity to talk more about their product or service. The problem is that the more time you spend talking the less time you’re spending listening. Listening is how you learn about the customer’s problem. Listening gives you the opportunity to understand the customer’s pain points. The salesperson thinks that their job is to make a sale. It isn’t. The sales person’s job is to determine what the customer’s problems are and present appropriate solutions to those problems. Bill understood that and, as a consequence, never had a problem selling his services.

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

Extreme Accessibility, Revisited

I’m really terrible about responding to emails. I get (and send) a lot of email and lots of it just sits and sits for embarrassingly long times. After CSUN I got a great email with some questions from Vincent François about some of the things I said during my CSUN 2016 presentation “Extreme Accessibility

Vincent had a couple of good follow-up questions to the information I talked about that I wanted to share the answers to:


When bugs are found, tests are written. Programmers have a failed test to focus their efforts and know when the problem is fixed

Vincent included a picture of the above slide and said:

Are you saying that we should create a new test each time we find a bug? In order to, later, focus on the part of the product in which we encountered and created the bug?

My answer:

One of the things about bugs is that once you’ve verified the bug, you actually have two important pieces of information: the details on why it is a problem and what should happen instead. With this information at hand, you can write a test. The test should be an assertion that the code does what it is supposed to do.

Taking accessibility out of the picture, for a minute, imagine we are on Amazon. We have found a bug: when we click the “Add to wish list” button, it actually adds the product to the cart. The first step to fixing the bug is writing a test that tests the following:

  1. Given that I am on a product page
  2. When I click the “Add to wish list” button:
  3. The number of items in the Cart is not increased
  4. The number of items in the wish list increases by 1
  5. The specific product is found in the wish list

The above is the criteria we will use to verify that the bug was fixed. Now we modify our code and test it against the above criteria. We don’t ship the bug fix until the tests pass.

The automated test(s) also ensure that we don’t end up “unfixing” the bug later down the road.

The latter point above is super important. One of the biggest pieces of tech debt I run into are cases where an untested fix gets undone somehow – or worse, has another side effect elsewhere. This is why if someone reports a buggy test in Tenon I ask for the URL of the page they’re testing and use that URL to verify whether i’ve fixed the test bug.

Vincent’s next question was:

With a11y-specific tests, is there a risk to separate a11y from overall quality and in some cases, to choice to postpone them?

This is an important consideration. One of the things I really harp on during Tenon sales demos is the ability to put Tenon into your existing toolset. This is important not just for convenience or efficiency but also (I hope) so that it keeps accessibility from being seen as a separate thing.

Here’s my answer:

The a11y-specific tests I advocate for are only those tests which are directly aimed at verifying an accessible experience. I think in the presentation I used the example of a modal dialog. In a normal development scenario you might have a case where the developer writes a unit test around whether the dialog opens and closes. But there are accessibility implications with modal dialogs including things like keyboard accessibility and focus management. These require their own tests. Thankfully these patterns have been provided for us by the fine folks at the W3C. We can take those patterns and turn them into test cases and these test cases can be turned into automated tests as well. The best part about this part is that we now have accessibility testing backed in to our normal process and not really separate.

Upcoming Event this week

On Thursday August 18, 2016 I’ll be taking part in a panel discussion, "Including Accessibility in the Agile Development Process". Other panelists include Mark Urban (CDC Section 508 Coordinator), Tony Burniston (FBI), and Matt Feldman (Deque Systems)

This FREE will be held at the National Science Foundation at 4201 Wilson Boulevard, Arlington, VA 22230, Stafford 1 Building in conference room 375 from 8:30 to 3:30.

NSF is located in the Ballston area of North Arlington, Virginia, between Wilson Boulevard and Fairfax Drive, one block south of the Ballston-Marymount University Metro stop on the Orange Line. Parking is available in the Ballston Common mall, in the NSF building, and at other area parking lots and garages. Metered parking is also available on the surrounding streets.

Visitors are asked to check in at the Visitor and Reception Center in the Stafford 1 building, on the first floor to receive a visitor pass, before going on to meetings, appointments, or other business at the NSF. Visitors bringing computers into NSF should consult the NSF Computer Security Policy before arriving.

For directions go to http://www.nsf.gov/about/visit/

NOTE! To attend, you must register: https://registration.section508.gov/

Should you use more than one automated accessibility testing tool?

If you’re already aware of Betteridge’s Law, then you know the answer already.

There are some that would argue that you need to use multiple tools because automated accessibility tools can’t find everything and because each tool takes its own approach to testing – including what they specifically test for. This sounds spot on, but misses the point about automated testing entirely.

I believe the primary benefit to automated testing is the efficiency and repeatability they add to the test process. Using multiple tools for testing will only add work, thereby reducing the efficiency benefit of using the tool. In addition, irrespective of the quality & accuracy of each tool, the other problem that arises is differing guidance. Even if they found the same things, each tool will use different words to describe the issues. For instance Tenon will say “This form field is missing a label” and AMP will say “Provide explicit labels for form fields”. While they’ve both found the same issue the user now needs to interpret the messages to determine if they are pointing out the same thing. Add the fact that each tool may find different things, may apply different severities, and may provide different guidance and now you’re really losing efficiency because now you need to determine which tool is right and where. Now you are adding a lot of work for very little benefit.

We already know that there’s only so much that automated testing tools can find. Automated testing isn’t the end but rather the beginning of the process. Tools aren’t a replacement for expert review but rather a supplement to it. Using > 1 tool doesn’t close that gap effectively and instead adds unnecessary work that’s probably time better spent with manual testing. The best approach is to find a tool you like, become an expert user of it, become familiar with how it works (including its shortcomings) and use 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