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

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):

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.

Text from the screen shot…

Defendant’s online store includes an “accessibility widget” which shoppers may allegedly use to enhance their user experience. The widget supposedly helps shoppers adjust font and emphasize titles, among other things. To use the widget, shoppers must activate, or “click,” a floating button on the right side of the Website. Once activated, Defendant displays a pop-up window. Shoppers who perceive content visually can click the pop-up window to activate the widget’s various tools. Unfortunately, the Website does not alert Plaintiffs’ screen readers when this pop-up window appears. Instead, their screen readers remain locked on the Website’s underlying page, making it impossible for them to use the “accessibility widget” independently and thereby defeating its purpose.

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.

Page 13 of Blair Douglass v. Masterbuilt Manufacturing, LLC Page 14 of Blair Douglass v. Masterbuilt Manufacturing, LLC
From pages 13 and 14 of the Blair Douglass v. Masterbuilt Manufacturing, LLC complaint.
Text from the screen shot of page 13…

There are two screen shots of the Masterbuilt home page; in both images the accessiBe widget is visible in the lower left corner.

38. Unfortunately, because of Defendant’s failure to build its Digital Platform in a manner that is compatible with screen access software, including VoiceOver, Douglass is unable to understand, and thus is denied the benefit of, much of the content and services he wishes to access from his smartphone.

39. As a result of visiting the Digital Platform, and from investigations performed on his behalf, Douglass found that the Digital Platform denies him full and equal access to the goods and services that Defendant offers. For example:

(a) On September 2, 2020, Defendant installed a $49/month plugin that the plugin’s maker represents will “turn[ ] inaccessible websites into WCAG and ADA compliant websites.”33 However, notwithstanding this marketing,

33 Accessibe, Homepage, available at https://accessibe.com/ (last accessed Oct. 12, 2020) (“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.”); but see Kris Rivenburgh, 2019 Review: AccessBe Automatic Website Solution Accessibility Using AI, Apr. 17, 2020, available at https://krisrivenburgh.com/2019-review-accessibe-automatic-website-solution-accessibility-using-ai/ (last accessed Oct. 12, 2020) (“AccessiBe amounts to a toolbar overlay and it won’t make your website accessible for numerous reasons.”); Karl Groves, Web Accessibility Overlays Do Not Work, available at https://overlaysdontwork.com/ (last accessed Oct. 12, 2020); Adrian Roselli, #accessiBe Will Get You Sued, June 29, 2020, available at https://adrianroselli.com/2020/06/accessibe-will-get-you-sued.html (last accessed Oct. 12, 2020).

Text from the screen shot of page 14…

There are two screen shots of the Masterbuilt order process, one showing an Add to Cart control, and one showing the cart; in both images the accessiBe widget is visible in the lower left corner.

the plugin seems to have actually made Defendant’s Digital Platform less accessible to Douglass. On accessing the Masterbuilt website, https://www.masterbuilt.com/, Defendant prompts screen reader users to turn on Screen Reader Mode. However, this mode actually restricts screen reader users’ access certain areas of the Digital Platform. For example, screen reader users cannot activate buttons and links on the Digital Platform’s product pages when the Screen Reader Mode is turned on. Although Defendant reads aloud all of the content on the product page, screen readers jump from the page to their browser’s “back” button, skipping over the actionable content in between. As a result, it is impossible for screen reader users, including Douglass, to add an item to their cart, find a retailer, or access Defendant’s frequently asked questions.

(b) Consumers who perceive content visually will notice a pop-up window after placing an item in their shopping cart at https://www.masterbuilt.com/. This pop-up window confirms the shopper placed the item in their shopping cart successfully and asks consumers whether they would like to checkout. Unfortunately, Defendant fails to notify screen readers when these pop-up windows appear. As a result, screen reader users, like Douglass, do not receive this confirmation and shortcut to the payment platform. Instead, screen reader users must tab back to the top of a webpage in order to complete a purchase. This

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.

Page 14 of Murphy v Eyebobs complaint Page 15 of Murphy v Eyebobs complaint
Excerpts from pages 14 and 15 of the Murphy v Eyebobs complaint.
Text from the screen shot of page 14…

(b) What’s more, the accessiBe overlay makes it impossible for some screen reader users to access the Digital Platform after they visit Defendant’s Accessibility Statement. As this video demonstrates, screen reader users may tab to Defendant’s Accessibility Statement shortly after entering the Digital Platform. However, their screen readers become stuck after closing the accessibility interface. Screen readers can neither tab “back” nor “forward” in order to navigate the Digital Platform in a predictable manner. Because screen reader users, including Murphy, are likely to become stuck so soon after arriving to Defendant’s online store, this accessibility barrier has a particularly deterring effect on their future use of the Digital Platform. As a result, Murphy is more likely to look elsewhere for the products that Defendant sells. Click the picture contained in this paragraph or following link to view a short video describing this access barrier: https://youtu.be/aHnaJKHgQjU.

Text from the screen shot of page 15…

(c) The Digital Platform prevents screen reader users from accessing some primary content. For example, when consumers visit the Digital Platform from a new IP address, Defendant displays a pop-up window inviting them to “[e]njoy 10% off your next purchase. Offer ends soon.” Consumers who perceive content visually can type their email into the text field that Defendant provides in the pop-up window, then click “enjoy 10% off” to claim the promotion. Unfortunately, Defendant does not alert screen readers of this pop-up window. Instead, screen readers remain focused on the content of the Digital Platform’s underlying page, making the pop-up invisible to screen reader users. As a result, it is impossible for Murphy to perceive this promotion independently, the effect of which would require him to pay more on his order thanconsumers who do not use screen reader technology to shop online. Click the picture contained in this paragraph or following link to view a short video describing this access barrier: https://youtu.be/UvtjU3FXUFU.

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.

Page 7 of Fischler v Dorai Homes complaint Page 8 of Fischler v Dorai Homes complaint
Pages 7 and 8 of the Fischler v Dorai Homes complaint.
Text from the screen shot of page 7…

21. Defendant has installed a low-cost plug-in developed by a company called AccessiBe. AccessiBe is one of the most well-publicized overlays available on themarket and the company has clearly spent a great deal on advertising. AccessiBe’s

Text from the screen shot of page 8…

Website claims it is “The #1 Automated Web Accessibility Solution for ADA & WCAG Compliance,” See www.accessibe.com (last visited May 10, 2021). AccessiBe’s overlay claims to make websites accessible to screen reader users and others with specific accessibility needs. However, Plaintiff Fischler found that Defendant’s Website remains inaccessible, despite this overlay, and in some instances, the overlay actually makes Website navigation more difficult. In fact, many visually impaired users have taken to social media point out the inefficacy of this overlay for increasing accessibility. See NBC News, Innovation, May 9, 2021 (last visited May 10, 2021) https://www.nbcnews.com/tech/innovation/blind-people-advocates-slam-company-claiming-make-websites-ada-compliant-n1266720.

22. AccessiBe recognizes the limitations of its product by providing a broad disclaimer of warranties stating, inter alia, that “[…] the company parties provide nowarranty or undertaking, and makes no representation of any kind that the services and the content will meet your requirements, needs or preferences, or achieve any intended results, be compatible, uninterrupted, timely, secure, operate without interruption, meet any performance or reliability standards or be error-free, or that any errors or defects can and will be corrected, or the results that may be obtained from use of services will be complete, accurate or reliable.” (https://accessibe.com/terms-of-service).

23. Plaintiff Fischler last visited the Website on or about April 28, 2021. Immediately upon entering the site, he was told he could use the Website in screen reader mode. However, when he tries to engage the overlay, he is blocked by a pop-up. After finding a way to close the pop-up window he again tried to engage the overlay, but did not receive any confirmation that he had successfully done so. When he navigated to the

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 v accessiBe, paragraphs 60–62

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.

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:

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.

The WAVE inspection panel with a warning in red at the top.
The WAVE checker displays the message The 3rd party accessiBe integration on this page may temporarily modify content when WAVE is activated resulting in interference with WAVE’s detection of and accuracy identifying accessibility and compliance issues.

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

Before running accessiBe, looking at the logo link’s accessible name in Chrome's inspector. After running accessiBe, looking at the logo link’s accessible name in Chrome's inspector. After running accessiBe and WAVE, looking at the code in Chrome's inspector.
Using Chrome’s dev tools to show how the link is exposed on page load (first image), after running the accessiBe overlay (second image), and again after running WAVE (third image).

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

Before running accessiBe, looking at the logo link’s accessible name in Chrome's inspector. After running accessiBe, looking at the logo link’s accessible name in Chrome's inspector. After running accessiBe and WAVE, looking at the code in Chrome's inspector.
Using Chrome’s dev tools to show how the link is exposed on page load (first image), after running the accessiBe overlay (second image), and again after running WAVE (third image).

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.

The Sources panel in Chrome showing a highlighted function runWaveProcess.
The Sources inspector in Chrome’s dev tools, looking at a function in the file acsb.js.

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.

Watch The Underlying Truth about Overlays at YouTube.

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.

Navigating to the Lawsuits page of the AccessUS web site. The page gets a gray overlay, and then audio starts to play with no visible video player or audio controls.

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.

Axe showing 4 violations before running the accessiBe overlay on the AI page. Axe showing 12 violations after running the accessiBe overlay on the AI page.
Running Deque’s Axe browser plug-in reveals more WCAG violations after enabling the accessiBe overlay, from 4 to 12.
ARC showing 19 violations before running the accessiBe overlay on the AI page. ARC showing 38 violations after running the accessiBe overlay on the AI page.
The Paciello Group’s ARC browser plug-in also shows a jump from 19 violations to 38 after running the accessiBe overlay.
WAVE showing 0 violations before running the accessiBe overlay on the AI page. WAVE showing 0 violations after running the accessiBe overlay on the AI page.
WebAIM’s WAVE checker browser plug-in returned no violations aside from a single contrast violation. These results are not surprising given it may be spoofing WAVE and I get the WAVE warning when I use the bookmarklet.

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.

The hero image on the page is a 10 second looping background video that autoplays when the page loads and has no controls to stop it. When activating the accessiBe overlay, the video still cannot be stopped more than once. Subsequent presses of the “Stop Animations” button from the :12 mark have no effect, but there is a visual indication that my button press has been processed.

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.

The video shows the browser default focus ring, then the alert prompting the user to enable the overlay at :09. When declined, from :12 forward you can only tell that focus is changing by looking at the browser status bar.

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

At :02 the focus skips past the hamburger, at :05 the user is prompted to activate the overlay, at :17 I put focus on the hamburger, from :19 to :31 I am repeatedly pressing Enter and Space to no avail, and at :35 I discover the <h1> has tabindex="0". If you were staring at the hamburger, you might have missed the overlay instructions from :09 to :19 at the bottom third of the screen.

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.

55 seconds of a screen reader experience.

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.

1:05 of a screen reader experience.

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.

4 views of the overlay, each one has white text on a light gray background and hover styles that are minor changes in size.
The overlay is long, so this image captures 4 screenfuls. The screen shot is from Chrome 87 on Windows, a common browser, though it behaves this way across browsers. The image is a link to a larger file where you can try to guess over which control I am hovering. Or you can visit the example site, Aquis.com, and try it for yourself.

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.

The “English” language button, with an American flag, with the browser inspector showing the image has the alternative text “English” and the button has the visible text “English”. The accessibility inspector confirms the button’s accessible name is “English English.”
The dev tools show the redundancy. It’s so obvious that a linter, or even fake AI, could flag and fix this.

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

2 seconds of testing would have found this redundancy.

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.

Sorta transcript:

0:00 bushnell.org/shows-concerts in Chrome incognito.

0:01 I highlight checkboxes under a button named “Filter”.

0:09 I activate the accessiBe overlay and choose “Keyboard navigation”.

0:10 I note the text is #FAA633 on white, or 2:1 contrast ratio.

0:11 I note same text now on gray has a 1.8:1 contrast ratio.

0:13 The checkboxes are now replaced by blank spots.

0:21 I disable the feature.

0:23 The page reloads, opens the overlay, and also loses all my previous checks.

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.

Watch The Great Accessibility Overlays Battle – Part 1 at YouTube.


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.

@neilpatel Wow. NeilPatel.com is fully compliant. What's your secret, Neil? (I ran your site because I figured if any site was fully compliant, it would be yours.)

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.

Lighthouse showing a score of 88, identifying poor contrast, missing field labels, and links with no accessible name. The link with no accessible name. The link with wordy SEO-optimized link and also a new target attribute.
The first image shows the Lighthouse score of 88 on the Neil Patel home page, the second image shows a fundamental error any checker should catch, the third image shows the page with a perfect aCe score and modified HTML. I captured these in separate windows to avoid it tracking and trying to defeat my tests.

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 aCe tool giving NeilPatel.com a non-compliant rating, with one score of 54 visible. The inspector showing the logo link still has no accessible name, but does have a target attribute.
The first image shows the failing review, and the second shows how the HTML is mostly the same as before aCe was run.

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.

Edge dev tools showing the heading structure as described. The accessScan page with a modal dialog showing the message: “Website Connection Error!
We couldn't evaluate the website you entered. This may happen if your server blocks our request or the page is trying to redirect. Please ensure your website can be accessed by web crawlers!” There is also another modal dialog showing the scanning process, and another box showing a bi-directional scrolling chat box.
The reading order feature of Edge’s dev tools shows text following the heading precedes it in the DOM (which is generally fine), but the placeholder text is a a problem. That those existed in aCe and were not fixed is surprising. That it will not check itself is unsurprising.

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.

Firefox dev tools showing the link and raw HTML along with a script error that the widget was not initialized.
The browser is showing it cannot load the script, and the trigger to load the accessiBe overlay is a <div> with a tabindex and a button role.

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.

I left the alternative text as Twitter’s default, Image. The visible text reads Web accessibility is and then uses Braille to represent the word accessibe, without their brand capitalization because no upper case indicator was included in the Braille.

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 box with a dollar sign icon displaying above the page, with the following content: This article may have been created or edited in return for undisclosed payments, a violation of Wikipedia's terms of use. It may require cleanup to comply with Wikipedia's content policies. (October 2020)
Visit this version of the accessiBe article with the spam warning. The current version no longer has this warning and has a lengthy Controversy section.

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.

Watch Stitch in Time License to Fail at YouTube.

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:

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.

Michael Hingson, accessiBe CVO, at 1:14:54

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…

Michael Hingson, accessiBe CVO, at 1:54:26

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.

Michael Hingson, accessiBe CVO, at 2:00:46

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.

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.

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.

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.

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

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.

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)

The Six Flags home page in a mobile browser alongside the same page with the accessiBe overlay expanded and showing its options.
The Six Flags home page shows the accessiBe overlay before and after expansion

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.

Update: accessiBe Response (4 August 2020)

Update: accessiBe Response (4 August 2020)

Today I received an email from accessiBe. The email included a link to a two-hour-fourteen-minute YouTube video refuting my claims (embedded below). As of today this video has neither captions nor a transcript.

This is an unlisted video, so accessiBe may have felt making it accessible would be unnecessary — a common mistake from organizations looking at accessibility as risk to be managed (for a fee) instead of from a user-first perspective.

I have requested captions. Once those are in place I plan to review the video.

Update: Response to accessiBe Response (17 August 2020)

Update: Response to accessiBe Response (17 August 2020)

Today (17 August) I discovered that accessiBe finally provided captions for its response video, though they did not email to tell me as promised. The captions were not there last week. This meant I was finally able to sit down with it, review it, and write a response to the response.

This is going to be a long read, and I apologize. I am working through a two-hour fifteen-minute video. I include links to timestamps in the video in case there is anything you want to jump to in particular.

I have marked everywhere I was wrong in this style so you can find it quickly. I did not mark everywhere he was wrong.


The accessiBe CEO opens by stating that I am on a Twitter frenzy, showing a pile of screen shots of my tweets as evidence. Frankly, I consider it more of a hobby.


Here he asserts I never reached out directly. Which is true.


Here he says he wants feedback, but in the right channels. The implication being that I will give away my expertise for free. It turns out I am not the only person accessiBe has approached asking for free work.


He addresses the section accessiBe Is Cited in an Accessibility Lawsuit, claiming it pre-dates accessiBe’s involvement.

The screen shot and PDF I provide in that section are from the case, which clearly shows the accessiBe overlay and references the ineffectiveness of the tool. No matter when accessiBe got involved, accessiBe was involved enough to warrant being cited in the case file.

In an attempt to obfuscate, he asserts Usablenet made a correction to a post related to this case. This is obfuscation because my information came from the case file, not Usablenet.


Addressing my section on the Two Kinds of Lawsuits, he claims that accessiBe provides a litigation support package, then reads an email from a client thanking them for a case being dropped (good for that client!).

He also claims they have gotten all cases dismissed, but does not state if the overlay alone enabled that or if manual remediation effort was needed. He then asserts lawyers avoid sending lawsuits to accessiBe’s clients, but provides nothing to back that up (proving a negative is kind of hard).


Here he intends to address screen reader support by looking at the screen shots from the accessiBe Spoofs Automated Checkers section, which is the wrong section (the JAWS videos are in the Via Actual Use section). It is where I show the accessible name in the dev tools to demonstrate the redundancy.

He asserts how I tested (which is wrong, just watch my videos), including saying I played with the size of the dev tools (I did not), while hinting there is a bug in the accessiBe overlay where resize actions can mess with the code.

He does not address the problems I identified in the embedded screen reader videos. My screen reader testing was on the accessiBe site but he spends 10 minutes with a screen reader on a different site.


Here he is starting to address my assertion that accessiBe Is Inaccessible.


Here he shows the overlay and it is apparent the overlay is different than the one I tested for this post.

It is important to keep this in mind, because he is running a new release on the accessiBe site. He continues with a general walk-through here, not addressing my three specific examples.

The next 20 minutes are mostly a product demo / pitch of this new release.


Here he starts showing accessiBe’s demo site. I appreciate that accessiBe works as he wants on their own demo site.

I found 3 examples after roughly 10 minutes of poking the accessiBe corporate site with accessiBe’s overlay, not this optimized demo.


He acknowledges what he is showing is a newer version of the overlay than what I tested. This is not an effort to refute anything I identified, it is just a product pitch. He is showing features, but not how it works or conflicts with users’ existing tools.


He wraps 40 minutes of demos to address my WAVE, Axe, and ARC findings (without using them) from the section Via Automated Testing.


Here he says So, he basically claims that with these testing tools, the number of accessibility errors jump rather than reduce when using accessiBe.

He follows that with we are very much aware of that. Twice.

His claim is that this is intentional. His argument is that adding role="presentation" to an image with a blank alt attribute is to prevent lawyers from claiming a blank alt as a WCAG violation. Which it isn’t.

Notably, the screen shots I offer from Axe do not mention alternative text. Axe flags 3 instances of bad contrast and 9 instances of improper nesting. No mention of alternative text.

He ignores the 12 visible errors in Axe and does not address the errors identified in ARC and WAVE.


He is starting to address the section Via Manual Testing.


He says, What Adrian found here is a bug. And a minor one at that.

I agree that bugs are unfortunate and they happen to the best of teams. It is still a 2.2.2 violation.

He also asserts it needs to be triggered three times in a row to reproduce, but clearly it is only twice.

When someone comes to a page who does not want motion, they may quickly move to stop that motion (as I do in the video), then after taking a moment may want to see if it has important information, restart the video (as I do), and then decide to stop it again to limit exposure (as I try to do). This is not me playing around. This is not an edge case.

They could have learned this from testing with users (as I have).


He asserts the feature worked perfectly. The feature that he acknowledged was a bug almost 45 seconds ago.

I get that all software has bugs, but to assert this is a minor bug when it will fail WCAG and can make users sick is dismissive. If I discovered it so easily, you can be sure users would as well. This also speaks to the QA on the software.


He references a Chrome bug (he does not offer a bug ID), that removes focus styles after an alert fires.

At 1:17:33 he says he just doesn’t do what users with disabilities do when I ignore the prompts to enable the overlay. He is forgetting power users who are mostly keyboard-first, as well as general keyboard-only users who may not be interested in learning a new interface, all while forgetting the people who need the visible focus but do not identify as disabled.

He demonstrates the bug he mentioned using the Google search results page and shows the focus disappear — except at 1:19:30, where the focus styles kick in for the top stories.

I can point to a demo that relies on focus styles working after the alert. Navigate the second table in my block rows demo to see the focus styles are retained after the alert is dismissed.

Clearly accessiBe knows about this potential browser bug, knows what triggers it, but makes no effort to account for it when the user declines to enable the full overlay. This is knowingly allowing a degraded experience.

He acknowledges this at 1:19:55 with you can claim, and you will be fully correct, that […] we as the providers […] should find workarounds […] If you claim that, then I will be, I will completely agree with you. He goes on to say they found out about the bug and released a fix a week and a half later, though given my example above I am wary if it was every coded correctly.


Here he addresses the issue with the hamburger by both pretending that users do not zoom, and claiming that this zoomed view is strictly for mobile users. Both are clearly, overwhelmingly, wrong. There are even WCAG Techniques tied to this (under 1.4.4 and 1.4.10).

He also asserts I repeatedly shrunk and expanded the window, which tells me I should have started the video at the blank screen (as I did the others) so he could not wrongly assert I was messing with the window size. It was my mistake to not provide an unassailable video since it provided traction for him to make that claim.


He says it works perfectly fine when you just don’t abuse the browser. This statement is building on his prior incorrect assertions about how I am testing, but also attempts to blame me for failures in their software.


He runs the page in the mobile emulator within the browser, which is very much an apples to oranges comparison. He also uses a different version of the overlay.

It also means users who zoom the page are not only stuck, but accessiBe considers them browser abusers, or at least not real users.

This tells us that accessiBe, or its web site developers, do not understand that a narrow viewport does not automatically mean a mobile or touch context.


This relates to the Via Actual Use section where I generally assert the poor screen reader user experience.

He refutes this by mentioning his earlier demo showing the newer version of the overlay: You have seen it in the walk-through. The experience is perfectly fine. It’s intuitive and it just works right away.. He backs that up by anecdotally claiming support from actual blind users.

I can provide anecdotal feedback from screen reader users that say the opposite, such as Brian or Haben. That took a moment of Twitter searching, so you can probably do the same.


He addresses my sighted screen reader use case. He talks primarily about visible focus, but seemingly misses the point I raised about how verbose the announcements are.

This is a common mistake when sighted developers are providing experiences for screen reader users. Particularly when they do not include screen reader users in testing.


I had written about how verbose the content is and noted that a sighted screen reader user may struggle to identify where it is on the screen.

He argues his point using a hidden skip link: So he complains that a sighted screen reader user won’t be able to see the button here. And that’s confusing because he hears, they hear something, but they don’t see that.

This demonstrates he completely misunderstood the real issue.


Now he is addressing my section accessiBe Does Not Understand WCAG. Only 45 minutes to go.

He spends the first two minutes talking about Karl Groves’ video.


Here he takes issue with my comparitive parenthetical reference to The WebAIM Million work. It was my mistake to add that throwaway comment, but the comparison seemed apt.


Here he talks about the ARIA navigation menus they promoted in their research. He goes on to say First off, I do acknowledge that three of the seven points that we’ve made shouldn’t have been included as, or tied into the WCAG specifically as a dry requirement for 2.0 or 2.1 at the double A level.

He contends they included these to balance WCAG technical requirements with ADA-focused experience. His argument is that lawsuits cite a lack of arrow key support, therefore accessiBe can declare it a requirement.

He adds at 1:37:39, …incorporated into WCAG or not is a dry requirement, … it still appears in thousands of lawsuits and therefore it also appears in our research and in our blog post. He follows it with, I also agree that we should have explained this much better. …I’ve already instructed our team to edit the blog post…

The overall logic is that things appear in lawsuits, so things are a WCAG requirement.


He is at the accessiBe Spoofs Automated Checkers section.

He asserts I make my claim based on the WAVE message, a string of random text in the page, and the runWaveProcess function name. He goes on to explain the accessiBe overlay adjusts the site as the user is using it: …if you don’t use a screen reader or the keyboard, you won’t get any accessibility adjustments.

Because WAVE is not a user it gets no adjustments from accessiBe (I enabled accessiBe to test). At 1:41:45 he says once they detect WAVE, they add the adjustments. He claims he spoke to the WAVE team, but I cannot verify that either way.

At 1:47:15 he explains that because WAVE is not parsing as a user, accessiBe is unable to identify the site and falls down. That makes me wonder why it needs to know the web site to replace text, especially since accessiBe claims this is all AI with no human intervention.


He has moved on to the accessiBe Misrepresents ADA section. He cites their ADA disambiguation post, which I also did to demonstrate they understand the concept, they just misrepresent it with their “ADA TITLE III COMPLIANCE” badge (which he does not discuss). He also claims my term “SEO-driven” is childish, but you can decide by reading the page.

Then he touches on Timothy Springer’s article, Lies, Damned Lies, Overlays and Widgets arguing the accessiBe overlay is just like a ramp. I argue the overlay is only like a ramp if when you try to climb the stairs someone runs up to you carrying a very steep wedge and jams it under you.

He returns to his argument that they have saved thousands of businesses from lawsuits and therefore accessiBe covers the ADA and leaves it at that.


He is back in the accessiBe Does Not Understand WCAG section. He takes issue with my UserWay reference, arguing that their own post taking a swing at UserWay is because UserWay customers come to accessiBe. I actually don’t care. I was citing the broken table and the checklist content.

He claims I did not use a screen reader (again) when I tested, which is both untrue and irrelevant. The table has no column headers until you enable the accessiBe overlay. Which means the tables are broken from the start. The correct assertion is accessiBe coded broken tables and relies on the overlay to do the job of its developers. If someone disallows the overlay, or it breaks, or is blocked, then that user does not get that fix.


He does not understand my point about marking up deleted and emphasized text, which is fine. And alarming. Even though accessiBe says tagged appropriately and does not explicitly mention the elements, the elements are implied. He talks around it for a bit and moves on. At nearly 2 hours I was grateful.


My issue here is that the accessiBe checklist oversimplifies ways to provide an accessible name. This can lead business owners astray by asking for insufficient information from their developers, potentially causing panic on the team or in management. He misses that point.


We are at the accessiBe Pays for Praise section. His opening salvo is this is a really unprofessional thing to bring up.

I know NextWeb is their client. Nobody refutes NextWeb is their client. He goes on to say You do understand that companies do marketing, right? Companies do PR. He is not denying the NextWeb piece is a marketing post.

He takes issue with my reference to tweets by marketers, asserting they have never paid for tweets. He goes on to say they partner up with marketing agencies. When their partner marketers tweet, even if there is no invoice for the individual tweet, it is a function of their transactional relationship. This is simply an admission of their marketing strategy.

I leave it to the reader to judge, but if accessiBe feels this is a really unprofessional thing to bring up, then it sounds like they would be happier with nobody knowing.


He has made it to the accessiBe Deletes Critical Comments section. Finally, after all of those claims, after everything here, Adrian is correct on something.


Here he contends that accessiBe’s web host deleted two comments because the host believed they were hate comments. He claims he does not know the content of the comments, even though I provided a Wayback link he could have reviewed. He did not address if they could or would restore them.

He goes on to remind me that he offered to have a conversation on LinkedIn. Not only do I avoid LinkedIn, it also moves the conversation out of the public eye.

There may be a reason this YouTube video has comments disabled.


From here to the end is a pitch.

He argues that manual accessibility is too costly, too complex for engineers, and is not a sexy topic. He asserts that for accessibility to exist and still be robust, it has to be powered by AI and automation. He continues to argue for letting organizations languish in broken processes, with untrained developers (my words).

His entire pitch is about clients and lawsuits. It is not about users. I think that tells you everything you need to know.

Note, 18 August 2020: I made a series of changes in my response to fix typos, clarify sentences, include more of his quotes, and fix some formatting wonkiness. I changed nothing of the substance of my feedback.

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.

Cartoon. A man at a computer happily exclaims, "Finally, my website is up!" Two men in suits appear next to him holding legal papers and say, "Not so fast! Nice website, but it's not accessible! You've been served." Shows the man again, crying, hands up in the air, saying, "I'm broke now. Why bother?" In the background the two men can be seen walking away carrying bags of money. 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:

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:

Where do accessible websites stand with the ADA Tax Credit? The ADA was initially drawn up with the intention of applying its rules and regulations to the evolving internet landscape. Currently, the ADA covers websites and does in fact mandate accessibility in the digital arena; this means that the tax credit very much applies to businesses who invest in owning and operating accessible sites.

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:

The language from accessiBe with the first and last bullet highlighted. The language from the IRS with the first and last bullet highlighted.
I highlighted the parts that are substantively different, namely the entirety of the first bullet and the clause of the last bullet.

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.



Accessibe is shit



David Berman; . Permalink

Accessibe makes me so angry, they’re a bunch of scammers.

Matt Putland; . Permalink

AccessiBe is a scam.

Daniel; . Permalink

This was so insightful, Adrian. Thank you! I’ve followed your info on accessibility for years.

I recently did a podcast episode about overlays and mentioned Karl’s video, along with some other resources.

I will add a link to your article there as well.

Colleen Gratzer; . Permalink

Not to add to a pile-on or anything, (Oh f*ck it, I’m adding), but speaking just as a plain-old screen reader user with the accessibility practitioner toggle switched to off as much as possible, AccessiB really does make me want to throw valuable breakable things at hard surfaces. And drink. And I think they really should quit digging by asking PWD to do free labor for them. Although if I had to think of something positive to say, I think the entire Gutenberg team should give itself a round of aplause for not just going the AccessiB route, because as many problems as there are, and as many issues as I have with it, even the most hard-core Gutenberg team members have never gone so far as to suggest “Hey let’s just include AccessiB!”


As a native screen reader user and a QA tester. I agree with Amanda and everyone else that accessibility overlays like accessiBe are just atrocious. Every time I have to deal with one, it makes me want to throw things because the experience is just so damn awful!

Ka Li; . Permalink

I’d say that using such an headline like: accessibe will get you sued, while at the bottom writing: “The title is hyperbolic. You will not get sued as soon as you put accessiBe’s overlay on your site” is a nasty thing to do.
I’d even say you hurt the noble effort of making the internet indeed accessible for people with disabilities in an affordable rate for SMBs.

Daniel Louis; . Permalink
In response to Daniel Louis. Reply

Daniel, I think pitching a one-stop solution to all your accessibility needs while knowingly excluding actually disabled users is a nasty thing to do, so I guess we have a different attenuation for what constitutes “nasty”. Incidentally, my entire post details how the accessiBe approach is not an affordable rate for SMBs given that it does not deliver the thing it is paid to deliver.

In response to Adrian Roselli. Reply

As a website owner using accessibe I got tens of feedbacks from people with disablities saying they are super satisfied with that solution. Nevertheless I didn’t get any negative feedback from any person with disability who used or tried to use accessibe on my site.
That’s the only reason I feel I’m a kind of an “ambassador” here…
The only thing I know is that I couldn’t pay the rate of a comprehensive manual work on my site in order to make it accessible, and that people with disabilities are satisfied with that automated solution.

Daniel Louis; . Permalink
In response to Daniel Louis. Reply

Daniel, I noticed that you did not provide the address of your site, which is fine but telling.

I am glad you have received positive feedback, but frankly I am wary. Everyone I have spoken to who has a disability and has used the accessiBe overlay has had a problem with it. If you search on Twitter you will see many have raised issues and continue to do so.

You may not have heard negative feedback about your site because users who struggle will simply leave your site instead of wasting their time (see Click-Away Pound). This is even more true if the methods to offer feedback are just as inaccessible. Making the assumption that no complaints means all is well, in the face of overwhelming technical flaws and vocal detractors, is called confirmation bias, particularly when there is already a sunk cost.

I encourage you to read Honor the ADA: Avoid Web Accessibility Quick-Fix Overlays to see feedback from disabled users.

In response to Adrian Roselli. Reply

I believe that the bottom line is that a business like mine cannot afford itself paying for a full manual accessibility service. Yet it could naturally pay for an automated one.
So the way I see it – even if I’ve helped just few people using my site which couldn’t do it before – that itself is a move to the right direction.
Maybe some day an automated tool will be able to provide a full accessibility mode to the website, or a manual one would be affordable to SMBs…
I appreciate your roll and your actions towards a better internet experience for all – but you are doing it under a very narrow perspective I believe. Something like offering a full 1 month lockdown to fight Covid19… Almost 100% success in fighting Covid19, but in the meantime killing all small businesses on the way… Sorry for the comparison, but it’s the closest I could think of… lol

Daniel Louis; . Permalink

My own experience as an accessibility developer and feedback from my disabled testers/friends also suggests that these overlays are ineffective and misleading. Thank you for all the time you spent researching, testing, reading and responding. I’m glad to see this article ranking #2 on Google organic search ;-)

Matt Wilson; . Permalink

Looks like AccessiBe have been caught astroturfing:



Adrian this was incredible. Thank you for the effort you put in to not only fighting the fight, but collecting and organizing everything for others to find.

So: Legally it’s a total bust, and may do even more harm than good. $50/mo to avoid lawsuits always sounded too good to be true, and I never really expected that.

What about from a UX perspective? Giving the user control over how the site works and looks is hugely beneficial. Especially with AccessiBe’s new “Profiles”. Someone with epilepsy can reduce color contrast and turn off animations easily. Giving a “focus” bar for people with ADHD or Autism Spectrum Disorder. Are these truly based in user research and helpful for them? I recognize my own experience with how my mind and body work, which does not include any of those attributes. I have a lack of personal experience in-person user testing with many groups, so I’m relying on what I’ve read and researched elsewhere. Microsoft recently discovered and shared their finding: “Nothing about us, without us.” I’m working my best to implement that through research others have done and taking some steps others have learned are helpful while we work on connecting with people of all abilities within our own user base.

With all the other stuff and shady practices by them, I’m in no way advocating for AccessiBe. I was looking into them for my job as a possible thing that would be far easier to implement than continuing to hear “Not yet” from the development team who understandably has a million things on their to-do list (no judgment – just reality).

I am passionate about inclusive design and accessibility and realize there’s no magic bullet – I am working towards baking it in to our process as much as a I can – but is there ANY benefit to AccessiBe (or any of its ilk) if we go into it with the mindset of enhancing the UX rather than full WCAG/ADA compliance?

Honestly curious. Just trying to do my best and help serve our users as best I can.

Thanks much,

Jason Ober; . Permalink
In response to Jason Ober. Reply

What about from a UX perspective? Giving the user control over how the site works and looks is hugely beneficial.

Only if those controls work. Which they make no guarantee they do, and which are not necessarily grounded in real research.

Microsoft recently discovered and shared their finding: “Nothing about us, without us.”

Microsoft did not discover that. The phrase dates back to the 1990s when, in addition to other prior uses, it became a disability community rallying cry.

…but is there ANY benefit to AccessiBe (or any of its ilk) if we go into it with the mindset of enhancing the UX rather than full WCAG/ADA compliance?

Given the inconsistent output, extra load for end-users’ browsers, lack of broad research supporting the changes it makes, and the fact that just embedding the control increases your risk of WCAG violations (by adding more), I would say no.

Instead, do some research with your current users and find out what, if any, of those features might benefit them, and either build them into your site or adjust your design to incorporate them.


what do you recommend to use if you dont recommend this website?

Lori Schuman; . Permalink
In response to Lori Schuman. Reply

None of the overlays on the market work as advertised, as I address in my 2015 post Be Wary of Add-on Accessibility (and which I still update).

The thing is, they can’t. Every industry professional knows that automated testing tools can only identify about 30% of accessibility issues. This is a function of how WCAG is written to consider content beyond just mark-up. That means even the best overlay starts at the 30% mark and then has to somehow understand author intent.

Instead, you have to start from good and accessible defaults and build from there. If your thing is already built, then you need to identify your issues and make a plan to address them. I cover some of this in my post Sub-$1,000 Web Accessibility Solution.


Added both URLs to my Adblocker in my openwrt router. thanks. BTW OpenWrt has grate a11y on ther e web interface.

Tapper; . Permalink

If I’d read this in advance then maybe I wouldn’t have been so surprised to receive a tweet from #Accessibe and four different tweets from their “Chief Vision Officer” (and on the weekend at that!) in response to my tweet:

“Have we stopped for a second to consider business owners’ needs?”
Wow, next level whining in this 3700 word blog from #Accessibe, a web accessibility tool that’s come in for criticism from actual disabled users accessibe.com/blog/trends/industry-…
Would Sir like some meal with their whine?

I’m more a physical accessibility guy, but a friend pointed me at the blog, which seems to suggest they might be pivoting to an argument that fully meeting accessibility standards is unaffordable, and disabled people should instead “think of the businesses!” and lower our accessibility expectations to meet what they’re willing to pay for.

A few highlights:

“in the last several months we’ve been going through a non-proportional amount of harassment that is not only unethical but in some cases borderline illegal and involves sabotaging our customers’ businesses and trying to harm our digital assets.”

“Have we stopped for a second to consider business owners’ needs? Their wants? Their day-to-day operations? Their vendors? Their projects? Their expenses? Their priorities? Their challenges? If we want to achieve an accessible Internet we must consider what business owners are willing to do, what’s realistic for them, and what they actually need. ”

“it is unrealistic to expect businesses to meticulously design and plan out their websites”

“We can’t let the edge cases define an entire industry”

So if they can’t persuade disabled people their product is good enough, instead argue our expectations are unreasonable.

In which respect:

“We are in the process of joining the W3C”

suggests that monitoring what changes they might try to drive into W3C accessibility policy might become important.


What a read! I appreciate the detailed work Adrian, thank you very much.

I enjoyed reading the responses to Chancey & learning of, I assume, so many expert disabled commentators.

Comment – typo here, start for star “five-start reviews for the accessiBe plug-in that he identified as fake.”

Regards, Chris.

Chris Leighton; . Permalink
In response to Chris Leighton. Reply

Fixed, thanks!


WordPress.org Removes Fake Reviews for AccessiBe Plugin

In response to david. Reply

Thanks, David! I link to that piece in the post above but I also know I provide a lot of links (I like to back up my assertions with references), so I appreciate that you shared it.


Have you seen the latest all out attack from User way against accessiBe? https://userway.org/userway-vs-accessibe/

Mitchel P; . Permalink
In response to Mitchel P. Reply

Well, that is fairly dishonest of UserWay. The implication is that those critical of accessiBe are therefore supporting UserWay, and since half the tweets cited are also signed on to the Overlay Fact Sheet it suggests UserWay is less interested in getting its facts right.

I captured the UserWay page at the WayBack as it stands today so we can reference it without giving it link juice (a highly technical term, I know).

And for the record, UserWay is also a problematic product and it also makes claims about what it can do that do not stand up to scrutiny. This criticism of accessiBe in no way suggests the other overlay products are good. In fact, my 2015 post Be Wary of Add-on Accessibility names UserWay as one of the problematic options out there.

In response to Adrian Roselli. Reply

UserWay has removed the link and reference at my insistence, though it kept my post title and the tweets of others.

In response to Adrian Roselli. Reply

They removed the page completely now

Kirk; . Permalink
In response to Kirk. Reply

Welp, absent a statement from UserWay, I guess we can draw whatever conclusion we want from that. Maybe even that they knew their claim was crap and the people they quoted were not on board with it.


What does everyone think about AudioEye?

Kevin Mackie; . Permalink
In response to Kevin Mackie. Reply

Over at OverlayFalseClaims.com, AudioEye has its own dedicated section.


This Article was mentioned on arush.io



I am glad I googled them. My ex is going to change much of architecture for the better with ADA because of her own disabilities. So I’m rather cognizant of these issues

Justin; . Permalink

very informative information…

DMR Engineering; . Permalink

Thanks for compiling this. I’ve been checking in periodically since you first wrote it. I was able to use it in a call today where a vendor was trying to leverage my company’s network of customers to hock their overlay.


What are your thoughts on the highly advertised tax return Accessibe is pumping?

Thomas Gadbois; . Permalink
In response to Thomas Gadbois. Reply

Never heard of it. Though I have been out of the country for the last couple weeks, don’t use Google search, block accessiBe in my browser, and don’t use Twitter anymore (except to post my grump). Can you share some detail? Perhaps a Wayback link?


Yeah it’s something they’re really using as a grabby reason to justify their costs.

Here’s the article on their site:


Also notice the ad funding message on their header. Such a shame.

Thomas Gadbois; . Permalink

For the record, this might well help some people get some money back, which is great. But to me this seems much more like an advertising opportunity for accessibe to profit off of this ongoing loophole

Thomas Gadbois; . Permalink
In response to Thomas Gadbois. Reply

A very small business still has to fill out IRS paperwork, so there is no guarantee. But sure, it could save that business $120 per year, or maybe a third of what it will minimally pay its CPA to review it.

However, this statement in the accessiBe post is, er, problematic:

The ADA was initially drawn up with the intention of applying its rules and regulations to the evolving internet landscape. Currently, the ADA covers websites and does in fact mandate accessibility in the digital arena; this means that the tax credit very much applies to businesses who invest in owning and operating accessible sites.

I address how egregiously wrong (and troubling) this statement is in my post ADA Web Site Compliance Still Not a Thing.

The linked untagged IRS fact sheet is from 1998 and says this:

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 accessiBe page misrepresents it as (emphasis theirs):

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 misrepresentation on that page is so problematic that I made a Wayback version of it in case it is handy for future false claims litigation.

Sadly, most small business won’t know what a scam accessiBe is (my opinion, dear lawyers), though any developer who looks at the source code for the image on that page will understand how little accessiBe understands:

<p style="text-align: center;">
 <img src="/media/blog/tax-benefits-meets-web-accessibility/taxform.png" aria-hidden="true" role="presentation">

Ok, I get it without having to spend the next 3 months reading and researching your comments. Is there anywhere in your dissertation that you recommend a solution?

In response to Bob E. Reply

Bob, check my response to an earlier comment.

Leave a Comment or Response

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>