Karl Groves

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

Beginning a new chapter in this adventure we call life

A little over 4 years ago, I joined The Paciello Group and the last 4 years have been nothing short of incredible. At The Paciello Group, I made lifelong friends and got to do great work. TPG was the first place I worked where there was a universal appreciation and respect across the board. Mike Paciello and the other partners at TPG treat everyone like family, not employees and fostered a great atmosphere in which to work. Internal culture is the most important contributing factor to whether or not you’ll enjoy or loathe your job and the culture at TPG has been amazing.

The Paciello Group has always been supportive of Tenon as well. My co-workers at TPG regularly use it and give me feedback on what I can improve, and some TPG employees were some of the first paying customers because they wanted to support me.

As time has gone on and Tenon has become more popular, the strain of working two full-time jobs has certainly taken its toll. I’ve reached full burnout more than once during the last few years. It became obvious that at some point I’d have to leave TPG if Tenon was to succeed. June 30, 2017 is my last day at The Paciello Group and I’m switching my single full-time effort to Tenon.

I’m both terrified and excited at what the future holds. One thing is for sure, I’m not done with this Accessibility thing just yet. There’s important work to do. I will be offering accessibility consulting services, audits, VPATs, training, and development. For more information, head on over to Services.

Website Accessibility in the United States: What are your requirements under the ADA?

“Compliance” is a word I’m not a fan of. The reasons are many, but the most important reason is that it puts people into the mindset of “What am I required to do?” vs. “What should I do?” – and the latter mindset is the true path to risk mitigation. When it comes to the Americans with Disabilities Act (ADA), the dirty secret is that there are no specific technical requirements for any website. There are no standards which apply to the ADA and unless you’re a State or Local Government, there is no specific reference to website accessibility. Despite claims you may hear otherwise, the unfortunate truth is that there is nothing in the ADA Regulation itself that says you must conform to WCAG or any other technical standard. This is a long-standing source of frustration for accessibility advocates in the United States. Let’s unpack this a little more.

Laws against discrimination on the basis of disability in the United States

There are a number of laws in the United States that prohibit discrimination on the basis of disability. Among them are:

  • The Rehabilitation Act
  • Americans with Disabilities Act
  • Air Carrier Access Act
  • Fair Housing Act
  • Individuals with Disabilities Education Act
  • Twenty-First Century Communications and Video Accessibility Act (CVAA)
  • and more

Among them, only the Rehabilitation Act (Specifically, Section 508 of the Rehabilitation Act) actually has any specific technical requirements. When it was Amended in 1998, the technical provisions and other additions were made to ensure that EIT (Electronic & Information Technology) is accessible for both members of the public and federal employees to such technologies when developed, procured, maintained, or used by federal agencies. Even the CVAA, which is a regulation specifically about technology and accessibility, does not reference any specific technical standards.

Within ADA, there are 3 “Titles”

  1. Employment (Title I)
  2. State and Local Governments (Title II)
  3. Public Accommodations and Commercial Facilities (Title III)

Nowhere in any of the 3 Titles is EIT/ ICT accessibility specifically mentioned except in associated information.

Title II “protects qualified individuals with disabilities from discrimination on the basis of disability in services, programs, and activities provided by State and local government entities.” The DOJ has been pretty proactive in enforcement of Title II as part of Project Civic Access. In their view, if there’s a “service, program, or activity” offered by the State & Local Government, it must be accessible – and that includes any associated EIT/ ICT component. But there are absolutely no technical standards cited, apart from a discussion referencing WCAG that is located in Supplementary Information attached to the Final Rule submission.

Title III, which covers places of Public Accommodations, is essentially the same in this respect. In the Supplementary Information they say “Although the language of the ADA does not explicitly mention the Internet, the Department has taken the position that title III covers access to Web sites of public accommodations.” but, “The Department did not issue proposed regulations as part of its NPRM, and thus is unable to issue specific regulatory language on Web site accessibility at this time.” Title III also references WCAG in this discussion.

So what are your actual, real, honest-to-goodness requirements for Website Accessibility according to the ADA? I don’t know. I’m not a lawyer but it would seem as though there isn’t any specific requirement that a website be accessible according to the ADA. In fact, some have tried to make this argument. Some have even won.

Strategically, it seems like a risky approach. The list of settlements around website accessibility is far longer than the list of defendants who’ve successfully had lawsuits dismissed. If anything, that list of settlements proves that website owners agree that it is too risky. But given the rise in drive-by demand letters, some website owners may be willing to take that risk.

There’s a better way

One of the biggest mistakes that website owners make is in assuming they can wait until they get sued to deal with accessibility. That’s like waiting until you crash before you decide to get the brakes fixed on your car. Using Extreme Accessibility, you can save a ton of money while taking a proactive approach to increasing accessibility and overall quality. Whether or not ADA explicitly states that Websites must be accessible, one thing is for sure: The DOJ believes they should be and so do a whole pile of plaintiffs. Being proactive about accessibility turns the whole thing into a non-issue.

Drive-by demand letters and lawsuit threats do not help advance accessibility

Over the last 18 months, a handful of law firms in the United States have been sending out demand letters to website owners threatening to sue over web accessibility. The trend for this activity was started by the law firm Carson & Lynch out of Pennsylvania and has gathered enough attention that it has been discussed on this blog numerous times. It has also gathered enough attention that other law firms have started playing this game.

Basically, the pattern goes like this: Law firm sends over a demand letter. The demand letter features several well-worded arguments establishing their case. It is often also worded ahead of time as a “Settlement Agreement”. From there, the recipient of the letter has the choice to fight, settle, or do something in-between. In the vast majority of cases, the settlements set forth a number of requirements that include fixing the website (obviously), paying some sort of settlment fee, and paying attorney’s fees.

In my opinion, everything in the above paragraph makes sense. If you have an inaccessible website, you should fix it. If you do not fix your site, you are discriminating against users with disabilities by preventing them from having equal access to your products and services. If a user needs to use your site and cannot do so, they should be able to levy a complaint against you. If you still do not fix your site, the discrimination persists and therefore they should be able to sue you. Settling this matter out of the courts should – at the very least – require that the website be fixed, that it remain accessible moving forward, and that you reimburse the complainant’s costs for attorney’s fees. I think all of this makes sense and at least in the case of Carson & Lynch, this is what they require.

But there’s another reality to this, which is that these attorneys are playing a dangerous game of chicken. The Americans with Disabilities Act does not define the Web as a place of Public Accommodation. The only place where the ADA says that websites must be accessible is when referencing the requirements for state & local governments. The DOJ has gotten involved in past lawsuits and stated that their position is that the Web is a place of Public Accomodation. But, that is not the same as having it stated in the ADA regulation itself. Issuing an Amicus Brief or joining on as a co-plaintiff in a lawsuit is not, strictly speaking, the same as having it written into law that Title III of the ADA applies to the Web.

The DOJ knows this is a problem and has known it for years. In July 2010, the DOJ issued an Advanced Notice of Proposed Rulemaking (ANPRM) which signified what many hoped would be the first steps in clarifying this once and for all. Unfortunately, it seems that they’ve since commenced kicking the can down the road. Like the much-delayed 508 Refresh, this has far-reaching consequences that go beyond mere uncertainty. It could even backfire. In fact, it already has.

The Court chastised the DOJ for failing to follow through on its July 2010 pronouncement to regulate website accommodation for public accommodation…

Website Accessibility Under the ADA, A New Federal Court Ruling Helps Banks

See, for traditional ADA “trolling” of physical spaces, a person merely need drive through a parking lot, observe the fact that there’s no accessible ramp or no reserved parking spaces, and fire off a demand letter. The ability to fire off scores of demand letters each day is easy in these cases and a small but noticeable number of people do exactly this. Case law here is well-established and the law & associated standards are very clear. This is not the case for the Web, as I’ve already discussed.

There’s a very clear and important distinction between advocacy and trolling. Most importantly, advocacy requires actively working to make things better. It requires a lot more than signing an agreement and accepting a settlement payment. True advocacy involves collaboration. The collaborative approach of Lainey Feingold and Linda Dardarian – called Structured Negotiations – delivers real results. Using this method, Lainey and her co-counsel have negotiated more than 60 settlement agreements without filing a single lawsuit., says Lainey’s “About” page.

The recent trend of firing off demand letters – and filing lawsuits when website owners fight back – risks harming the effectiveness of real advocates. Over the past 8 years, the DOJ under President Obama was very active in supporting the rights of people with disabilities. We now have a new President who has mocked people with disabilities and a new Attorney General at the helm of the DOJ who has slammed the UN CRPD and IDEA.

“We have created a complex system of federal regulations and laws that have created lawsuit after lawsuit, special treatment for certain children, and that are big factor in accelerating the decline in civility and discipline in classrooms all over America. I say that very sincerely,” Sessions said at the time.

I feel that we’re now witnessing what will become a game of chicken that threatens the effectiveness of real advocates. I’m skeptical that we’ll see any positive movement toward clarifying Title III’s application for the web and that we may see more decisions like the one I referenced at the beginning of this post. The volume of legal threat letters being sent out simply raises the probability that we will see more lawsuit filings when companies start to fight back which, in turn, raises the likelihood that we will see more decisions referencing Title III’s lack of clarity. What will the DOJ under Jeff Sessions do in these cases? Given his previous record on social issues, I’m not optimistic about what the new DOJ’s position will become.

Regardless of whether or not you agree with the ethics of using legal threats to advance accessibility, it does have the very real and almost immediate effect of causing websites to become more accessible. Unfortunately we’re almost certainly facing four years of uncertainty around Title III. The risk that presents itself as a consequence is that more judges may cite this uncertainty as a reason to dismiss a suit – especially one brought about by an obvious troll. Meanwhile the hard work and effectiveness of true Disability Rights Advocates is threatened at the expense of trolls looking for a quick payday.

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

Automated Web Accessibility Testing Tools Are Not Judges

Recently social media has been abuzz regarding an article titled “ITIF: 92% of Top Federal Websites Fail to Meet Security, Speed, Accessibility Standards” – and for good reason. The article cites a study by ITIF which details rampant failings of websites of the US Government. American taxpayers, being both the audience and source of funding for these systems, have every right to expect those websites to be user-friendly, secure, and accessible. ITIF is to be applauded for doing this rigorous research and reporting this information.

When it comes to their research into accessibility, their methods and conclusions leave a lot to be desired. The first problem is in their choice of aChecker to do accessibility research. aChecker suffers from a very important technical shortcoming: It does not test the browser DOM. I’ve gone into this before: tools that do not test the final rendered browser DOM are not testing what the end user experiences. In this specific use case, it leads to horrible research outcomes. Using aChecker to test accessibility is like using a broken thermometer in your Thanksgiving turkey. Every single website that ITIF tested uses JavaScript and CSS and yet the tool they chose to use does not render the JavaScript or CSS before testing.

But there’s another, more important thing to understand about this type of exercise: Automated Web Accessibility Testing Tools Are Not Judges.

Before I continue, I want to make sure that first-time readers understand my background on this topic. I have a long history with testing tools. In fact, my introduction to accessibility started with tools (as described here). As my resume shows, I worked for SSB BART Group and Deque, two of the major players in the accessibility testing tools market. I contributed significantly to the development of SSB’s AMP product. I’m the founder of Tenon.io and I’ve been doing accessibility consulting, accessibility testing, training, and web development for over a decade-and-a-half. It is – quite literally – my job to know what can and cannot be done with automated accessibility testing tools and I seek to stretch those boundaries every chance I can.

This cannot be said often enough or loudly enough: There’s just too many things in Accessibility that are too subjective and too complex for a tool to test with enough accuracy to be considered a judgment of the system’s level of accessibility. An automated testing tool cannot even tell with 100% certainty whether or not a web page passes WCAG 2.0 1.1.1.

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…

Read that again. “All non-text content”, which is defined as:

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
Note: This includes ASCII Art (which is a pattern of characters), emoticons, leetspeak (which uses character substitution), and images representing text

The non-text content must have “… a text alternative that serves the equivalent purpose…”. Not only that, but the text must be programmatically determinable. If your text alternative is not truly equivalent, your document is non-conforming.

Think about this for a second. There are a lot of cool emerging technologies that allow computers to recognize the objects in an image. We can detect text inside of an image and we can even locate specific people’s faces. Add a lot of complexity to an image, and most computer vision falls apart. Even OCR, which has existed for around 50 years, can’t read the logo for a Death Metal band. But even if computer vision was perfect, we can’t determine why any specific “non-text content” was chosen. What was the web author trying to convey with that non-text content? Why was that specific non-text content chosen over other options? What benefit will that non-text content have for the user who can see it? Is that non-text content there for decoration, or is it critical to the content? Tenon has 25 tests for WCAG 1.1.1 and we have maybe a dozen more on our wishlist. Even then, we’ll never be able to determine the meaning that the user intended to convey via non-text content and therefore we’ll never be able to fully judge conformance with 1.1.1.

There’s only so much that can be tested for automatically. Some things are so subjective or complex that trying to test for them would result in so many false positives vs. accurate findings that having the test would do more harm than good (like testing for 1.3.3). The team over at the UK Government Digital Service have done a great job of demonstrating the limitations of automated tools.

One thing that is missing across all automated testing tools, is contextual understanding. Automated accessibility testing tools provide the ability to test against highly specific heuristics that are very tightly scoped. They have no insight into the broader document being tested. They have no ability to determine the specific purpose of the page as a whole. I have been present at usability tests where test scenarios failed because of one highly important technical failing that – within its own context – was relatively minor. Nevertheless, it caused all participants to fail the test scenario.

What can you base a grade on?

Given the above, we’re already at a significant disadvantage if we rely on an automated tool. Again, we can’t even definitively prove conformance with any given WCAG SC, so grading any specific SC as a “pass” is wholly impossible. This is important to consider, because it means that even if your tool of choice returns zero errors, you can still be non-conformant. A picture of a dog, with an alt attribute of “cat” will pass all automated accessibility tools, despite being completely inaccurate even in terms of what is displayed in the image.

At this point, the only thing you can “grade” is one document’s failures against another’s – turning this from an exercise in deriving an absolute grade to an exercise in deriving a grade relative to other documents. An absolute claim of conformance would require an ability to fully test all criterion necessary for conformance. For instance, if a product contains a mark from Underwriters Laboratories it means the product has been found to conform to all of the defined safety standards for that type of product. Because no automated accessibility testing tool can completely test the criteria for WCAG conformance, no absolute “grade” derived from an automated tool is at all relevant or accurate which is why, at best, we’re left with relative grading.

Once you’ve settled on relative grading, what do you base that grade on?

  • Using tests passing vs. tests failing fails to consider the volume and severity of the issues found for the tests that did fail.
  • If you base it on issues per page, you’re failing to consider complexity differences between tested pages. You’re also failing to consider the severity of each issue.
  • You can break down issues-by-page-by-severity, but the severity of an issue varies significantly based on the type of user impacted. Bad alt attributes don’t impact users who are color blind. A lack of keyboard accessibility doesn’t impact a mouse user or a voice dictation user who can still use Dragon’s mouse grid. The priority score calculated by Tenon handles this pretty well, but the truth remains that a generic measure of severity fails to consider the full specific nature of an issue.
  • When it comes to complexity differences of each page, you can try to use Issue Density – that is, how many issues exist per kilobyte of document source. We’ve even proposed a mechanism for doing that. Unfortunately relative grading based on issue density is of little value, because even with a statistically significant sample size, standard deviation is ridiculously high.

There are certainly ways to combine metrics in a way that can be used to perform relative scoring of one site against the next but it would require:

  1. Testing all pages of each site.
  2. Using a baseline derived from a statistically significant-sized sample of all other sites on the web and testing every page of those sites.
  3. Gathering and measuring the relevant metrics (assuming your tool gives you the necessary granularity, such as issue-density-by-severity-by-affected-population).
  4. Using a tool that uses the browser DOM, tests accurately and without false positives.

And even then, all you’d be left with is – at best – a “sniff test” based on the comparatively small number of things that an automated testing tool can test for. For the most part, you’d still have absolutely no idea how any of the sites performed for users who are deaf or hard-of-hearing, for instance.

Automated accessibility testing tools are not judges

Given all I’ve said above it seems the only reasonable conclusion that using an automated web accessibility testing tool to “grade” websites’ accessibility is an exercise in futility. The only claim that you could make is that “given the things that can be tested for by tool x, the following issues surfaced…”. In other words, automated testing tools are great at diagnosing issues.

Automated accessibility testing tools have an important role to play in ensuring that web-based systems are accessible. They offer a level of efficiency that cannot be matched by humans and they perform at a scale no amount of humans could match. Since launching in 2014:

  • Tenon averages over 1000 customer test runs per day (including holidays and weekends).
  • Every day, we have non-bot traffic 24/7/365 across every timezone on the planet from 66 distinct countries.
  • Tenon has logged over 51,000,000 distinct issues across more than 1 million distinct URLs on approximately 30,000 distinct domains.

The real power of automated website accessibility testing tools is in their ability to quickly and accurately detect the specific issues they were programmed to find. They are a vital component of any robust website QA testing process. They cannot be used to “judge” or “grade” the level of accessibility of a system.

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