#accessiBe Will Get You Sued

The hashtag is in the title because accessiBe does not maintain a presence on Twitter (it does now!). Instead the accessiBe site links to the hashtag, which is currently mostly positive and much of which may be paid. I am hoping a search for that hashtag will surface this warning.

What We Know About accessiBe

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

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

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.

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 the a confounding experience. Both of these scenarios, exacerbated by accessiBe’s product, increase the risk of a suit.

accessiBe Is Inaccessible

Steve Faulkner did a technical walk-through of the accessiBe overlay, among others, and documented clear failures under WCAG.

Whether you review it with automated tools or manual testing to check for WCAG failures, or you look at it from the perspective of de facto accessibility, both accessiBe and its overlay do not pass muster.

I am not wading through accessiBe’s client sites. I am looking at accessiBe’s site though its own tool to get the best insight into how it understands accessibility. I am also not doing an in-depth review, partly because others have done so (which helps establish an ongoing pattern) and partly because I am not giving them my help for free.

Via Automated Testing

I grabbed a few examples of how one page on its site performs worse with automated checkers after the accessiBe overlay is enabled.

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.


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

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

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



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.

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:


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>