#accessiBe Will Get You Sued

The hashtag is in the title because accessiBe does not maintain a presence on Twitter (it does now!). 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
  • accessiBe Is Cited in Accessibility Lawsuits
    • Thomas Klaus and Robert Jahoda v Upright Technologies
    • Blair Douglass v. Masterbuilt Manufacturing, LLC
    • Murphy v. Eyebobs, LLC (lost 5-Oct-2021)
    • Fischler et al v. Dorai Homes
    • Sherwin v accessiBe (10 July 2024)
  • accessiBe Pays for Praise
  • accessiBe Deletes Critical Comments
  • accessiBe Spoofs Automated Checkers
  • accessiBe Misrepresents ADA
  • accessiBe Does Not Understand WCAG
    • accessiBe’s AccessUS As More Proof (9 November 2021)
• Two Kinds of Lawsuits
  • accessiBe Is Inaccessible
    • Via Automated Testing
    • Via Manual Testing
    • Via Actual Use
    • December 2020 Release (9 December 2020)
    • Users Share Their Experience with accessiBe (15 December 2021)
    • accessiBe Still Introduces WCAG Violations (18 January 2024)
  • accessiBe Will Not Protect from Lawsuits (20 March 2021)
• Wrap-up
• Why to Avoid aCe (14 July 2020)
  • aCe May Have Been ReplaCed (6 July 2022)
• When the Script Fails (30 July 2020)
• accessiBe Spams Prospects (21 September 2020)
• accessiBe Is Unaware of Social Media Accessibility (7 October 2020)
• accessiBe Uses Black Hat Content Marketing (9 December 2020)
  • accessiBe Uses Coordinated WordPress Plug-in Reviews (17 February 2021)
• accessiBe Will Not Honor its Guarantees (14 December 2020)
• accessiBe May Have Lied about JAWS (9 March 2021)
• accessiBe Relies on False Advertising (15 December 2021)
• Community Response to accessiBe (17 March 2021)
  • Mosen at Large Discusses accessiBe (17 March 2021)
  • More Mainstream Press
    • Vice (17 March 2021)
    • NBC News (9 May 2021)
    • Wired Magazine (12 November 2021)
    • 13 Letters Podcast (01 April 2021)
    • Financial Times (7 April 2024)
  • accessiBe Is Ableist (5 September 2020)
  • accessiBe Asserts a Silent Majority (14 February 2021)
  • Disabled Users Block accessiBe (18 February 2021)
  • accessiBe as Privacy Risk (28 July 2021)
  • Statement from Haben Girma, Human Rights Attorney (5 May 2021)
  • NFB Revokes accessiBe Sponsorship (24 June 2021)
  • Nielsen Norman Group Confirms Users Don’t Want It (1 May 2023)

• accessiBe Response (4 August 2020)
  • Response to accessiBe Response (17 August 2020)
• 13 May 2023: accessiBe Redemption Tour Starts
  • 7 June 2023: accessiBe Redemption Tour on Mosen Podcast
  • 15 April 2024: accessiBe’s GAAD Sock Puppets

I have highlighted accessiBe’s lies (the first three are in my response to accessiBe’s video response, so you will need to expand it):

• Lie 1
• Lie 2
• Lie 3
• Lie 4
• Lie 5
• Lie 6
• Lie 7
• Lie 8
• Lie 9
• Lie 10
• Lie 11
• Lie 12
• Lie 13
• Lie 14
• Lie 15
• Lie 16

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 Accessibility Lawsuits

Users are filing cases against web sites that use accessibility overlays.

Added 20 June 2021: accessiBe’s CEO made this statement on LinkedIn at the end of May 2021, well after four of these lawsuits were listed below:

[…] You have never, not once, had encountered a company that got sued because of accessiBe. You have only seen companies that have joined accessiBe to be a solution to their already existing legal situation. […]

Remember, we know he read this post and saw two of the lawsuits because he responded to it (video embedded way below). His claim, on its surface, seems counter to reality.

Thomas Klaus and Robert Jahoda v Upright Technologies

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.

Blair Douglass v. Masterbuilt Manufacturing, LLC

Added 22 October 2020: accessiBe has been named in another lawsuit as of 13 October 2020. As a result, the heading for this section has now changed to plural.

The case is Blair Douglass v. Masterbuilt Manufacturing, LLC and I have embedded two pages from the PDF since you would have to pay to see it otherwise.

Murphy v. Eyebobs, LLC

Added 16 January 2021: Yet another lawsuit names accessiBe as of 7 January 2021. In Murphy v. Eyebobs, LLC., the complaint offers YouTube videos demonstrating the failures with the accessiBe widget. One shows how viewing the accessiBe accessibility statement traps a screen reader user. Two more show how accessiBe fails to make a modal dialog accessible along with accessiBe failing on another promo pop-up, depriving the user of a discount. The last video shows how accessiBe fails on a star rating widget, preventing a user from getting a sense of the quality of the product.

Update 18 October 2021: Eyebobs lost the case. ADA lawsuit settlement involving an accessibility overlay outlines the terms of the settlement, including building a team, writing a policy, and training its staff. All the things accessiBe promises you need not do. Grab a poorly-tagged PDF of the agreement.

Update 12 November 2021: Wired Magazine did an article on this case and seemingly exposed a couple more accessiBe lies, which I cover in more detail below.

Fischler et al v. Dorai Homes

Added 26 May 2021: Another lawsuit directly cites accessiBe as of 12 May 2021. In Fischler et al v. Dorai Homes, accessiBe’s overlay is named as the reason for the barrier. Its failure to provide any alternative text for images was one stand-out for me, given claims the “AI” is more than capable.

Sherwin v accessiBe (10 July 2024)

I don’t have a lot of detail here, but Sherwin K. Parikh MD, P.C. d/b/a Tribeca Skin Center has filed a class action complaint against accessiBe in the southern district of New York.

I have embedded the complaint, but you can also download the 918kb tagged PDF of Sherwin v accessiBe:

If you read the section Accessibe falsely claims to automatically make websites conform to WCAG standards starting at the bottom of page 7 (or paragraphs 23 through 45), you will see a lot of what I cover in this post. Including a LinkedIn discussion where the CEO claims no prior lawsuits, which I had responded to at the time to point out the lie with a list of lawsuits.

I’m going to pull out how accessiBe responded after Sherwin was sued for an inaccessible site (starting at paragraph 60 on page 19):

Plaintiff contacted Accessibe within days, provided it with a copy of the complaint, and asked for the promised legal support. The “support” received consisted of another Accessibe audit report stating that its website conformed to WCAG level AA and was fully ADA compliant and a naked statement that the claims against Plaintiff were invalid. Accessibe then referred Plaintiff to an outside attorney who quoted a cost of over $10,000 to defend against the lawsuit.

Plaintiff retained a different attorney who provided a defense for a fee of $4,000 and ultimately settled the claim with a monetary payment.

Plaintiff retained a legitimate website remediation firm. An audit of Plaintiff’s website that Accessibe’s automated audit claimed to conform to WCAG Level AA identified dozens of issues of non-conformance. The outside firm manually remediated Plaintiff’s website to make it accessible in conformance with the WCAG at a cost of $3,500. This included end-user testing by a legally blind individual.

Sherwin asserts Breach of Contract, breach of the Covenant of Good Faith and Fair Dealing, violating New York State General Business Law § 349, breach of Implied Warranty, violation of the Magnuson-Moss Warranty Act 15 U.S.C. § 2301, Negligent Misrepresentation.

Lainey Feingold has also written about the case at New Class Action Lawsuit against AccessiBe.

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”);
• at Techopedia (placed by StudioWorks, which publishes its client’s marketing in magazines);
• at ShoeMoney (where the contact page is a 2014 post about someone being in federal prison);
• at Business 2 Community on August 17, where it was syndicated from…
• Blueleadz, a marketing company that is likely one of the “partners” the CEO references in his response video;
• at UXPlanet (September 10, byline of UXPlanet) where it shows 6 positive responses, hiding the seventh critical response.
• at Design Shack (October 27), written by a content marketer and parroting the key marketing points of others.

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 target="_blank".

Wading into accessiBe’s JavaScript, there appears to be some sort of WAVE-specific detection and processing happening. While dismantling the script is outside the scope of this post, there is evidence accessiBe is making some sort of changes to the page after WAVE is run but the intent is unclear.

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.

1. 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”).
2. A “role” attribute equal to “menuitem” must be present on the links that comprise the menu items.
3. 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).
4. 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.
5. Users can open dropdowns using the Enter and the arrow-down keys. Dropdowns should also be opened by focusing on the menu item.
6. 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.
7. Users can close the dropdown using the Esc key, and the keyboard focus must go back to the root menu item of this dropdown.

1. 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, menu roles are an anti-pattern as I have identified in the past, and definitely not a requirement under WCAG.
2. Again, menu and menuitem roles 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.
3. 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.
4. 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.
5. 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
6. See my previous point.
7. 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.

accessiBe’s AccessUS As More Proof

Added 9 November 2021: The AccessUS site is either an accessiBe reseller or an alternative accessiBe brand for selling more aggressively to litigation fears.

The auto-playing audio from accessiBe, the accessiBe overlay, and the embedded accessiBe references in its content cement its connection. Evidence of a failure to understand WCAG come from the auto-playing audio you cannot disable and the image of text on the home page with an empty alt attribute. Evidence of broader incompetence can be seen in the footer non-links in an <h2>, or the social media icons that are not links but have a cursor change to suggest they are.

Either accessiBe is hoisting a new wildly inaccessible site under a different brand, or it allows anyone to white label its tool without even the barest effort at confirmation or validation. Not the kind of rigor I want from a company claiming its AI can do it all.

Two Kinds of Lawsuits

When a web site receives a legal complaint, it typically comes in one of two-flavors:

1. seeking financial compensation;
2. 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 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 <h1>.

For a sighted screen reader user, the experience is a bit overwhelming considering how little of the spoken content is visible.

December 2020 Release (9 December 2020)

I am adding this on 9 December 2020. You may note that the version of accessiBe’s tool that I reviewed above was replaced shortly after this post went live. Since I cannot bill for time reviewing the latest offering I only look when I get a tip. For example, Karl Groves pointed out the egregious color contrast violations in a tweet in November, and I finally took a look.

The fourth image shows flags for selecting a language (a huge internationalization no-no), but the notable part is none of those flag images has an alt attribute. This overlay violates at least three WCAG Success Criteria from 10 seconds of poking around. How many more can you find?

Users Share Their Experience with accessiBe (20 March 2021)

Connor Scott-Gardner read a post from accessiBe asking for users to keep an open mind and try its service for themselves. So he did. He wrote about his experience in Do Automated Solutions like #AccessiBe Make the Web More Accessible? and recorded a video. I have embedded the video, but this conclusion stood out in his post:

In the end, it was far easier to navigate the blog post without AccessiBe. Although I’d have liked for better table markup, I could understand the information perfectly well without it, and I could at least navigate the page quickly. With AccessiBe enabled, this became impossible.

Brian Moore also took the time to record a video demonstrating a shopping experience both with and without accessiBe, sharing it on Twitter. He was motivated to do so after listening to the Mosen at Large podcast episode discussing it. At almost the 40 minute mark he collects his thoughts:

So the issues I had with actually going through the flow were actually a bit worse with the accessibility overlay on. There were strange alt text buttons that were not at all clear what they did. The field labels on the checkout were duplicated. And any of the issues in the actual reading of the content, like empty links that had no text, or expanded / collapsed ARIA sections that didn’t tell you what they were, were not remediated at all. There were a couple of extra headings, and the search results gave erroneous data when I typed in the search field. So, my conclusion from this short demo, and it’s anecdotal of course, it’s not conclusive, is that actually turning on an accessibility overlay actually provided a worse user experience than not having it on.

Bear in mind accessiBe has been getting feedback for months (at least 7 months now) and has released a new version and many updates since users started broadly raising issues over a month ago. These examples are using the latest, most robust version of accessiBe’s product. A product which has marketed itself for years as guaranteeing both WCAG compliance and a better experience.

In this post I demonstrated the WCAG compliance is not now and never was true. These latest videos demonstrate the same for the experience, even after months of detailed examples and complaints, along with $40 million dollars in funding.

Added 2 April 2021: accessiBe wrote:

[…] In reality, the mentioned table did not have column headers (a heading for every column), rather, it has row headers (a header for every row). To be fair, the user expected a table with column headers, which is the typical kind you would find on this kind of site, but instead, the website had a table with row headers. The way accessiBe did in fact remediate this for an accessible screen reader experience is s identifying that it is actually a row header type of table and made the cells of every row that were visual headings, a row header for screen-readers as well. […]

The video clearly demonstrates that accessiBe inserted <h2>s, not <th>s as claimed. Either accessiBe’s CEO is lying, confused about the technology, or did not pay attention. Go listen at 8:04 in the video.

In the same article, accessiBe also wrote:

[…] A screen-reader user filmed a video in which they meant to show that Belkin.com is fully accessible without accessiBe but isn’t accessible with accessiBe. […] What the user did not know that accessiBe was turned on the entire demonstration […]

Two big issues there: The user never said the site was fully accessible, even demonstrating that it was a mess; the video shows the accessibility problems with the site, so this might be an unintentional “self own” on behalf of accessiBe. In fact, at 41:23 the reviewer talks about the problems and states he had a different experience in each use — suggesting inconsistent output from accessiBe.

accessiBe Still Introduces WCAG Violations (18 January 2024)

It’s been nearly 4 years since I first showed accessiBe’s overlay introduces WCAG violations. Unsurprisingly, accessiBe’s overlay still introduces WCAG violations.

When I said that accessiBe needs alternative text for its flag-based language picker, I did not expect them to add redundant alt text.

This is a great way to demonstrate that accessiBe, after I raised it years ago, still has not tested with a screen reader:

While someone can argue that the redundant alternative text does not violate WCAG Success Criterion 1.1.1 Non-text Content (and maybe keep a straight face while doing it), these two are far more obvious.

Credit to Manuel Matuzović for identifying the bug. I just made the fancy video.

To experience it yourself, go to The Bushnell’s concerts page. Activate accessiBe, toggle the “Keyboard navigation (motor)” option, and then try to find the checkboxes on the page.

The accessiBe overlay introduces a WCAG SC 1.4.3 Contrast violation because of the orange text on white (then gray), when it could have prevented whomever configured the overlay from using that color combination. Worse, however, is the 2.4.7 Focus Visible violation. This is a huge problem for the very keyboard users this feature is meant to help.

As an aside, notice how toggling the “Keyboard navigation (motor)” option also toggles the “Blind Users (Screen Reader)”. The needs of these two user groups don’t necessarily overlap, and a hackneyed attempt to support the former can make things worse for the latter. I suspect this is done partly so accessiBe can claim folks are activating this feature and therefore must be screen reader users (who are otherwise loud in their frustration with accessiBe). It may be a novel way to keep the numbers in the green for reporting to investors.

Update: accessiBe Will Not Protect from Lawsuits (15 December 2021)

At the 2021 Digital Accessibility Legal Summit, a two-part session was held on overlays. Part one has been posted to YouTube with this abstract:

As part of the 2021 Digital Accessibility Legal Summit, Jeremy Horelick, Jason Taylor and Richard Hunt discuss widgets, plug-ins and overlays being marketed as one-step software solutions to website accessibility. They provide a brief review of terminology and differences between the various products, followed by an examination of whether these tools will do what they promise—in terms of both actual accessibility and protection from website accessibility litigation.

When asked if overlays reduce litigation expense or risk, the answer was a resounding no. You can jump to 31:46 of the video and listen/read for yourself, but I have quoted the salient bit:

They absolutely do not. And there are two reasons why this is true. The first reason is simply because they don’t actually fix websites. […]

The other reason is because the law firms, not all the law firms, but many of the law firms that are in this area do not care whether the website is really accessible or not. Their desire is to find something that they can identify as an error, usually by measuring it against WCAG, and if they can find that error, they can file a lawsuit in good faith. Remembering that their goal is to settle the lawsuit as soon as possible.

Wrap-up

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.

The best approach is to build for your users, engaging them where you can, and creating an organization-wide process to integrate and support accessibility. That takes far more work than stuffing a JavaScript reference on your site, but yields much better returns. Instead of trying to limit risk, work to build loyalty.

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.

Update: Why to Avoid aCe (14 July 2020)

I referenced accessiBe’s aCe product above but did not go into any detail about it. I felt that, in time, experience with it would warrant an additional post. However it is probably best to note today that aCe is likely just as problematic as accessiBe’s overlay.

The new aCe offering is an accessibility inspector that accessiBe presents for free, most likely to drive traffic to its overlay product. Given that its name is likely a play on Deque’s Axe product (formerly aXe, note the capitalization), and given accessiBe’s demonstrated lack of WCAG understanding and misleading claims about accessibility in general, you would be right to have low expectations.

Remember that accessiBe is paying for all the positive reviews and comments it has out there today. It is no surprise that an internet marketer, who has an aCe promo as her pinned tweet, would be astro-turfing for the product the same day aCe appears on Product Hunt.

We already know Neil Patel is a client of accessiBe (because I cover NeilPatel.com’s problems in detail above), and we know that accessiBe spoofs other tools to improve scores. It does not seem like a stretch that accessiBe would tweak aCe to give good marks to its own client (promoted on its site).

What is not clear is if aCe is running its check with the accessiBe overly active. If the overlay is not running, then arguably aCe is making the case that the accessiBe overlay is not benefiting NeilPatel.com.

If you run Google Lighthouse on NeilPatel.com, however, you get a score of 88 out of 100. Lighthouse uses Axe-core as its engine, which prides itself on no false positives, so these are unlikely to be picayune issues.

Further, a manual check confirms these are real issues. Fundamental issues. The kinds of issues any accessibility checker should be expected (required) to find.

Curiously, before running aCe, the link on the logo (as I identified way above) is clearly broken. After running aCe that link has the same code added to it that the accessiBe overlay adds when it is trying to spoof WAVE.

But it gets a bit weirder.

When I re-ran NeilPatel.com later, using the same accessiBe URL, I got different results. This time I used an incognito window. When in incognito mode all my accessibility checker plug-ins are disabled, which makes me wonder if aCe did not detect them and therefore did not adjust the HTML to try to spoof them. That is clearly speculation, of course.

The breakdown of scores on NeilPatel.com from aCe (all out of 100): Clickables 54, Titles 100, Orientation 40, Menus 33, Graphics 50, Forms 25, Document 100, Readability 79, Carousels neutral, Tables neutral, General neutral.

Which aCe review of NeilPatel.com do you believe?

Update: aCe May Have Been ReplaCed (6 July 2022)

The aCe sub-domain, ace.accessibe.com, has been broken since at least 18 June 2022. It does not appear to resolve anywhere. It appears to have been replaced by accessScan, which lives on the main site at accessibe.com/accessscan.

When I tried to run it on itself, maybe to see if would catch some of the obvious errors on its own page (such as the use of placeholder text for the input), or less obvious risks (such as the re-ordered heading content), I got a connection error. No matter how many times I ran it and no matter which browser or connection I used. Granted, I got the same error when trying to test accessiBe’s poster child, NeilPatel.com, so the entire tool may be broken.

My guess is that this was a consolidation effort to keep folks on the main site with all the trackers, saving the hassle of managing two sites. The renaming may just be for better search targeting, and addressing how “aCe” looked like a direct copy of “aXe”.

Update: When the Script Fails (30 July 2020)

Throughout this post, I talked about the problems from accessiBe after it loads on a site. I did not talk about the effect when it does not load.

Earlier this week a user posted to the Malwarebytes support forum to report that accessiBe’s script was being blocked as a trojan. Malwarebytes has since removed the block, though it is clear at some point it was flagged and could be flagged again or by others.

Meanwhile, a screen reader user ran into the same problem with ad blockers and reported it to NameCheap (while also confirming that when accessiBe’s overlay does work the audio cue is a problem).

When I checked the NameCheap site without any blockers the overlay still did not load, seemingly from network issues. If NameCheap used code provided by accessiBe for that control, then accessiBe was adding accessibility barriers to its page.

What does accessiBe offer when its external script is blocked or fails to load? Seemingly nothing. There is no script that lives on accessiBe’s customer site if a trojan or ad blocker is in place. There is no HTML-only fallback (either processing on the server or hiding the accessiBe launcher) should the network hiccup or there be an error in script elsewhere on the page.

The accessiBe overlay (falsely) promises its customers WCAG compliance but seemingly offers no fallback when it does not load, giving its customers a false sense of security but still exposed to complaints. The reliance on remote third-party scripting by accessiBe, instead of a robust progressively-enhanced solution, is even more reason you are increasing your risk by using it.

Update: accessiBe Spams Prospects (21 September 2020)

Over the last few weeks I have been aware that accessiBe has its team fanning out across LinkedIn, web site contact forms, and other venues to look for ‘partners’ to re-sell its platform. It is impressive what $12 million in funding can be used to acoomplish (certainly not making its widget accessible).

As we saw in the section accessiBe Pays for Praise (and at 2:00:17 in the response video), accessiBe only sees partnerships in transactional terms. If you build web sites, the transaction is simple — you reduce your and your clients’ risk of a lawsuit, and accessiBe gets its product on yet more sites, further bolstering its install claims regardless of what it does for users. Maybe they offer a referral fee, but that will be negligible.

Bear in mind, once the accessiBe widget is on a site and a user files a genuine complaint, the web site developer will be the one in the hot seat having to take time and effort to deal with it. Reputation damage is perhaps the mildest outcome.

If you receive a request on LinkedIn you can report unsolicited marketing, sales, or partnership requests directly from the message. Reporting those messages can help prevent accessiBe from wasting others’ time as well.

Update: accessiBe Is Unaware of Social Media Accessibility (7 October 2020)

In accessiBe’s effort to use National Braille Week (which is not even being promoted by the organization that coined it) to pitch its one simple solution, accessiBe posted a tweet with an image of Braille — without alternative text.

As you can expect, the replies were quick to point this out, as well as the quote tweets. Given that Twitter has allowed alternative text on images for 4½ years now (since March 2016), it is unlikely that a truly accessibility-focused company would not have been aware of the feature.

I think most of us can appreciate that mistakes happen. We have all forgotten alternative text on a Twitter image at some point. But in this case, since accessiBe joined Twitter in August it has never posted alternative text for an image (as of this writing). You can confirm this by going to accessiBe’s Twitter media page and running a bookmarklet I wrote that shows the alternative text for an image in a tweet (Note: accessiBe has since deleted all tweets with images they posted before I raised this).

It is apparent accessiBe’s claim they make the internet accessible for everyone, no matter the disability, disorder, illness, or injury in question would only apply through their widget, if at all. Clearly accessiBe is not making the effort on Twitter.

The next morning accessiBe deleted the tweet without any acknowledgment and posted a replacement tweet with an image of a Braille display that it describes in the alternative text as a Braille keyboard. If accessiBe used its AI technology to provide that, then it is not very good. If accessiBe did not use its AI technology, then you have to wonder why not.

A few days later accessiBe posted its Braille image again and deleted it within an hour.

Update: accessiBe Uses Black Hat Content Marketing (9 December 2020)

In May 2020, an accessiBe page appeared on Wikipedia. As you can see in the article history it sat dormant until 8 September when it was flagged as puffery (spam), was flagged for deletion on 20 September, and then on 17 October (after many attempts to clean it up) the article was given a spam warning and the author was blocked for spamming — a violation of Wikipedia’s Terms of Use.

A discussion at Hacker News roughly outlines a black-hat marketing effort using sock-puppet accounts on blogs, Reddit, and Hacker News at a scale large enough to move the needle on search engine placement as well as astro-turfing in general. As you guessed, accessiBe is among the companies the author lists who is using these techniques.

The author lists the accounts on Hacker News he has identified and links to all their posts (I refined it to show only accessiBe posts). He also points to authors on Medium who plug the listed companies, and I identified one who has written four posts that are based on shaky or incorrect accessibility tips, suggesting accessiBe or parroting accessiBe’s tactic of descrediting free options (1, 2, 3, 4). That last post feels like a paid post and may have been related to the author’s tweet 2 months prior about writing an ADA piece for a company.

At the start of this post I link to a promotional piece from UXPlanet. As of this writing, that post has 7 comments (responses) total, though it only shows 6. The hidden comment is mine, which is critical of accessiBe. Two of them claim to be accessiBe customers (1, 2) and a third is a response to another comment that claims the same (3). What these have in common with sockpuppet accounts is the lack of an address for their web sites (in their bio or elsewhere) along with little activity (the third account has three posts written in the same week in February).

As an aside, there is another UXPlanet piece, Why Free Tools Just Aren’t Enough to Achieve Web Accessibility Compliance, which fits neatly into the accessiBe playbook of generating content that does not mention accessiBe, but is likely use to discredit any potential competition.

While there may be nothing here other than coincidence, when you see comments like this it is worth thinking twice about praise coming from folks with no sites, no history, and no details:

Aside from the content itself, I’ve noticed the commenting and voting patterns on Reddit for articles about AccessiBe are suspicious. I always assumed they had “help”.

As of 29 December 2020, accessiBe is continuing its sock puppet efforts. At least 110 tweets with the exact same text and image, but a different URL to track performance, appeared in one week. You can browse them (and report, as I did, as you see fit) from this custom Twitter search bounded to those 7 days. This is in violation of Twitter’s terms, and I am guessing is not the only coordinated tweet storm acessiBe has run.

Update: accessiBe Uses Coordinated WordPress Plug-in Reviews (17 February 2021)

Joe Dolson, a WordPress contributor, plug-in developer, and member of the WordPress accessibility team, has published a post, AccessiBe & the fake WordPress plug-in reviews. Joe has tracked, flagged, and managed to get removed five-star reviews for the accessiBe plug-in that he identified as fake.

At the time I reported the reviews, AccessiBe showed 31 five-star reviews, 2 four-star reviews, and 2 one-star reviews. This can still be seen by Viewing the plug-in page in the Wayback Machine.

[…]

Since reporting this issue, all 33 positive reviews on AccessiBe’s plug-in page have been removed. More are starting to appear already, of course – but given AccessiBe’s prior record of paid promotion, it’s hardly a surprise.

You need not just rely on his word. Joe has offered to share his spreadsheet. Obviously I agree that the reviews were suspect and that his findings amount to more than coincidence or I would not add it here. You can also go to the Wayback capture from October 24 to see the 10 five-star reviews that were live then.

When I checked after the purge of fake reviews, a new five-star review had appeared. The person who left it does not use the WordPress accessiBe plug-in on his site, which has easily 30 automatically detectable errors (via Axe and ARC). While his client list does not say what services he offered them, and does not link to the sites, searching shows none of them use it either.

Given accessiBe’s ongoing history of astro-turfing, this all fits.

Added 19 February 2021: WordPress Tavern has some coverage in its post WordPress.org Removes Fake Reviews for AccessiBe Plugin. It also touches on the suggestion that accessiBe’s sock puppet accounts are down-voting other plug-ins.

accessiBe Will Not Honor its Guarantees (14 December 2020)

One of the primary claims accessiBe makes in its marketing, and its CEO made in his response video to this post, is that accessiBe protects its customers from lawsuits.

Does accessiBe protect me from lawsuits?

Absolutely! accessiBe turns inaccessible websites into WCAG and ADA compliant websites. But not only that, accessiBe provides you with a Litigation Support Package, in case you need to prove your ADA website compliance, and guides you through the process.

It claims to do this because its plug-in makes your web site compliant to all the necessary standards — and more.

Does accessiBe cover all accessibility requirements?

Yes! accessiBe covers the WCAG (Web Content Accessibility Guidelines) version 2.1 at the AA level success criteria, and in certain areas even level AAA. This is a step beyond what legislation requires.

Even if you make updates to your site, you will be covered.

WCAG 2.1 & ADA Compliance

Ongoing WCAG & ADA compliance even when website updates

The accessiBe Terms of Service (ToS), however, stands in stark contrast to these guarantees. Some excerpts follow.

2. […] The functionality of the accessiBe Systems requires that the Licensee Website in which they are embedded be websites based solely on HTML files and tags, and that the source code be written according to the Standard of the World Wide Web Consortium (“W3C”), without any errors or validation warning in W3C’s troubleshooting inspections; please note that Licensee changes to such website may impact the functionality of the Service. By way of example, accessiBe Systems do not support other components, such as Canvas, Flash and/or SVG.

Essentially you have to have valid HTML, or HTML that already passes SC 4.1.1 Parsing.

But accessiBe’s terms go beyond that, since a validation warning is not a 4.1.1 error. Essentially accessiBe makes it your responsibility, not its own, to ensure the HTML of your site is beyond what WCAG requires and is also technically perfect.

Since accessiBe exempts SVGs, for example, if you use an SVG on your page then accessiBe will not fix it. It may even declare the entire page is not covered per these terms. Same for PDFs. And video. And audio. And canvas. And so on.

Not only that, your Angular, Vue, React output will generate warnings (if not errors) from the W3C validator. Third-party tools (ag-Grid, chat widgets, etc) as well. Custom elements too. Even microdata for your SEO efforts (itemprop is valid HTML, but not according to the validator). If you use these technologies, then accessiBe’s ToS are pretty clear its guarantee does not apply.

2. The accessiBe Systems are only compatible for use by users on the following operating systems and browsers: Chrome, Firefox, Safari, Microsoft Edge, Internet Explorer 11, Android 8, and iOS10. […]

Even if your HTML is technically perfect, if your users come in on the latest release of Android or iOS, or the second-latest, or third-latest, then you get no coverage guarantee for any challenges they face. Which means you might be best served putting an Android 9–11 and iOS 11–14 users can bugger off banner at the top of your site.

5. The Licensee is aware that the installation of the accessiBe Systems cannot guarantee that claims will not arise, and that embedding the accessiBe Systems in the Licensee Website does not, on its own, fulfill all of the requirements of applicable law in respect of website accessibility (accessiBe does not remediate PDF files or create subtitles for videos, for example). […]

Here accessiBe rightly asserts it cannot prevent someone from filing. The ToS goes on to add accessiBe’s service does not satisfy accessibility laws. It specifically excludes captions, a requirement to pass WCAG under Level A (not even AA) thanks to 1.2.2 Captions (Pre-recorded).

5. […] The Company does not undertake that the Licensee Website will be 100% accessible at any given moment, owing to factors such as Licensee changes made to the Licensee Website, issues originating in the Licensee Website and /or limitations stemming from technological reasons. The Licensee irrevocably waives any claims against the Company from any liability, legal or otherwise, and that it shall assert no claims against the Company in this regard (including in relation to any Claims Support Services, if provided).

To put a bow on this, accessiBe is not promising 100% compliance. If you change the site in any way (by editing content, or maybe it has a social media feed), accessiBe promises nothing. If your web site does not use solely technically perfect HTML with no validator warnings, accessiBe promises nothing. If there is a known browser bug or a screen reader behaves unexpectedly, accessiBe promises nothing.

These Terms of Use are subject solely to the laws of the State of Israel, with sole and exclusive jurisdiction over any dispute arising hereunder to be adjudicated in the competent courts of Tel Aviv-Jaffa.

I leave it to your legal counsel to decide if your complaint about accessiBe’s failure to honor its marketing commitments to ADA Title III or EN 301 549 should be handled in a jurisdiction that is in neither of the regions where those laws apply.

Incidentally, the accessiBe home page has 38 errors and warnings according to the W3C HTML Validator. If I take the rendered source code from the accessiBe plug-in from the Aquis site (see December 2020 Release above), it has 17 errors, 15 of which are the missing alt attributes I referenced. Given accessiBe promises you can customize the design for the widget, this also explains how it let Aquis get so many contrast errors — accessiBe’s tool won’t even protect its customers from accessibe or themselves.

If accessiBe’s own web site and product would not be covered by its own Terms of Service, why would you trust the product? And if accessiBe claims in its marketing to support WCAG and then explicitly excludes at least one SC (and puts the burden on you for at least one more), why would you trust accessiBe?

Once again, Karl has already made a video detailing much of this.

Added 19 February 2021: A human-sized birdie informed me that I may have I overlooked the significance of this specific definition under the General section at the start of accessiBe’s Terms of Service:

h. “Standard” means WCAG 2.1 level AA success criteria.

That very much affects the meaning of this paragraph under the section Sale, Purchase and Termination Policy

2. […] The functionality of the accessiBe Systems requires that the Licensee Website in which they are embedded be websites based solely on HTML files and tags, and that the source code be written according to the Standard of the World Wide Web Consortium (“W3C”), without any errors or validation warning in W3C’s troubleshooting inspections; […]

Since Standard means WCAG 2.1 AA, and accessiBe requires no validation errors or warnings against WCAG 2.1 AA, that means you must have a site that meets WCAG to be covered by accessiBe’s Terms.

If you are not covered by accessiBe’s WCAG compliance guarantee until your site is WCAG compliant, then what guarantee exactly does accessiBe offer?

If accessiBe promises to make your site WCAG compliant only after you make your site WCAG compliant, what exactly is the point of accessiBe?

Update: accessiBe May Have Lied about JAWS (9 March 2021)

There is a comment on my overlay post where an accessiBe representative asserts a relationship with JAWS, the screen reader from Freedom Scientific. I struck part of that comment because I received the following email this morning:

Mr. Roselli:

This represents Vispero/Freedom Scientific. We have identified a false statement re: accessiBe and Vispero’s JAWS product on your website, at https://adrianroselli.com/2015/11/be-wary-of-add-on-accessibility.html#comment-164513. The text at the suite states falsely that “The process also included leading experts in accessibility, as well as a developer from the JAWS team whom, as you may know, is an eminence in screen-reader technology in the world today.”

Neither Vispero nor any of its developers have ever worked with accessiBe relative to any products and services.

Please remove such reference to JAWS and accessiBe from your website.

I agreed to strike it visually and programmatically but retain the text itself, since it demonstrates a deceptive marketing practice on the part of accessiBe.

I can immediately think of two places where accessiBe has made this claim:

• A 2019 video, where at the 10:23 mark accessiBe’s CEO says, We at accessiBe have collaborated with the lead developer from the JAWS team, which is the world’s most popular and advanced screen reader…;
• A 2019 knowledge base post on the accessiBe site from its CRO (then CMO) that says, For more than 18 months, accessiBe’s developing process focused on working back to back with a developer from the JAWS team.

I expect accessiBe’s C-level team is getting a similar cease and desist as well.

If you have other examples of accessiBe making this claim, let me know so I can forward it to the attorneys at Freedom Scientific.

Update: accessiBe Relies on False Advertising (15 December 2021)

The site Overlay False Claims documents provably incorrect assertions made by accessiBe throughout its marketing efforts. The site also tracks other anti-competitive behavior, downloads for use in legal action or consumer complaints, and links for filing consumer complaints throughout the US and Canada.

If you have other examples of false advertising (perhaps you have received marketing emails, or been pitched by your web site vendor / overlay reseller) or links for filing consumer complaints in other countries, then please submit a GitHub issue.

Community Response to accessiBe (17 March 2021)

When I say community, I mean the disability community. People who are most likely to encounter accessiBe. People that accessiBe claims it is ultimately helping. As accessiBe’s profile in the disability community has grown, so has this post with the community’s experiences. I have re-organized it to group the related content, so the timelines may be a bit off.

On 11 March Karl Groves spun up the site Overlay Fact Sheet to gather details about the intent of overlays in general, how they enable conformance to standards, real-life experiences from people who have interacted with overlays, links to more resources (including this post), and a list of signatories who commit to not cutting corners (my words) to achieve accessibility.

As a result of claims from end users and denials from accessiBe, Karl Groves proposed a moderated Q&A / debate between him and accessiBe for 17 March 2021. In response, accessiBe chose to run its own webinar on 16 March 2021 where it asserted it would answer legitimate questions. When the webinar happened, accessiBe ran out of time for questions because it spent the bulk of the time running yet another demo, claiming it would answer question in a follow-up webinar. Granted, accessiBe telegraphed this bait and switch beforehand.

Added 28 March 2021: accessiBe ran its webinar. One hour of accessiBe demoing on its own demo site (which we know has been optimized for its overlay), with selected questions starting at 1:09:55. He answered three questions (two of them twice) plus a question from its own CVO, Michael Hingson. W3C and WordPress community (ongoing) promises aside, he never addresses the items identified in user videos, promising to do so in another session (the switch). That should give them plenty of time to write custom rules to make their overlay less broken on those sites.

Given how Michael Hingson used his platform on the Mosen at Large podcast to assert that accessiBe’s detractors were focused on code, I was only mildly surprised to see how often accessiBe’s CEO spent diving into the browser dev tools and bragging about the code the overlay outputs. This suggests one of the two C-level leaders of the organization is unfamiliar with what accessiBe actually does.

Mosen at Large Discusses accessiBe (17 March 2021)

Jonathan Mosen dedicated a three hour episode of his Mosen at Large podcast to accessiBe: Episode 105: The AccessiBe controversy. Can AI make the web fully accessible in a few short years, or might it make matters worse?

I embedded the episode’s YouTube video as well:

The first hour is made up of interviews with Samantha Evans, then Stephen Clower, and then Chancey Fleet, all sharing their own experiences of barriers to using sites with the accessiBe overlay. After that he spends a bit over an hour interviewing Michael Hingson, accessiBe’s new Chief Vision Officer. After the interview he has Curtis Chong and then listner feedback.

Because Michael Hingson referenced me during his block of time, I want to address three comments in particular. For this first commment, Jonathan quickly confirmed Michael was talking about me:

I knew some of it. I had heard about a couple of the major detractors, one of whom is not blind, who purports to speak on behalf of blind people, and one who is blind.

I am not blind. I also do not purport to speak on behalf of blind people. My criticism details how accessiBe is broadly a barrier to users with disabilities, along with the technical bits to back it up. The blind community has been particularly vocal, likely because accessiBe’s overlay and messaging has resulted in outsized harm. Michael may be conflating these two things. A less generous take is that he is trying to discredit me to an audience of listeners he knows is overwhelmingly blind.

Later, after Jonathen Mosen asks about accessiBe claiming victimhood, Michael asserts accessiBe is not trying to play the victim and goes on to say:

…accessiBe has, for months, not responded to articles like the one by Roselli and so on…

This post went live on 29 June 2020; accessiBe emailed me and posted a 2+ hour uncaptioned video response on 4 August 2020 (embedded at the end of this post). That is a 36 day gap, or barely more than one month. Yes, this is a minor, picayune point, but building a defense on even a tiny false claim (that also references me) warrants a response here. It is part of the Gish Gallop model of accessiBe’s responses.

After that Michael said he would offer specific examples:

I mentioned the meeting that we had with Chancey, and Adrian Roselli was added, and there were comments made at that meeting that were not acceptable.

The phrase there were comments made at that meeting is a weasel phrase. It does not say who made what comments. It is also not a specific example.

Evidence told me not to trust accessiBe enough to believe they would recount that call honestly, so I had my own audio recorder. When I joined the call I saw that the Zoom session was being recorded as indicated solely by a visible icon. They did not announce it was being recorded nor did they ask permission. I did, however, ask and get permission.

I have an audio recording and transcript of the call, so if Michael cares to share what I may have said that he found not acceptable then I will compare it to my recording and confirm. Otherwise I think we can dismiss his statement.

Update, 28 March 2021: In a Twitter thread, Chancey Fleet calls out accessiBe’s CVO (Mr. Hingson) for mis-representing what she said on her call with them. He never responded to her. I also compared the transcript with Mr. Hingson’s assertions and found no match for what he claimed.

In a follow-up Mosen at Large episode, Jonathan Mosen takes comments from listeners and they are all critical of Mr. Hingson’s performance and message. One even notes that, as I asserted above, I was not presuming to speak on behalf of the blind community.

More Mainstream Press

The interactions between accessiBe and the blind community in particular (outlined in some of the older updates that follow) has raised its profile beyond community outlets.

Vice (17 March 2021)

Vice published an article today, People With Disabilities Say This AI Tool Is Making the Web Worse for Them

This quote stood out to me:

“AccessiBe can only solve the problems that AccessiBe can solve,” he said. “What we need to do is recognize that when AccessiBe does what it does, it enhances websites and I think that’s the most important thing that detractors need to accept.”

There is now plenty of evidence, and experience, telling us that accessiBe does not enhance web sites when it does what it does. Further, users (detractors or otherwise) do not need to accept this bogus claim. In fact, they must not accept it as it flies in the face of evidence.

In the interest of full disclosure, I was interviewed for this piece but I am not named. This is a good thing. While I am happy my own research has given folks affected by accessiBe some context to inform the brokenness they encounter, I am more happy to see the voices of those most affected get elevated (above mine too).

NBC News (9 May 2021)

NBC News did its own investigation and published Blind people, advocates slam company claiming to make websites ADA compliant.

Some excerpts:

“Almost no one gives any specifics to actual websites that really don’t work for them,” Ekerling wrote in an email. “This is because they don’t really test us, nor have really used us. At most, they went on a website out of anger and didn’t even try to understand.”

[…]

[…] AccessiBe denies that Eyebobs and Masterbuilt Manufacturing were using its product at the times identified in the lawsuits.

[…]

Amy Mason, a technology instructor at the Lighthouse for the Blind and Visually Impaired in San Francisco who is blind […]. When they got to the website with AccessiBe, every few seconds it kept prompting them to enable AccessiBe’s screen reader mode.

[…] The company said it has since fixed the issue with the repeated prompts to enable AccessiBe.

I cherry-picked those excerpts because they are not true. Many people have tested accessiBe, not just me. Eyebobs and Masterbuilt reference accessiBe by name and the Eyebobs case includes videos of accessiBe failing. The ongoing prompt to enable accessiBe was not fixed at the time of this writing (confirmation 1 and confirmation 2).

For full disclosure, I was interviewed for this piece as well.

Wired Magazine (12 November 2021)

Wired gathered information after the disastrous loss in the Eyebobs case and talked about the promises of AI overall, using accessiBe to demonstrate the limitations, in the article This Company Tapped AI for Its Website—and Landed in Court. These two paragraphs stood out to me:

In a statement, AccessiBe’s head of marketing, Gil Magen, said the company had analyzed Eyebobs’ website and found it complied with accessibility standards. AccessiBe offers clients assistance with litigation but Eyebobs declined, the statement said.

In its own statement, Eyebobs said AccessiBe failed to respond to requests for meetings with its lawyers. “Eyebobs is no longer working with AccessiBe nor will we in the future,” the statement said.

The assertion that accessiBe found the Eyebobs site conformed to WCAG, given that Eyebobs lost the case, either demonstrates accessiBe is terrible at WCAG (I maintain accessiBe does not understand WCAG) or that acessiBe is lying. I think both are true since admitting the site had WCAG failures would undermine its product.

Given that context, it also makes me highly doubtful of accessiBe’s claim that its client declined the litigation support accessiBe promises, particularly when the client claims accessiBe failed to respond to requests for meetings.

I thought this update at the end was interesting: Updated, 11-11-2021, 2:20pm ET: This story has been updated to include that Joshua Basile [AccessiBe’s community relations manager] is a quadriplegic. This suggests that accessiBe might have come back with a correction, and chose to flex its disability bona fides instead of challenging other material in the piece. I could also be completely wrong (the writer may have simply forgotten it).

13 Letters Podcast (01 April 2021)

I hesitated sharing this since it is mostly just me talking. But in the interest of completeness I was a guest on the 13 Letters podcast, specifically the episode Adrian and the Overlays.

Financial Times (7 April 2024)

Financial Times has just published Blind internet users struggle with error-prone AI aids. While it incorrectly frames overlays as ‘AI’, that is partly a function of disingenuous marketing claims meant to cash in on the terms that both investers and customers are pouring money into. Regardless, I think the sub-head distills it very well: Unreliable software installed to comply with rules to help disabled people navigate online has prompted thousands of lawsuits.

The FT article notes global laws which require web sites are accessible to disabled users. Those laws prompted companies to look for quick fixes in the form of overlays (which we know are aggressively marketed with problematic guarantees).

However, those businesses that rely on accessibility code assistants and “overlays” — software that transforms a website so that it can be understood by assistive technologies — appear to have exposed themselves to more liabilities as the tools still need improving.

The article shows that accessiBe, AudioEye, EqualWeb, and UserWay each fail to remove testable errors, with accessiBe ranking worst. It even calls out AudioEye (second worst) has leaving one in seven sites with poor contrast.

It gives EqualWeb an opportunity to respond, where it unintentionally acknowledges how ineffective its overlay is:

Anat Cohen, vice-president of business development at EqualWeb, said the issue on Zara’s website was not related to the accessibility technology but “stems from the website’s structural design”.

It also gives UserWay an opportunity to respond:

Level Access, an accessibility provider, has just bought UserWay, an overlay maker. Its founder and chief executive Timothy Springer has addressed some of the criticisms of UserWay’s technology and has promised accuracy and transparency in Level Access marketing.

Note the promise is for Level Access marketing, but not UserWay marketing (which is retaining the UserWay brand and marketing efforts). Prior behavior suggests no positive changes forthcoming.

Again, the barest poking at claims and code show how accessibility overlays are broadly ineffective and primarily built on lies. Lies which have harmed, and continue to harm, users.

Update: accessiBe Is Ableist (5 September 2020)

Yes, this update is out of order in the flow of the page, but that is partly because the original video response from accessiBe, along with my own response back, takes up so much space and adds so little to the issues I identified (they agreed with many of them) that it seems hardly worth navigating through to get to further updates.

Flush with funding and facing valid criticism from accessibility practitioners, advocates, users, and members of standards bodies, accessiBe has finally taken to Twitter in an attempt to polish its image.

Almost immediately accessiBe pushed out its first tweet of “inspiration porn”, a term coined by Stella Young in her 2014 TED Talk, I’m not your inspiration, thank you very much.

Nothing is impossible #peoplewithdisabilities #PWDs #webaccessibility #accessiBe twitter.com/SportsCenter/status/1275…

The tweet it links shows a high jumper with one leg in an uncaptioned, non-audio-described video.

It also did not take long for accessiBe to promote its own efforts at “disability tourism” through a disability simulation. In it, the accessiBe presenter blindfolded an audience to try to force empathy and give them that real-life blind experience (yes, that is snark): accessiBe Founders blindfold and lecture to 600 Employees of Digital Ocean at Florida.

Lainey Feingold’s tweet captures the frustration, but you should look at the replies and quote tweets to see how problematic this is for people with disabilities.

I have to stop reading this stuff! #Accessibe "distributed eye masks to blindfold every person so they could experience for themselves the frustrations + disappointments a blind user feels when they visit a site without accessiBe" accessibe.com/blog/news/accessibe-founders-… HT @DeafGirlWalking #a11y

These are just two quick examples of ableism from a company that claims it wants to improve the web for disabled people. These examples demonstrate that accessiBe’s framing of disability is nothing more than a marketing pitch.

Update: accessiBe Asserts a Silent Majority (14 February 2021)

Chancey Fleet was asked for a meeting by accessiBe’s new Chief Vision Officer. I joined the call and Chancey started offering suggestions well before one of the founders later asked for some, demonstrating they were not listening. The call ended before we got through them all, so I wrote them up in a post, Free Feedback for #accessiBe. Much of my feedback is informed by the same failures with accessiBe’s service that I outline earlier in this post.

One thing that stood out in the call was when a founder asserted that a silent majority of users were happy with the outcomes accessiBe’s service offers, far outnumbering its vocal detractors. While Chancey explained that most users are not disabled and therefore not affected, even for those who are disabled, presenting anything is better than the black boxes many sites were beforehand. That, in itself, does not make accessiBe’s results accurate, usable, or even a net good, considering the messaging that villainizes disabled users.

I did not expect to find accessiBe had used the silent majority defense before, and that accessiBe has been trying to silence detractors by framing their valid experiences as misconceptions. Essentially accessiBe has been scheduling calls with people who have genuine problems with its tool and gaslighting them. When I shared the feedback post, stories of negative experiences started to come in on Twitter. Following is a sampling.

The founders of #AccessiBe are interpreting the complacency of nondisabled customers and the bone-deep fatigue of disabled users to mean that a "silent majority" — their actual words — is grateful for and enjoys AccessiBe. Let's not be silent then twitter.com/marconiusiii/status/136103…

I experienced much the same treatment when on a call with Shir after the SiteAccess conference last year; lots of marketing talk, no time to put up actual usability points and examples I had run into.

Pretty much, as well as citing their silent majority of blind users who approve and "test" their product. I ran into so many issues just going through their example sites alone, I didn't want to give them a fully free audit of how much they were doing wrong.

If anyone even gets it into their head to use #accessiBe to instant-fix their accessibility woes, please tell me so I can hit you in the face with a trout. Do not. You'll just make it worse. twitter.com/ChanceyFleet/status/13610…

I opened their "ADHD" mode on one site and was like, what? No. This is absolutely not how I want to be served.

But, hey, enjoy that Series A that could have funded 10 profitable disability-led companies!

their overlay creates a horid user experience mostly and if you dare to try and dismiss it, it will use aria-role=alert to talk over content to ensure you turn it back on

How frustrating and unacceptable! I have recently found a few websites that use this technology and they are completely in accessible with a screen reader.

I thought I was the only one…I'm in the silent majority, but not the one #AccessiBe thinks exists, but the one who thinks their product is cac madra (that's "dog shit" for those of you without Irish). twitter.com/mattmay/status/13610…

The fastest way to get me to close a website is to be forced into a segregated and unusable experience by the #AccessiBe overlay. Poorly applied #a11y band-aids are not equivalent to an inclusive and usable UX; they serve only to make companies lose our business and patronage.

I won’t buy anymore content from @TheGreatCourses until they get rid of #AccessiBe and do accessibility properly. I believe #AccessiBe, last time I attempted to use the site, actually breaks the poorly implemented login form, where it actually worked before #AccessiBe. twitter.com/chanceyfleet/status/13610…

Is there someone at AccessiBe I can yell at? Because seriously it took me 35 minutes to change the bank account for my rent payment comes out of and fully 30 of those minutes were working around their shitty design.

"Press alt+1 for accessibility mode. Press alt+1 for accessibility mode. We see you are blind and haven't pressed alt+1 for Accessibility Mode. Did you know that you can press Alt+1 for Accessibility Mode? Perhaps you are blind and slow and havent figured out you can press …"

I am not grateful for Accessiby. I don't enjoy the tool when I encounter it as an end user. Add to this their being wholly uninterested in improving the product when approached with sensible suggestions by multiple subject matter experts. twitter.com/ChanceyFleet/status/13610…

If you take some time and explore the #accessiBe hashtag on Twitter, you will see the only people sharing praise for the product are paid marketers (as I demonstrate earlier in this post) and those who do not need affordances. The majority of experiences with accessiBe are complaints. You would need a sizable and demonstrable silent majority to warrant ignoring them, or a motivation to dismiss them.

The reason accessiBe uses this approach is because you cannot disprove it. Bear in mind accessiBe also cannot prove it. In fact, accessiBe’s approach is a variation of the argument from silence logical fallacy. One they have clearly bought into completely and use like a cudgel.

Update: Disabled Users Block accessiBe (18 February 2021)

When you promise your product works perfectly and that disabled users love it, it may be difficult to reckon with these very users when they start sharing a method to disable your product.

Frustrated by accessiBe’s inaccessible product and failure to listen to years of complaints, some users have been sharing the domains and IP addresses to block it at their routers or with ad blocking extensions. They have determined that the best experience they can have with accessiBe is none. Perhaps the real silent majority wil be those who never have to encounter it, thereby no longer needing to complain.

Following are some examples of this recent push of people to take control of their browsing experience.

It appears acsbap.com and acsbap.com are the only two domains currently used by #AccessiBe to serve their malware. In case they host more aliases, block their IP instead. Currently it is 167.172.136.187.

Hot off the press. Tired of a11y overlays? Want them to stop asking you to press some key, or stealing focus? Install the adblock+ extension, go to advanced settings, filters tab, and add this filter rules list url. files.derekriemer.com/evilA11yNasties.txt

I'm reconfiguring my router to use Pi-hole for DNS and DHCP. Assuming the next twenty or so minutes go as planned I'll get faster browsing, reduced adds and best of all no more #AccessiBe

Here are the #AccessiBe domains you want to block. acsbap.com
and acsbapp.com

Current status: Adding #AccessiBe domains to my router for network-wide blocking. acsbap.com and acsbapp.com if you want to add them yourself. Should also work on a per-device basis if added to adblocker.

Sweet. Changed my router to use Open DNS, added acsbap.com and acsbapp.com, and now my network is entirely protected from #AccessiBe . Should be the last time I"m prompted to "Press alt+1 to mangle the site you're visiting with our screen reader mode".

Just go to namecheap.com and see if you get the stupid alert. If you don’t after a few seconds, you’ve got it fixed. If you do get the alert, then it’s not working right.

They have become less silent and it turns out they do not like the service.

You should be noticing the vast influx of us #Blind users speaking out about how poor the #AccessiBe experience is with a screen reader. For every person you find for a positive testimonial, we have 10 or more who hate these overlays. twitter.com/AccessiBe/status/13617…

In fact, I can't even navigate that testimonial page in #iOS since the #AccessiBe overlay keeps silencing and cutting off #VoiceOver. you are not listening and you are not testing, you just want people to buy into your "protection." #A11y #Fail twitter.com/AccessiBe/status/13617…

Added 27 February 2021: Stephen Clower has gathered instructions for blocking accessiBe in his tutorial AccessiBe Gone. He gives steps for blocking accessiBe’s scripts in Windows, macOS, and Linux. He also links to Better for Safari and Derek Riemer’s AdBlock Plus filter.

To be clear, as someone who has had to fight for access for over 20 years, I find this whole gig draining and exhausting. But as I’ve learned the hard way, if no one else is going to step up to the plate, I might as well. Share and enjoy.

Added 28 March 2021: In the follow-up Mosen at Large episode about accessiBe, we hear from two developers (Mike Calvo and Matt Campbell) who have released a browser plug-in to disable accessiBe and other overlays. The add-on, available at AccessiByeBye.org, will monitor for overlay scripts, block them, and track the sites using them.

The ongoing lesson is that users do not feel accessiBe has delivered on its promise and are actively routing around the damage.

accessiBe as Privacy Risk (28 July 2021)

Léonie Watson did some legwork to identify what sort of guarantees or protections accessiBe offers for the privacy of your personal data when the overlay is active on a site. In her post AccessiBe and data protection? she lays out her findings.

Essentially accessiBe’s own privacy policy allows it to aggregate data from its overlay and other sources:

Not only can AccessiBe identify me as a unique individual with a disability, they can also associate that information with my name, and any other information they can obtain from LinkedIn, Twitter, and other public sources.

The ongoing failure of accessiBe to respond to Léonie’s requests for its Data Protection Impact Assessment (DPIA) suggests it may have some GDPR issues as well.

As a new member of the W3C, accessiBe should be expected to honor the W3C Web Platform Design Principles, specifically § 2.7. Don’t reveal that assistive technologies are being used.

Statement from Haben Girma, Human Rights Attorney (5 May 2021)

Haben Girma has been advocating on behalf of the disabled community for years. She wrote about being the first Deafblind person to graduate from Harvard Law School. When she weighs in on overlays in general, and accessiBe in particular, it is not just from personal experience but also based on her recognition of the harms the tool is creating.

NFB Revokes accessiBe Sponsorship (24 June 2021)

[…] In particular, it is the opinion of the Board that accessiBe peremptorily and scornfully dismisses the concerns blind people have about its products and its approach to accessibility. […] The nation’s blind will not be placated, bullied, or bought off. Therefore, the Board revoked accessiBe’s sponsorship of the convention on June 22, 2021.

Since accessiBe became a gold sponsor for the National Federation of the Blind 2021 National Convention and was placed on the schedule to give talks, the NFB constituency has been up in arms. As of today, accessiBe has been wiped from the convention sponsor page

The announcement came on Twitter at nearly 6pm on 24 June.

Of course with a great deal of effort on accessiBe’s part, it could conceivably be back on the bill for 2022.

Nielsen Norman Group Confirms Users Don’t Want It (1 May 2023)

Nielsen Norman Group has an article about the challenges screen reader users on mobile device experience across the web. The last section of the article is 4. Accessibility Menus: Not Helpful, which deals with the accessibility overlays offered by accessiBe and UserWay. Within the scope of the article, Nielsen Norman Group refers to overlays as “accessibility menus”. I adjust for that in the following quoted excerpts.

We wondered how practically useful and recognizable these [overlays] are to real users who are blind or have low vision. To answer this question, we had participants in our study perform tasks on mobile websites with these [overlays]. The short answer is that our screen-reader users did not find them useful.

[…]

When participants did not open the [overlays] on their own, we prompted them to open the menus and see whether there was anything that seemed useful inside. After briefly exploring one [overlay], a participant commented, the first thought that comes to mind is what a waste of time and money […] when anyone using a phone that needs a screen reader is already gonna have one built in.

[…]

[…] As one blind user put it, I hate [overlays] because […] I think they make companies feel like they don’t need to actually work on making something accessible […] it is not a substitute for actual accessibility testing and, to me, it feels like just a Band-Aid that can almost make it worse sometimes. […] Most accessibility issues are structural and cannot be fixed by a simple plugin.

Nielsen Norman Group is confirming what disabled users have been saying for years — overlays are not helpful. Including overlays from UserWay and accessiBe.

13 May 2023: accessiBe Redemption Tour Starts

The CEO of accessiBe penned a letter in the May edition of the NFB’s newsletter, Braille Monitor. It is titled A Heart-felt Apology and a Chance to Start Again. You will not find this letter nor an apology of any kind on the accessiBe site. Not even in its linked 8,300 word Purpose Statement. I am unaware of any practitioners or prior customers who have received this apology either.

The CEO says he is writing to address our past actions and outline what we are doing and have done to change and improve. The letter does neither. He does, however, seem to assert his Type 1 diabetes makes him understand the challenges of assistive technology (this is not a judgment, simply a framing) without addressing the challenges to AT that the accessiBe overlay creates.

He acknowledges what we all knew, that he was a newcomer to the accessibility and disability communities. This is how you get disability dongles, incidentally. The supposed good news is that that free labor of the community in the form of feedback from Federation members and many individuals and disability rights activists has guided [him] and accessiBe through a meaningful transformative process.

Nowhere does he acknowledge any specific prior harms accessiBe will correct. The accessiBe cartoon depicting accessibility as an extortion racket is still live on LinkedIn, for example. While he claims they have replaced [their] chief marketing officer and discarded previous campaigns, it seems that is not completely accurate.

How much of accessiBe’s latest round of $58 million in funding are you going to get for all your free labor teaching him how to fix its software, communicate with the community, and attenuate its messaging? How much do future rounds of funding depend on launching new products (outlined in the Purpose Statement) and clearing its name with the very communities it has harmed?

Incidentally, the email address he lists for feedback is not the same one he used in August 2020 to threaten me not to, and I quote, force our hand. I expect the email address will be managed by the new PR team. That is, frankly, a good idea given his prior behavior with others critical of accessiBe.

The CEO says Making significant changes takes time, and we understand that building trust is a lengthy process. Since accessiBe first came on my radar four years ago in early 2019 I feel it can check in with me in early 2027 for an assessment of how it has done, meaning I am less trusting than Karl. I hope I never have to update this post again.

7 June 2023: accessiBe Redemption Tour on Mosen Podcast

Episode 232 of Living Blindfully (formerly Mosen at Large) has the CEO of accessiBe, Shir Ekerling, on to discuss his community apology. There is a transcript available. The following YouTube embed does not start at the right point, but you can jump to 17:55 or go directly to the video at 17:55.

As accessiBe continues its rehabilitation tour, I am going to call out some specific items from the episode that I feel give insight into how serious this effort is. I have no interest in giving accessiBe more free advice on how to market itself.

Ekerling: And again, [laughs] I don’t want it to sound like an excuse, but we are first time founders. This is my first time company. I created it when I was 28 years old. I was young. I was ambitious. I wanted to do a lot of good things. My co-founders wanted to do a lot of good things. We thought that we’re doing the right thing.

I appreciate the challenge of being a founder. I was one at 23 years old, with co-founders. We did not have the millions in funding accessiBe had, the access to marketing professionals, and yet we never behaved the way Shir did. He treats his age as an excuse, when at 28 he was more than old enough to have developed empathy and emotional maturity.

Here Jonathan Mosen disusses the call Shir Ekerling had with Chancey Fleet and me back in 2021:

Mosen: I was leaked in advance of that episode. A recording of a Zoom call between AccessiBe Chancey Fleet, who for those who don’t know her is a blind accessibility expert and advocate, and Adrian Roselli, who’s sighted but he’s also an accessibility advocate.

And interestingly, it was AccessiBe who leaked that recording to me to try and make the case that Chancey was being unreasonable.

But what I heard when I listened to that recording was Chancey trying to calmly make her point while being repeatedly interrupted, invalidated by being told by you, specifically. I mean, you’ve talked about other people having gone, but you were still there. You told Chancey that she had misconceptions about the product. I felt that she was bullied and treated in an ableist, chauvinistic fashion.

I was unaware accessiBe leaked that call. Note that accessiBe was recording the call when I joined, did not ask permission, and only acknowledged it when I called it out on seeing the recording icon.

So it is insightful to know that in February and March of 2021 Ekerling was engaging in this practice. Barely 2 years ago.

Ekerling goes on to assert he has been apologizing for “a few years”, even though he was actively gaslighting and releasing information without permission barely 2 years ago.

Ekerling: We went silent for a few years. And we weren’t silent privately, but we were silent publicly. Privately, we were everything but silent.

Then this assertion:

Ekerling: Again, I don’t want to put anyone in the spotlight. But a lot of the people that I talked about that have helped us from a lot of different organizations, (Some of them are not from organizations, just community leaders.) Many of them, you know. A lot of you, you know them. And some of them are our biggest criticizers or critics. I think this is the right word. [laughs]

I am wary of this, and claiming you don’t want to shine a spotlight on anyone is just an easy way to dismiss the potential lack of well-known critics. So far I am unaware of major critics working with accessiBe. Note that “helping” may not be an intentional act — this post has arguably helped accessiBe extensively but I am not intentionally helping accessiBe.

Regarding the apology that was published only in Braille Monitor and not on the accessiBe site…

Ekerling: But first, let me answer a question. We have it on our website. Not only that we have it on our website, it has a dedicated page on our website.

This is true that we received that criticism. And once we received that criticism, I spoke with a lot of different people about that.

In the beginning, it was only on the Braille Monitor. But very very quickly, it went to a dedicated page on our website. And that page is linked from all our website pages in the footer to that page directly. It’s AccessiBe.com/Braille-Monitor-post. It’s a dedicated page for that.

Here Ekerling leads by asserting the claim is wrong, and then he acknowledges he posted it to the site in response to criticism. Ekerling leads with the revisionist history, a habit of someone used to lying for so long.

Ekerling: You will not see marketing from 3 years ago, and you won’t see those things in the last 3 months coming to the apology.

You will see that starting 2+ years ago, you will see hundreds, if not thousands of these things, and almost 90% of the things are that. So verify what I’m saying. Do that research.

And later, in response to a question about marketing as an extortion racket:

Ekerling: We have removed any such wording and any such language years ago already. It’s not a part of our marketing or business communication process.

Ekerling cited places we can search for accessiBe’s lack of problematic marketing messages. I am not on Facebook, I barely use LinkedIn or Twitter, and so on. What I can say is that 2+ years ago Ekerling was leaking a recording of a call with Chancey Fleet and me. The accessiBe cartoon depicting accessibility as an extortion racket was still live on LinkedIn at least of last month (and which was widely shared as an example of accessiBe being simply performative).

In fact, accessiBe has poured so much money into aggressive marketing tactics that Shir probably forgot it is still spoofing WebAIM’s WAVE checker to trick users into thinking the accessiBe overlay actually works:

We've released a new update to the WAVE accessibility tools with numerous improvements and bug fixes. This version now informs users that accessiBe and UserWay overlays may manipulate page content to suppress detection of accessibility errors.

And that was a downright dirty tactic — demonstrating it could trick an automated accessibility checker on demand but still not improve a page for users.

Ekerling: And everything that you will see on our platforms, that’s all community-driven. There isn’t a single thing today that AccessiBe makes that is not made by, or with, or reviewed, or verified, or created by a person with a disability in the process. And this is including software, including posts, marketing, campaigns, etc.

Remember that Ekerling identifies as disabled owing to his Type 1 diabetes. While that is not wrong, it is not the kind of disability that has an immediate impact on, or from, web accessibility concerns. So his bench of disabled persons may be deeper than what we expect as practitioners who seek input from the community on the work we do.

Ekerling: However, I do want to express a few things that you might not know about small businesses and the way that they can, or should approach accessibility. And I’m giving you now some observations of reality, having speaking with hundreds of thousands of small businesses (and we’re speaking with thousands of them every day).

That smacks of hyperbole. Mostly because Ekerling himself is clearly not speaking with thousands every day. What insights he gets are gleaned from sales staff and support reps. All filtered through KPIs and sales targets. We should treat insights from this kind of assertion warily.

Ekerling: There isn’t a single accessibility service today that we do not provide.

Of course I cannot confirm this. Nobody can. But I don’t think I have ever seen an accessiBe name on a browser or AT bug report. And that is absolutely an accessibility service I have provided to clients.

Ekerling: I’m sure 100% that there are issues today with websites using the overlay. I don’t think that it’s a perfect solution, or a service.

It’s nice to finally have that admission in the face of overwhelming evidence.

Mosen: But let’s just deal with this elephant in the room about data collection, because you’re saying that there are a lot of misconceptions out there about precisely what accessiBe knows about users who use websites with the overlay on it.

Ekerling: First and foremost, the absolute thing that I want to clear out, we don’t know anything about those users. We never have, and never will track any user, gather user data, sell any such information. I know that people thought that we were selling data and information that we collect from users or from websites. We never, never have done that, not even once, and never will do that. All the claims around that were complete untruth and were misleading statements.

As far as I know, accessiBe still has not responded to Léonie Watson’s 2021 request for a Data Protection Impact Assessment (DPIA) under GDPR. As far as I know, accessiBe has still not identified the “untruth” or “misleading statements” in Léonie’s post AccessiBe and data protection?. Again, casual dismissal with no evidence.

Mosen: But then you’ll be well familiar with Adrian Roselli’s article – AccessiBe Will Get You Sued. And he’s making the point that there have been some cases where legitimate lawsuits have been filed because people installed the overlays in good faith (not just yours but other overlays), only to find that the remediation hasn’t been effective. And so legitimate disabled people have filed suit.

And essentially, it’s a promise not kept, right? These people in good faith are paying the money to get the overlay on the site, only to be sued anyway, because the accessibility has not been fixed.

Ekerling: The lawsuits that Adrian Roselli brought, … And I already addressed this. A few years ago, I sent Adrian an hour and a half video of me addressing the points, point by point, the technical and the non-technical, the legal and the rest of them directly. I don’t know what happened with the video, but I did send it.

The lawsuits that he brought are not AccessiBe customers. Those are customers that received lawsuits. That’s true. But then, they joined AccessiBe to help them with the existing legal situation.

Those are not AccessiBe customers that were sued because they installed AccessiBe, and then it failed and a user sued them, or anything like that.

I know what happened to the hour-and-a-half video, Shir. I embedded it above. I responded to above (comments were disabled on YouTube). You know I saw the video because I replied to your email to ask for a captioned version before I would respond.

In fact, the last time Jonathan Mosen gave accessiBe a platform, your CVO, Michael Hingson, proudly said accessiBe had not responded for months, which was a lie then as well.

Mosen: So can I just amplify that? You are saying that no one has filed suits after AccessiBe has been installed claiming inaccessibility.

Ekerling: No. I’m saying that this is specifically about the Adrian Roselli lawsuits that he brought, at least that I’m aware of back then that I also already addressed. This is what I’m saying.

As for the lawsuits I include above, accessiBe is named in the complaints. How accessiBe chooses to frame it is up to Ekerling, but accessiBe is absolutely cited (as I have stated from day one). This continuing casual dismissal is not a good look for the apology tour.

Regarding the 785 (as of this writing) signatories to the Overlay Fact Sheet:

Ekerling: And by the way, we tried multiple times, and succeeded to speak and have a dialogue with many of these consultants. And we share, them and us, share a lot of the ideas, a lot of the notions around and about accessibility and the technical aspects of it.

I have regularly counseled against any private conversations with any overlay companies. From experience with accessiBe’s leadership on the call cited above to now knowing they leaked the recording of that call (and did not say so during this apology tour), nobody should take any private meetings with accessiBe. Make it public.

The email address Ekerling shares, as I noted for the previous apology, does not match the one he used with me in three years ago.

Throughout the interview Ekerling repeatedly asserts that accessiBe “went silent” for a couple years as it realigned its messaging. That is not my recollection, but I also blocked its overlay and made a concerted effort to stop giving this multi-million dollar company free advice. As the community grew weary, its hashtag on Twitter was taken over solely by Michael Hingson (accessiBe’s Chief Vision Officer), ostensbily trying to push the vehement and valid criticism out of view.

Broadly speaking, I don’t buy this. The behaviors are still there, incuding mis-representation of facts, revisionist history, and willful ignorance. Leopard, spots. Scorpion, frog. Choose your metaphor.

15 April 2024: accessiBe’s GAAD Sock Puppets

In Socks, lies, and accessibility, Jan Maarten quickly and easily identified 5 sock puppet accounts on Twitter that were boosting accessiBe on GAAD 2023 — which was just a few days after accessiBe’s CEO apologized for lying and said the company would lie no more.

Not only were their tweet images devoid of alt text, but the numbers he called were met with hang-ups, the web sites were referral sites, and none of them use accessiBe.

We all know GAAD is often used for performative accessibility efforts, we all know accessiBe prefers lying over actual outcomes, and so it is no surprise that these traits came together so brazenly last year despite a very public commitment not to lie any more.

10 October 2023: accessiBe Claim for IRS Tax Breaks under ADA

I am unsurprised that after accessiBe started its redemption tour we would find it has continued to leave bad information in place.

In a comment below, Thomas Gadbois pointed me to late 2022 claims accessiBe makes about IRS tax breaks that will offset the cost of its overlay product. But first, accessiBe mischaracterizes the intent of the Americans with Disabilities Act:

The Americans with Disabilities Act (ADA) was signed into law on 26 July 1990. The very first web browser, WorldWideWeb, which was created by the inventor of the web, was released on 25 December 1990. Five months after the ADA was made the law of the land (minus one day). The ADA is silent about the web, as I outline in my 2022 post ADA Web Site Compliance Still Not a Thing.

Either accessiBe is lying or it does not understand the ADA.

Further down the page, accessiBe quotes a 1998 IRS fact sheet (which it also links) which helpfully notes that the tax credit, established under Section 44 of the Internal Revenue Code, was created in 1990 (potentially pre-web also).

I offer accessiBe’s re-write alongside the document it links:

Here they are as plain text, with my highlighting:

The tax credit covers the following accessibility and ADA-related expenditures:

• web accessibility solutions or tools that optimize websites
• the hiring of sign language interpreters
• the purchase of adaptive equipment
• the production of accessible formatting on printed materials (braille, large print, audiotape, computer diskette)
• the removal of architectural barriers in facilities or vehicles
• fees for consulting services

The credit can be used to cover a variety of expenditures, including:

• provision of readers for customers or employees with visual disabilities
• provision of sign language interpreters
• purchase of adaptive equipment
• production of accessible formats of printed materials (i.e., braille, large print, audio tape, computer diskette)
• removal of architectural barriers in facilities or vehicles (alterations must comply with applicable accessibility standards)
• fees for consulting services (under certain circumstances)

The first bullet from accessiBe is completely made up; accessiBe has rewritten the IRS bullet to imply its overlay product is explicitly covered. The last bullet excises the critical qualifier on consulting services not getting blanket coverage, a service accessiBe has to add on since its overlay product does not do captions, PDF, and more.

For the possible $120 credit a small business could get, that amount would easily be eaten up by the couple hours of labor from their CPA to read through the paperwork, confirm it would apply, and fill it out. And that might still be cheaper than the time the business owner or bookkeeper might spend on it. Or maybe not when looking at the opportunity cost.