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

Page 11 of THOMAS KLAUS and ROBERT JAHODA v. UPRIGHT TECHNOLOGIES, INC.
From page 11 of the THOMAS KLAUS and ROBERT JAHODA v. UPRIGHT TECHNOLOGIES, INC. complaint.
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.

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

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

Holly Scott-Gardner read a post from accessiBe asking for users to keep an open mind and try its service for themselves. So she did. She wrote about her 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 her 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.

Wrap-up

The title is hyperbolic. You will not get sued as soon as you put accessiBe’s overlay on your site. However, you will be using a product that generates more errors than not using it.

The accessiBe overlay also produces a worse experience. Users who care little about WCAG but understand their rights to equal access can file a complaint and put you on the hook for fixing the core issues. Another third-party hack will not help.

Using accessiBe’s overlay widget is a pre-preemptive admission that you know your work is inaccessible and that you took the shortest possible route to find the easiest possible workaround. You are telling users you care more about litigation risk than them.

The title is also a riff on accessiBe’s recent post Using an accessibility plugin like UserWay? You are at risk of litigation. In that post accessiBe is using fear, and fear is a poor motivator.

Adally, AudioEye, EqualWeb, Mk-Sense, User1st, and UserWay are not viable alternatives. They also promote their tools as risk mitigation over sustainable accessibility efforts that would otherwise promote better overall experiences.

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

I have a 2015 blog post, Be Wary of Add-on Accessibility, which I continue to update with news on accessibility add-ons and overlays. In February 2020 I noted a curious regional connection between accessiBe and others, but have not taken the time to dig in further. If there is something there, some kind of cahoots, please share.

Update: Why to Avoid aCe (14 July 2020)

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

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

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

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

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.

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.

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.


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.

2:49

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.

3:12

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

4:07

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.

6:32

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.

10:19

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

14:05

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.

26:10

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

27:21

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.

49:27

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.

1:01:34

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.

1:10:11

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

1:11:14

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.

1:13:30

He is starting to address the section Via Manual Testing.

1:15:27

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

1:16:06

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.

1:16:38

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.

1:22:08

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.

1:23:35

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.

1:23:50

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.

1:24:38

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.

1:26:00

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.

1:29:10

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.

1:30:50

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.

1:33:22

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.

1:34:48

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.

1:39:05

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.

1:50:02

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.

1:54:12

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.

1:56:25

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.

1:58:07

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.

2:00:17

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.

2:04:19

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.

Finally!

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.

2:07:12

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.

24 Comments

Reply

Accessibe is shit

Reply

+1

David Berman; . Permalink
Reply

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

Matt Putland; . Permalink
Reply

AccessiBe is a scam.

Daniel; . Permalink
Reply

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
Reply

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

Reply

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
Reply

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
Reply

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
Reply

Looks like AccessiBe have been caught astroturfing:

https://news.ycombinator.com/item?id=24783048

Reply

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

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.

Reply

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.

Reply

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

Tapper; . Permalink
Reply

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.

Reply

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!

Reply

WordPress.org Removes Fake Reviews for AccessiBe Plugin
https://wptavern.com/wordpress-org-removes-fake-reviews-for-acessibe-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.

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>