#accessiBe Will Get You Sued
The hashtag is in the title because accessiBe does not maintain a presence on Twitter. Instead the accessiBe site links to the hashtag, which is currently mostly positive and much of which may be paid. I am hoping a search for that hashtag will surface this warning.
- What We Know About accessiBe
- Two Kinds of Lawsuits
What We Know About accessiBe
It seems fair to first frame accessiBe by what we know of it today. I provide links so you can validate them yourself. My opinion (expert and otherwise) is grounded in these.
accessiBe Is Cited in an Accessibility Lawsuit
Users are filing cases against web sites that use accessibility overlays. The site UprightPose uses accessiBe as of this writing, though accessiBe is not the only vendor cited in the larger tranche of cases.
In the U.S. District Court, Western District of Pennsylvania, in the Civil Docket of Case #1:20-cv-00017-AJS, Judge Arthur Schwab has received multiple cases including Thomas Klaus and Robert Jahoda v Upright Technologies, and Kolesar v. Bylt, LLC. This particular judge has received many of these similar types of lawsuits and has started to consolidate into a single complaint. […]
The links to those cases are behind a paywall. UsableNet also mentioned these cases in its own ongoing tracking of accessibility and app lawsuits and that led me to a PDF. You can see a screen shot of the overlay in the example I excerpted.
accessiBe Pays for Praise
The article Why your website’s lack of accessibility options is opening you up to lawsuits at The Next Web cites a study by accessiBe in its opening to lay the groundwork for its thesis:
A vast majority of websites still remain closed off to people with disabilities. To measure the size of the problem, accessiBe, an AI-based web accessibility solution, tested 10,000,000 websites for accessibility compliance. According to the study:
It also asserts that AI is somehow used in accessiBe’s offerings, which is not something it can have verified. It doubles down on that assertion later in a section dismissing free automated checkers:
Luckily there are website accessibility companies, like accessiBe, out there that are leveraging AI technology to create solutions that are both comprehensive and affordable.
The post quotes Yan Kotliarsky five times, the VP of Marketing at accessiBe. When you get to the end of the article, where you encounter a logo with no
alt attribute, text that fails contrast, and a
<div> with the class
post-paidNotice, you see why:
This article is brought to you by ACE.
Ace is one of accessiBe’s products.
Since accessiBe points to its name as a hashtag on Twitter, you can find ostensibly paid praise in tweets almost exclusively from marketers that point to fluff pieces:
- at Information Age (as “partner content” under AI and machine learning),
- at TechWyse Internet Marketing,
- at International Business Times (byline of “staff reporter”), and
- at Techopedia (placed by StudioWorks, which publishes its client’s marketing in magazines).
If you look around for industry resources, they are either silent on accessiBe or openly critical of it.
accessiBe Deletes Critical Comments
One of accessiBe’s heavily promoted blog posts, referenced in most of the paid articles, is We Analyzed 10,000,000 Pages and Here’s Where Most Fail with ADA and WCAG 2.1 Compliance. The post makes some broad assertions about the nature of its automated testing and claims as failures things that accessibility professionals do not (I cover some later).
Patrick Lauke, an accessibility practitioner who is also active in the accessibility standards community, called out accessiBe for deleting comments that were critical of its assertions. Shir Ekerling, accessiBe’s CEO, asked what comments were deleted and then moved to redirect the conversation to LinkedIn, stating he may not check the comments again.
Which might explain why, when I provided a Wayback example of a deleted comment, I have not heard back.
Some contemporaneous evidence that there were more comments includes a message to the WebAIM email list on May 22, 2020, where Patrick says he left a comment, and then another message dated June 1 where Patrick notes the comments were deleted.
accessiBe Spoofs Automated Checkers
While reviewing some of the sites that has accessiBe’s overlay widget installed, I noticed the behavior changes when WebAIM’s WAVE automated accessibility checker is used. WebAIM seems to know about this, too.
If I look at DealerOn, the link on the logo has the accessible name “DealerOn DealerOn DealerOn”, derived from the alternative text from each of the three logos in the code. After running the accessiBe overlay, accessiBe uses
aria-hidden to hide one of the images and adds a visually hidden
<div> with new text. That results in the accessible name “DealerOn DealerOn Websites, SEO, and SEM for Car Dealers”. I leave it to you to decide if that is an improvement for screen reader users.
If I then run WAVE and look at the code, that visually hidden
<div> now has the text “.smmy 6za”.
At the site for Neil Patel, the logo link before modification has no accessible name at all. After accessiBe is run, it adds a visually hidden
<span> with the text “Neil Patel: Helping You Succeed Through Online Marketing!”, which becomes the link’s accessible name.
If I then run WAVE, that visually hidden
<span> now has the text “.jmzw znh”, another visually hidden
<span> is added with the text “New Window”, and the original link gets a
Changing the text in a node accessiBe inserts could be a bug. But adding a
target attribute and an additional text node suggests either this bug is significant, and putting accessiBe’s customers at risk of even more bugs, or it is not a bug.
If not a bug, accessiBe is delivering more code to every user just because it wants to modify the results of one automated checker. If that is the case, you can expect to see some effort made to do the same to other checkers, with users bearing the burden of a larger download, more processing, and more memory on their devices.
accessiBe Misrepresents ADA
On its site, accessiBe has badges with checkmarks in them. One of them is “ADA Title III COMPLIANCE”. This implies its service offers compliance to ADA, even though its own SEO-driven ADA explainer page makes it clear ADA does not explicitly cover web sites.
Throughout its site accessiBe references ADA compliance, including in its oft-promoted post We Analyzed 10,000,000 Pages and Here’s Where Most Fail with ADA and WCAG 2.1 Compliance. In Lies, Damned Lies, Overlays and Widgets, Timothy Springer outlines why this is not true. Specifically he asserts that overlays, like accessiBe’s, fail to provide full and equal access, instead attempting to create a separate but equal experience.
accessiBe Does Not Understand WCAG
Last year accessiBe left a comment on an old post of mine challenging claims Karl Groves had made (mistaking him for me), so I responded to the comment with technical issues with their work. I never heard back.
Karl Groves later recorded a video that demonstrates the problems with accessibility overlays in general, and accessiBe was rightly featured. Karl uses SC 1.1.1 as an example of this misunderstanding.
In accessiBe’s post We Analyzed 10,000,000 Pages and Here’s Where Most Fail with ADA and WCAG 2.1 Compliance (arguably its attempt to capitalize on the popularity of The WebAIM Million) accessiBe makes many assertions about what is required under WCAG. I am excerpting its statements about web site navigation, the first item accessiBe identifies.
- A “NAV” tag or a “role” attribute equal to “navigation/menu/menubar” (depends on the menu type) must be present on the top element that contains all the links and menu items (role=”navigation/menu/menubar”).
- A “role” attribute equal to “menuitem” must be present on the links that comprise the menu items.
- Users can use the Tab key to navigate to the next element, and Shift+Tab to navigate to the previous element, and the focused element must be easily identifiable using a focus ring (outline).
- Users can navigate across the menu bar itself using the left-and-right keyboard arrows. When reaching the end of the menu, and pressing the forward arrow key, the navigation should loop back to the first item.
- Users can open dropdowns using the Enter and the arrow-down keys. Dropdowns should also be opened by focusing on the menu item.
- Users can navigate within dropdowns using the up-and-down arrows, and the focus must never escape and loop within the dropdown unless it was intentionally closed.
- Users can close the dropdown using the Esc key, and the keyboard focus must go back to the root menu item of this dropdown.
- It is not a WCAG failure for a site to exclude a
<nav>or appropriate navigation role; while Technique ARIA11 is one option to satisfy 1.3.1 and 2.4.1, it is not the only option. Similarly,
menuroles are an anti-pattern as I have identified in the past, and definitely not a requirement under WCAG.
menuitemroles for navigation are an anti-pattern. So much so that a sample pattern promoting them has been roundly criticized by assistive technology users and accessibility practitioners who work directly with users.
- On its surface, this is accurate, but truthfully users should be able to tab to interactive elements, not any element (per 2.1.1). While visible focus is indeed a requirement (2.4.7), WCAG does not mandate “easily identifiable” (though 1.4.11 at least mandates some contrast) and it need not be a ring.
- There is no requirement that users can move through site navigation with arrow keys. This is doubling down on the ARIA Authoring Practices menu pattern, which was developed to mimic Windows-style interfaces to replicate native behavior on the web. In addition, the ARIA Authoring Practices is a Note, not a WCAG requirement.
- Given all the specific language in HTML and ARIA, accessiBe falls back to the term dropdown, which has no meaning on its own though I suspect they are still talking about navigation. Also not a WCAG requirement
- See my previous point.
- See my previous point, though managing focus is covered by 2.4.3 and closing on Esc is not a requirement but alludes to a misunderstanding of 1.4.13.
Most recently accessiBe is taking an unironic swing at a rival with its June 1, 2020 post Using an accessibility plugin like UserWay? You are at risk of litigation. It opens with a list of articles supporting its claim, all published in the first 10 days of June, two of which are the same article by the same author on two different sites, another of which is linked twice. We already know accessiBe pays for positive press, so 6 articles in 10 days seems suspect.
Never mind that accessiBe provided a checklist in a table that has no column headers, we can already see accessiBe is repeating its incorrect claims about navigation. But I want to pull two out in particular:
Deleted prices, bold and emphasized texts that are visually decorated using CSS are tagged appropriately to screen-readers[…]
All form fields receive a proper field description using a connected label or an aria-label
Screen readers do not announce bold or emphasized text by default, a user has to enable it. Deleted text (not just prices) are exposed in NVDA, but were only briefly exposed in JAWS.
Form fields can also use
aria-labelledby to provide an accessible name. In fact, there are even more ways to provide an accessible name for a field, but they are generally less good. This logic should already be in accessiBe’s algorithms if it is claiming it can provide WCAG compliance.
Two Kinds of Lawsuits
When a web site receives a legal complaint, it typically comes in one of two-flavors:
- seeking financial compensation;
- seeking functional change.
Those seeking money are generally the drive-by lawsuits that have gotten the press. A person runs an accessibility testing tool on a web site, looks for errors, and sends a letter demanding some web site fixes, attorney fees, and sometimes a cash settlement. These are brought most often by mass-filing law firms and plaintiffs and do not advance accessibility for users. The simplest protection is to have few to no accessibility errors flagged by automated testing tools.
Those seeking a functional change to a web site so they can use it are typically not concerned about the results of a testing tool, though it may bolster their claim. These users can point to specific problems on screens or flows instead of blanket statements or collections of WCAG issues. They also often do not demand financial compensation but instead work with the site owners to resolve the issues, such as through structured negotiation or similar processes. Their focus is generally on being involved in and validating the solution.
Ideally a tool promising to protect your site from suits would address both scenarios, by reducing automatically detectable errors as well as making core functions and flows work well for users.
The accessiBe overlay widget does not reduce automated testing tool errors, but instead increases them. Performing basic actions on a site are not improved with accessiBe’s overlay, creating the a confounding experience. Both of these scenarios, exacerbated by accessiBe’s product, increase the risk of a suit.
accessiBe Is Inaccessible
Steve Faulkner did a technical walk-through of the accessiBe overlay, among others, and documented clear failures under WCAG.
Whether you review it with automated tools or manual testing to check for WCAG failures, or you look at it from the perspective of de facto accessibility, both accessiBe and its overlay do not pass muster.
I am not wading through accessiBe’s client sites. I am looking at accessiBe’s site though its own tool to get the best insight into how it understands accessibility. I am also not doing an in-depth review, partly because others have done so (which helps establish an ongoing pattern) and partly because I am not giving them my help for free.
Via Automated Testing
I grabbed a few examples of how one page on its site performs worse with automated checkers after the accessiBe overlay is enabled.
Via Manual Testing
WCAG Success Criterion 2.2.2 Pause, Stop, Hide (Level A) could be tested with a trained AI (if one existed). If the
<video> element has no
controls attribute and/or has an
autoplay attribute, then it should be flagged as worth exploring to make sure it is not a 2.2.2 violation. The video on the page I tested fails this SC, and the accessiBe overlay seems unable to stop it more than once.
If you start navigating the page with Tab, after a few presses the page prompts you to use the overlay. If you decline, the visible focus styles (which were the browser default) go away completely. Declining to use the accessiBe’s overlay on its own site results in a 2.4.7 Focus Visible (Level AA) violation.
If you have the page zoomed enough to trigger the mobile layout, a hamburger control appears to replace the primary navigation bar. You cannot tab to it with the keyboard, but after a few Tab presses you are prompted to activate the overlay. While that allows you to tab to the hamburger, no amount of pressing Enter or Space will activate it. With the accessiBe overlay running, the page violates 2.1.1 Keyboard (Level A).
Via Actual Use
If I pose as a skilled screen reader user, I may start tabbing as soon as the page loads expecting to find a skip link. That means I unintentionally abort the alert. The first two links do not start with “skip to” or “jump to”, so I move past them quickly, find yet another link that does not interest me, and press Q to jump to the main region. JAWS then announces there is no main region.
Incredulous, I press R to find other regions and cycle through the banner, navigation, and footer. At :38 I pull up the JAWS region navigation dialog to manually confirm all the regions on the page.
When I open the page in JAWS and Chrome, there is an ARIA-powered alert that interrupts the initial page announcement prompting me to enable the overlay. When I press Tab, the first thing I encounter is a prompt to enable the overlay, which is interrupted by another alert to enable the overlay. When I relent, I find I have to remember Alt + 1 if I want to get to these custom controls.
After being offered the accessibility statement again I press R to jump to the next region of the page and am greeted with a verbose description of a custom navigation that is not visible on the screen. Another press of R gets me to the navigation, which I wait through just long enough to to confirm I am not where I want to be, so I press Q to jump to the newly-added main region. Then I encounter the seemingly multiple
For a sighted screen reader user, the experience is a bit overwhelming considering how little of the spoken content is visible.
The title is hyperbolic. You will not get sued as soon as you put accessiBe’s overlay on your site. However, you will be using a product that generates more errors than not using it.
The accessiBe overlay also produces a worse experience. Users who care little about WCAG but understand their rights to equal access can file a complaint and put you on the hook for fixing the core issues. Another third-party hack will not help.
Using accessiBe’s overlay widget is a pre-preemptive admission that you know your work is inaccessible and that you took the shortest possible route to find the easiest possible workaround. You are telling users you care more about litigation risk than them.
The title is also a riff on accessiBe’s recent post Using an accessibility plugin like UserWay? You are at risk of litigation. In that post accessiBe is using fear, and fear is a poor motivator.
Adally, AudioEye, EqualWeb, Mk-Sense, User1st, and UserWay are not viable alternatives. They also promote their tools as risk mitigation over sustainable accessibility efforts that would otherwise promote better overall experiences.
I have a 2015 blog post, Be Wary of Add-on Accessibility, which I continue to update with news on accessibility add-ons and overlays. In February 2020 I noted a curious regional connection between accessiBe and others, but have not taken the time to dig in further. If there is something there, some kind of cahoots, please share.
Accessibe is shit
Accessibe makes me so angry, they’re a bunch of scammers.
AccessiBe is a scam.