Accessibility Isn’t a Switch: Updates on accessiBe, AudioEye and Metro’s Public Safety Dashboard

Back in January 2025, I wrote about accessiBe and the claim that an automated accessibility product could make websites accessible. I was not impressed then, and after reviewing what has happened since, I have a few more things to say.

I also have a real-world example from Los Angeles Metro. On October 9, 2026, I prepared an accessibility evaluation of Metro’s Department of Public Safety dashboard after a technology demonstration. That experience reminded me why a page that appears to work and a page that actually communicates its information to a blind person are not necessarily the same thing.

What I said about accessiBe in 2025

I remember visiting websites that told me to press Control+1 to activate a screen-reader mode. I tried it on occasion and wondered what the hell it had accomplished. In my experience, some of those websites seemed usable already, and the special mode didn’t make an obvious difference. I didn’t use these overlays regularly, and I am not claiming that I encountered all the problems other blind users reported.

Other users and accessibility advocates did report significant problems, including overlays that interfered with screen readers or failed to fix inaccessible content. My question then is the same one I have now: why would a website owner think adding a widget is a substitute for building an accessible website?

In my January 20, 2025 article about accessiBe, I discussed the FTC’s proposed settlement and linked to the broader controversy. I followed up in my January 25 article after Adrian Roselli weighed in. At the time, the order was still proposed. I questioned whether a $1 million payment would be a meaningful deterrent, particularly in light of a revenue figure I cited then. I have not independently established accessiBe’s current financial position, so I won’t pretend to know what that amount means to its finances today.

The FTC case didn’t stop at a proposal

Here is the update. On April 22, 2025, the Federal Trade Commission approved a final order requiring accessiBe to pay $1 million. The FTC said accessiBe made misleading claims about whether its automated accessWidget could make websites compliant with the Web Content Accessibility Guidelines. The order also addressed representations about supposedly independent endorsements and reviews.

The order restricts accessiBe from claiming that its automated product makes any website WCAG-compliant, or keeps it compliant, without adequate supporting evidence. That is a regulatory action about advertising and substantiation. It does not mean that every feature of every accessibility widget is useless, and it does not mean the FTC performed a complete accessibility audit of every site using one.

I still find the $1 million amount striking. I cannot put a dollar value on every barrier or difficulty disabled people reported, and this FTC payment should not be confused with compensation to every affected user. I also do not know enough about the company’s current finances to say how painful the payment was. But I can say that I would have liked to see a stronger deterrent against exaggerated accessibility promises.

There is a larger lesson here, regardless of my disagreement with the amount. The Federal Trade Commission can investigate vendors that make deceptive advertising claims, including vendors selling products in the accessibility market. I hope accessiBe and other companies take that seriously. If you tell website owners that your product solves accessibility problems, you should be able to substantiate that claim. A clever marketing pitch does not replace testing with people who actually use assistive technology.

Read the FTC announcement of the final order and the FTC case record.

I also want to make something clear for businesses: accessibility law does not require you to buy accessiBe, AudioEye, or any particular overlay. And buying one does not automatically protect you from an accessibility complaint. The question is whether people with disabilities can actually use your services.

Adrian Roselli and AudioEye: A separate case

I also wrote about accessibility advocate Adrian Roselli, and I want to keep the companies straight. It was AudioEye, not accessiBe, that sued Adrian over his criticism.

AudioEye dropped its lawsuit against Adrian as part of a settlement announced in January 2024. The dismissal was with prejudice, meaning that lawsuit cannot be brought again on the same claims. The settlement’s complete terms were confidential, and the parties issued a joint statement. AudioEye also agreed to contribute at least $10,000 to the National Federation of the Blind.

Read Adrian’s account of the settlement and accessibility attorney Lainey Feingold’s coverage.

That did not end Adrian’s public discussion of overlay products. His continuing AudioEye article includes a February 2026 update challenging how a third-party comparison study was presented. That is Adrian’s critique, not a court finding against AudioEye.

My opinion hasn’t changed: when an experienced accessibility professional like Adrian raises concerns, I would much rather see a vendor investigate the issues, work with users, and improve its products than fight over the criticism.

Now let’s talk about Metro’s public safety dashboard

This brings me to a much more immediate example. For readers who don’t follow Los Angeles Metro, DPS stands for Department of Public Safety. Metro’s Board approved the creation of an in-house Transit Community Public Safety Department (TCPSD) in June 2024; the agency now refers to its developing organization as DPS. It brings together policing and security with care-based programs such as Transit Ambassadors, homeless outreach, and crisis intervention. It is led by Chief of Police and Emergency Management Bill (William) Scott. This is part of Metro’s broader transition in how it provides public safety, not simply a new name for its police contractors. Read Metro’s original TCPSD announcement and Metro’s description of its DPS safety team.

A separate body, the Public Safety Advisory Committee (PSAC), provides community perspectives and recommendations on Metro’s safety policies and programs. It is not the same thing as DPS. PSAC was established following a 2020 Board motion, and its public meetings allow riders and others to comment on public safety. Read Metro’s PSAC information and meeting page.

If you’re interested in attending or observing a meeting, the next scheduled PSAC meeting is November 5, 2026. Metro will provide the official meeting agenda, and I also plan to post the agenda on my independent LA Metro PSAC resource page when it becomes available.

I participated in a DPS dashboard navigation demonstration and wrote an accessibility evaluation dated October 9, 2026. The public-facing dashboard is publicsafety.metro.net. It presents information about public safety activity, including crime data, using filters, charts, and maps.

I want to be fair to Metro. My report does not say that the entire site is inaccessible. On Windows with JAWS, I could navigate useful headings. Radio buttons and other controls were identifiable, and choosing views such as rail, bus, or systemwide could change the display. Those are good things.

The trouble started when I tried to understand the charts.

One chart produced a stream of crime categories, numbers, dates, and axis labels, but without a usable relationship between them. I heard terms such as aggravated assault, battery, robbery and trespassing, followed by numbers and weekly dates. What I could not determine was which number belonged to which category and date. During the demonstration, I understood that the example concerned Expo/Crenshaw, but I could not independently verify the figures from the screen-reader output.

What good is a chart if I can hear its ingredients but can’t tell what the hell the data means?

The maps presented a related problem. I could operate certain controls, and the map would visually change, but the screen reader didn’t tell me what the new map represented. I also encountered a loading announcement and references to SVG and CSV downloads without a clearly usable download link in my testing. Those observations need further investigation; they are not proof that every download feature is always broken.

On my iPhone using VoiceOver, I could initially read headings, but selecting Rail produced a ‘Rail, visited’ announcement rather than a clear statement that Rail was the active filter. Screenshots from the testing showed the visual dashboard had changed to Crime | Rail while the navigation panel remained open. I also encountered an unexplained percentage around 99.9995 percent, and the chart was announced as an image without conveying the underlying values or trends. In a subsequent meeting, that figure was explained, and it is actually some great news about where we’re headed.

These are observations from my October 9 test, not a formal WCAG audit and not a claim that the live site still behaves exactly the same today.

What would actually help?

I don’t want Metro to remove its charts or maps. Sighted riders and analysts may find those presentations useful. What I want is an equivalent way to understand the information.

Give us a properly structured HTML table with row and column headings, the relevant crime categories, locations, dates, and counts. If a map changes after I select a station, tell me what station is selected and what the updated results show. Make the selected state and menu behavior clear to JAWS and VoiceOver. If the data can be downloaded as CSV, label the download and make it reliably reachable.

An HTML table isn’t some revolutionary technology. Screen readers have supported properly marked-up tables for years. The data behind a chart should not become a mystery simply because someone cannot see the chart.

My October 9 DPS dashboard accessibility evaluation describes what worked, what didn’t, and the follow-up testing I recommended. I have also prepared a public-comment statement for the Metro Public Safety Advisory Committee (PSAC), with a presentation planned for November 5, 2026. The full technical report was prepared for DPS and Metro’s review and is not being posted publicly at this stage.

If you would like to request a copy of the DPS accessibility report, please contact me at 888-405-7524 and provide your name, email address, and preferred format. Copies may be arranged through Google Docs or supplied as Microsoft Word, RTF, or Braille. For Braille, please specify your preferred code—English Braille, American Edition (EBAE), or Unified English Braille (UEB)—and your preferred line width or cell count, such as 30 or 40 cells. Braille versions will be prepared upon request and as production permits. Distribution is by request while the report is under review; making a request does not mean an immediate copy is available. After the November 5 PSAC meeting, I will reassess whether to publish the report more broadly.

One clarification about verification: when the AI assistant helping me prepare this article attempted to retrieve the dashboard, its web request returned a 502 Bad Gateway response. I did not encounter that error during my own JAWS or VoiceOver testing. The assistant’s retrieval failure does not establish whether the site was down for other visitors or whether its accessibility has changed. The findings above come from my documented October 9 testing, not from a new live audit.

Accessibility is not a button you press

The common thread here isn’t that every overlay company is identical to Metro’s data team. They’re not. Metro’s dashboard is a public information service, and my experience includes functioning navigation as well as barriers. The overlay controversies concern vendors’ products, marketing, and how they respond to criticism.

The common question is whether somebody can use the information or service independently.

I don’t need a company to tell me a page is accessible because its marketing says so. I need to be able to navigate it, understand it, and complete the task I came to do. Other people with disabilities have different needs, and good testing must include them too.

As I said in my earlier writing, websites should be accessible because you don’t know who will visit them. Accessibility should be part of designing, building, and maintaining a service, not a last-minute checkbox.

Metro has an opportunity to improve the DPS dashboard by listening to users and making the underlying data available in accessible forms. I hope the team follows through. I remain available to help test improvements. I will provide a further update after the November 5 PSAC meeting, once I have had the opportunity to make my public comment and consider any response.

And as for companies promising that one little script will solve accessibility for everybody? I think the FTC case should be a warning about making promises you can’t substantiate. Even when I disagree with the size of the settlement, I hope the investigation and final order remind every accessibility vendor that misleading claims can attract regulatory scrutiny.

What could possibly go wrong?