They wouldn't be the first. An SVP of a major SV company once told me "[my company] doesn't give a shit about accessibility, and no one in Silicon Valley does." When I went to the CSUN accessibility conference that year, guess which company's logo was emblazoned across the lanyards? Yup, their marketing department was happy to write checks that their company had no intention of cashing.
I understand and can relate to the feeling that nobody gives a shit. And it may be true that the leadership of all of these companies only care about the bottom line. But let's not make things look worse than they are. Whatever the motive, some SV companies are doing good work in accessibility. The most obvious example is Apple; the introduction of VoiceOver on the iPhone in 2009 was groundbreaking and has been tremendously useful to blind people all over the world. Microsoft (disclosure: my former employer) is also doing good work on accessibility, e.g. its Seeing AI app. Of course, we have constructive criticism for these companies as well, but the state of accessibility in mainstream tech is not all bad.
I understand that no one is perfect. What bothers me is the hypocrisy: making it seem like they care when they really don’t. Did they spend $100k to sponsor that conference? I’d prefer they spend that money actually training people to care.
The National Federation of the Blind (NFB) recently held its annual convention virtually. One of their sponsorships was a company that provides a supposed drop-in solution for screen-reader accessibility. The solution is being widely adopted and does a very poor job fixing all but the most basic and predictable accessibility fails--and it discourages big companies from doing real work to make their products better and promote accessibility as part of their culture. There have been attempts by various accessibility professionals to engage the company, but their concerns were all dismissed and the company continues to make claims that simply are not true. The NFB investigated the company and its product, decided both it and its marketing were harmful to blind people and revoked the sponsorship.
My point--and I may be spitballing a bit here, but I think it's valid--is that CSUN made the choice to take money from a company that didn't do any real accessibility work. That reflects badly on CSUN just as much as it does anyone else, and from what I know of CSUN, a company like the one you're describing shouldn't have ever been represented.
I was unaware of this particular incident, but AccessiBe has had a bad reputation in the blind community for several months at least. Incidentally, I helped develop a browser extension to block AccessiBe and similar "accessibility overlays".
This tempts me to the idea of accepting the sponsorship but making the company name all-but-illegible in every piece of marketing material.
"But why did you do that?" "We'll display your logo to the same level of comprehensibility as your software provides to our users. Feel free to get back to us as it improves."
A more charitable explanation is they may care, but their organization might not put their money where their mouth is.
Also organizations are not monolithic singular minds, especially as they get bigger and bigger. They are groups of people and one end doesn't talk to the other is quite common.
I would expect that marketing has the uncommitted resources to spare in ways that development does not. How many weeks of engineer-team-time in SF or London will $100k get you? One, maybe?
I find a lot of questions, such as this one, boil down to resource management. It's easy to look in from the outside, judge an organization based on what you can see of its resource allocation, and use this to infer emotions. Thus $ORG does clearly not care about $SUBJECT.
Some strange alchemy has now taken place. The question is suddenly no longer about resources and priorities. Now it's about empathy, compassion, decency, and human dignity. To fail to share someone's priorities is now to imply that you do not regard them as human.
When questions of infinite competing priorities over finite resources are rendered into questions of human dignity, it's been my experience that genuine discourse becomes impossible. Perhaps that is the point.
Those of us who are affected by inaccessibility don't have the luxury of coldly viewing this as a resource management problem. Sure, the company has limited resources and pressing needs, but so do we.
Nevertheless, I appreciate that talking about whether a company or its leadership care about this stuff is beside the point. I'm calling on Cloudflare to do the right thing, regardless of whether they care about it.
It is going to cost a whole lot more than $100k to train everyone necessary on accessibility. Especially when you factor in the opportunity cost involved in focusing on that over new features or the like.
Thanks so much for holding Cloudflare accountable for this. It's upsetting that they had so much input from you leading up to it and now they're dropping the ball. A lot of accessibility stuff and mission statements just honestly amounts to virtue signalling with companies and sad to see that's the case with Cloudflare so hope they step up. It shouldn't have to get to the point where they're sued but I feel like more often than not that's the only thing that changes things like this.
This problem unfortunately applies to a lot of remote access software, particularly when the web browser is the client.
I know of one company that switched to Web VNC for accessing a specific piece of software. They had a lot of offices and the software was expensive (paid per machine). This way, they could switch to a much smaller number of licenses, letting any employee connect from anywhere and wait in line if necessary. A blind person has lost a job over this.
I read those "just sue them" responses as coming from people who have never even talked to a lawyer except when going through the paperwork of buying a house, much less been a party to actual litigation.
Companies keep lawyers on retainer to fight suits like this.They have resources of time and money to easily bankrupt someone with a disability who has just lost a job, and typically it won't even cost the company anything above what their normal retainer fees run.
> They have resources of time and money to easily bankrupt someone with a disability who has just lost a job
Is this an America thing or did I just get lucky? Here (UK) I sued a company for disability related discrimination and it barely even cost me time never mind money. The solicitor handled it all once I'd given all the information I had. They took payment out of the settlement
There are extremes when talking about the legal system. One is people telling others to sue for anything that offends them. The other is people like the above telling you that you can never win a lawsuit against a company because money is the only thing that matters.
The truth is complicated and it actually depends on the individual facts and merits of the case (duh). Blanket statements about a system as complex as a legal system are rarely ever true.
Is there a reason why comments on HN so quickly go to to " you said X but X is not always true" direction? Is there something inherent in the nature of HN readers making them gravitate towards seeing absolutism that was never there?
Hello, yes, even if the EEOC and DFEH tell you "yes, you were illegally discriminated against on the basis of your gender in hiring and the company representative put that in writing" then no lawyer in the Bay Area will take the case lmao
It is also extremely difficult to prove beyond a reasonable doubt that you were let go due to the disability, especially if there is only a single case in the company and not a track record to follow unless there is a blatant email along the lines of "they're blind, let's get rid of them."
This is a common misconception, proof beyond a reasonable doubt is only needed in criminal cases. In civil cases most often preponderance of the evidence (i.e. 'more likely that not') is enough
I'm not sure if remote access programs (web browser or not) even support screen readers on the client, especially since many of those render the entire desktop server-side and send it back to the client as an image or video. A possible option may be to run the screen reader on the remote desktop itself if that's possible.
> A possible option may be to run the screen reader on the remote desktop itself if that's possible.
For generic remote desktop access, that's what we have to do. But piping accessibility information (in its generic form, not pre-rendered as speech) to the client side in that case is much harder than it would be for this Chromium-based remote browser. (I know this from relevant experience during my time on the Windows accessibility team at Microsoft.)
> A blind acquaintance of mine once lost his job because of a newly added requirement that he use an inaccessible application.
I find it hard to believe this happened as stated in the US, where any number of lawyers would be eager to take such an open-and-shut ADA violation case.
And yes, it was in 2006. And as it happens, his employer rehired him shortly after, but only because they found something else for him to do. I believe my point still stands; for a short time, he lost his job, without knowing what happened next, and he went through the emotions associated with that.
ADA is Federal Law. It provides no damages. No attorney fees. The USDOJ is the plaintiff. Fines are imposed.
California Law is different in that it is like other civil laws with damages and attorney fees.
Consequently, cases from California make attention commanding headlines. Elsewhere in the US, citizens must beseech the USDOJ to act on their behalf…it usually doesn’t.
While ADA is federal law and awards no damages, situations like what was described would be more appropriate as an EEOC matter.
An award of damages is a potential remedy when discrimination (e.g., not providing a reasonable accommodation) is found to have taken place. It is also a perfectly acceptable offering during alternative dispute resolution or as a settlement.
Lastly, civil litigation involving the ADA does not require support from the DoJ. The DoJ, as with other matters brought before courts on behalf of the government, CAN bring about suit and are generally responsible for enforcement.
People with disabilities sue private companies all the time for alleged/actual discrimination without the DoJ.
Any U.S. resident can file an ADA complaint with the DOJ. You don't need to be disabled, you just need to be aware of an ADA violation. You can also file on someone else's behalf. [0]
There are constant and flagrant ADA violations - while the lobbying group is not weak the war of attrition is definitely with the employers not the ADA; I have seen so many violations it makes my head spin.
I have been fired because an employer was unwilling to negotiate reasonable accommodation per the ADA. Tech is insular. I chose to make zero noise for the sake of the future of my career and I wouldn't be surprised if most do the same.
Just from the perspective of shedding light on where the brokenness was/is distributed, was this specifically about vision-related accommodation, or something else? Just idly curious.
People leave jobs for all kinds of abuse and never take legal action. Other people create legal but unethical workplaces. Still others create just plain nasty work environments. The legal system isn’t that great for sorting these messes out and plenty of poeple know it.
To my understanding their browser isolation text just renders to canvas on their edge servers (don’t quote me on this). Does canvas provide any accessibility at all and is actually a bigger problem with the creation of that standard / element in HTML5 with text generation? It’s essentially an image block that allows text generation with almost no accessibility in mind? That’s not really Cloudflare’s fault if so.
I agree accessibility needs to be of higher priority. It’s a shame it’s seems to be almost always a secondary priority to everything in tech.
But this post feels like an open letter to some bigger issue when it seems like it’s a very niche and non-common security tool.
> Does canvas provide any accessibility at all and is actually a bigger problem with the creation of that standard / element in HTML5 with text generation? It’s essentially an image block that allows text generation with almost no accessibility in mind? That’s not really Cloudflare’s fault if so.
Not everything needs to be accessible; there are plenty of non-accessible reasonable use cases for canvas.
For example, I made a small game with canvas some years ago. This isn't accessible for blind users, and that's okay. There is no real way to make this accessible as it's fundamentally a graphical game. It's called a disability for a reason: there are some things you just won't be able to do.
The problem isn't with the non-accessible technologies, but when people use this in ways that make every-day stuff required for basic participation inaccessible. That's basically the issue with Cloudflare's product.
Are screen readers capable of reading interfaces generated with QT or other desktop UI toolkits?
A cursory look at QT's documentation seems to indicate that they are aware of screen readers, but I didn't dig deeply enough to find out if they were compatible by default.
I know VoiceOver on OSX can at least read out the interfaces on the included apps, but I also don't know if that's true for every app---or if it actually extends to the browser and canvas/plugin rendered (flash, java, etc.) interfaces.
As an addendum, I'm pretty hopeful that in this decade we'll get AI vision enabled screen readers so anything that's displayable to a sighted person can also be immediately used with some caveats by someone reliant on screen reader.
> Are screen readers capable of reading interfaces generated with QT or other desktop UI toolkits?
Qt is one of the very few UI toolkits that is more or less accessible. And even Qt's accessibility implementation isn't great. My advice for someone implementing a cross-platform desktop app would be to go with something based on the web platform. That doesn't have to be Electron; Tauri [1] looks promising, though I haven't tested it lately.
> As an addendum, I'm pretty hopeful that in this decade we'll get AI vision enabled screen readers so anything that's displayable to a sighted person can also be immediately used with some caveats by someone reliant on screen reader.
Sadly, that might be what it takes to get access to applications using the long tail of UI toolkits.
This is a major challenge in the Move Fast and Break Things javascript world of half baked UI frameworka that arent accessible.
The problem with AI screen readers (Android already has one) is that they provide a "good enough" solution that drains the interest in building server frameworms that really work.
The pre-announcement [1] lays out at least some of those alternatives. I understand why they chose the approach they did, but they needed to do the work to make it accessible, as I advised them when that post came out.
> To my understanding their browser isolation text just renders to canvas on their edge servers (don’t quote me on this). Does canvas provide any accessibility at all and is actually a bigger problem with the creation of that standard / element in HTML5 with text generation? It’s an image block that allows text generation with almost no accessibility in mind? That’s not really Cloudflare’s fault to be honest.
The standard workaround is to create a parallel DOM that's invisible, e.g. covered up by the canvas. To be clear, this parallel DOM should be based on the accessibility tree of the remote browser, not based on the original DOM, as that would undermine the whole point of the exercise. This work-around may not be perfect, but Cloudflare hasn't implemented even this.
> But this post feels like an open letter to some bigger issue when it seems like it’s a very niche and non-common security tool.
It seems to me, from Cloudflare's original pre-announcement of this technology [1], that they intend for it to be widely adopted. Here's the money quote:
> Operating costs translate directly to customer costs. The S2 system was designed to make deployment to an entire enterprise and not just targeted users (aka: vaccinating half the class) both feasible and attractive for customers.
IMO, the best possible solution right now would be a native desktop client for their remote browser, as opposed to a browser-based client. But it would probably be better in the long term to fill in the appropriate gaps in web standards so the browser-based client can be fully usable with a screen reader.
On most Cloudflare-related HN threads, Cloudflare was really active and eager to answer the engineers' questions.
It's notable that this one is different. The fact that it's Sunday afternoon may be part of the reason, but I guess they really don't have anything to say. I'd really love to see their internal Slack now, though.
As someone who builds an open source remote browser myself, this is a non trivial task.
but anyone who wants to attempt to bring accessibility to a pixels only or drawing instructions only remote isolated browser security model is welcome to fork my repository and add that kind of stuff.
I appreciate the importance of accessibility but the tone of that article strikes me as strident and demanding, acknowledging only the situation feelings and difficulty of accessibility users, but not of the developers, nor of the other user groups.
Technically the issue is a trade-off between security and inspectability. the most secure remote browser technology simply sends pixels or in the case of S2 and cloudflare drawing instructions from the remote browser to the local client where the viewport is then presented so there is no HTML JavaScript or css sent to the client... which is the basis of that whole remote browser isolation security model. In order to make that accessible, without having the benefit of the HTML CSS and JavaScript on the client, it's not trivial. The more you expose that information from which you can bring accessibility to the client the greater the attack surface from a security point of view. So it's a trade off.
> I appreciate the importance of accessibility but the tone of that article strikes me as strident and demanding, acknowledging only the situation feelings and difficulty of accessibility users, but not of the developers, nor of the other user groups.
Who cares about the “feelings and difficulty” of the developers? This isn’t a niche side project they’re building for free on nights and weekends. They’re being paid handsomely by a multi-billion dollar corporation selling the software for profit.
And let’s be clear about what’s happening. The trade off isn’t about security. I’m sure you’re right that it’s not trivial, but problem is entirely solvable — it just costs money. Cloudflare has decided that accommodating visually impaired users is less important than their profit margins on this thing.
I think you always need to care about the feelings of the developers... Because that privileged and entitled attitude that I see prevalent in open source and even in complaints from customers to a company... I think it's a lacking in empathy thing and it's not a good thing to encourage at all... Also, I don't think you will achieve a good outcome for yourself or for anyone involved (and that's important) if you start from the point of view of let's just not care about the feelings of this group.
But I can also see how you feel like the feelings of accessibility users are not being cared about by this decision...but I encourage you to take a step back and see things in less absolute terms because I...think the situation has a lot of nuance which when appreciated changes the the way you'd be likely to choose if you are in charge of this.
Also in this specific category consider the idea that the isolation model is perforated by the need for accessibility so while you think you're getting simply a gain for accessibility users by opening the product up to be used by them you may be doing so in such a way that weakens the security model not only for all the other users, but for accessibility users as well... So, technically, or logically.. it very much is a trade-off about security, as much as you may wish to deny. I think if you weren't thinking in such absolute terms but more acquainted with the nuance of this technology you might see that as well.
but hey i could be misreading you in my own strident and stupid way, so i'm sorry if that's the case and it's possible i haven't yet considered the nuance of your view and feelings on this.
It is correct for the feelings of blind users to be prioritized over those of the developers. Blind and other disabled people have to deal with ableism in society every single day.
No that's not right, nor even correct. You can't just disregard their feelings, and put someone else above them no matter the issue. There's no justification for this.
Disabled people have a valuable contribution to make and their voice should be heard. They should have access. But this good cause is often misused by people using it as a fake pretext for abusing others under the delusion they are absolutely right, and persecuting anyone who disagrees as absolutely wrong. This it is correct to prioritize feelings over bullshit is part of this. It's ape brain shit of trying to dominate others with criticism and control, and pretend they're holy warriors. That attitude is a contributor to why I'm so scared to engage with people about this topic. It's also sad for disabled people because these abusive crusaders give the cause a bad name, and generate counter productive resistance all for the sake of their own compensatory ego gyrations.
But separating out how the topic is misused by some looking to criticize or control others...there is a real issue here and and it's an important and good cause. But the solutions posited, often by the same folks, are not I think the best technical solutions, they're not scalable or efficient. Asking every website to provide hints might be OK at a small scale, but at internet scale it doesn't work. I think the right solution is to direct AI at the problem and have these accessibility directives generated automatically. Intelligent accessibility is a feature that should be present in browsers (or screen readers) by way of AI. People who care about the topic and want change should get to work on that.
Original author here. I am taking your comments to heart. I'm not yet prepared to concede that we should give up on accessibility standards for platform and application developers and expect AI to solve the whole thing; I need to discuss this with others in the blind community. I appreciate that expecting every application and website to implement accessibility standards doesn't scale, but it's the best we have so far.
You said the tone of my article was strident and demanding. Please note that it was addressed to the leader of a growing public company, calling on the company to live up to their own PR about their mission. I wouldn't take that tone with a solo developer like you. Even so, I don't believe I was abusive or persecuting. Still, it's likely that writing and promoting this article did make some part of my ape brain feel good about fighting for a righteous cause. So thanks for making me stop and think.
Man you're so welcome I mean it takes so much courage and self-awareness and insighy to even like... like admit that reflection to oneself in private little lone on a public forum. Thanks for inspiring me today and for directing some of that goodwill my way.
I don't think we can give up on accessibility standards but I'm really no expert. I think there's a good analogy between how you know commercial buildings need to have accessibility affordances like wheelchair ramps. And I think in that space it really works for number of reasons. Again I'm no expert in how this comes about but when you have a critical mass of standards in the construction industry and like a permitting process and an approval process where buildings are constructed only if they conform with you know standards which include accessibility then I think you can ensure, and there's sort of an expectation, that you get these affordances and then I think the marginal cost of adding this stuff when everybody in the supply chain, architects and so on, already conforms to this cost is very small for buildings... so I think that's the right allocation of cost in this case because it's efficient. Like I'm not even sure if accessibility ramps are such a great solution for disabled people but they seem to be addressing the opportunity to enhance access and they are pretty prevalent at least in developed countries. I think it's a better solution than asking every disabled person to have some special sort of wheelchair that can climb up stairs or some kind of intelligent wheelchair. Because I think in that case the cost of providing such technology to all these people right now with the technological landscape we have with consumers, it doesn't make sense, it's too expensive. It's more efficient and scalable to have building people include this stuff.
But I think accessibility doesn't have that critical mass across the supply chain of software and it is more expensive to include but on the other hand right now there's not really a good alternative on the sort of disabled consumer technology side there is no AI solution that can do this. I think a hybrid approach might work but I do think we need to look at like the AI side of having some sort of intelligent user agent that can provide the successibility information and at least have a discussion with that context that there are other options worth exploring. I think that shifts the discussion at least in appearance away from ideology and towards a solutions focus. and then maybe the sense will be cultivated that some of the resistance to including accessibility is not an ideological thing and not because people are uncaring about disabled people, it might become seen to be partly because there's a sense that this is not like a technical solution that smells good in some ways.
Anyway I'm not an expert but thanks for engaging and I'm humbled and grateful for your response here.
No that's cool, i thought you were coming with an antagonistic attitude in the first comment i just tried to play it cool and positive, i succeeded but you showed how you really felt above.
This product is not doing that to them, anymore than the visual world, and every image on the internet that isn't captioned in every detail is doing that to them. So don't pretend that it's somehow our fault that o
people are blind.
That's important. There are important issues here but too often i see people misusing the cause of disabled people as a fake pretext to abuse others, while pretending they're being righteous, by criticizing and trying to control others, driven by their own need to put others down and feel better than them, thinking they're found a legitimate way to perpetrate their abuse. But they haven't.
And that's why I'm really scared of talking with people about this because so many get caught up in that game. Especially worse when they say oh let's not care about the feelings of the developers. Because that's exactly what they intend to do... be abusive and then pretend they're righteous while disguising themselves in the cause of supporting disabled people. well they're actually hurting disabled people by proposing these ineffective solutions and poisoning the discussion about this rather than trying to constructively support effective solutions. so what I'm trying to do with this statement is bring it's important topic back from being this excuse for toxic behavior. That's not a respectful or a good use of this topic at all.
But separating that out, disabled people have a valuable contribution to make and their voice should be heard and they should have access. So there are important problems that need solutions but the solution proposed by a lot of these people being abusive is oh let's get every vendor to alter everything they do to make it conform to this standard...and agree the case of buildings it's important to have a disabled ramp or something... but in the case of software that's not a scalable solution. And it doesn't respect the developers. I think the better solution is something like a browser extension and I think the ultimate solution is to leverage The power of AI to direct that ability to create the accessibility trees and so on from websites without needing annotations surely that should be possible and I think that is the ultimate solution and you're only doing disabled people a disservice by focusing on these you know ineffective solutions when there are technologically much better and much more scalable and effective ones and then you're only doing developers or disservice by having this abusive attitude.
I'm not saying you were exactly doing that but I did detect that antagonism so it seems like you could get caught up in that too but I'm making a larger point about a dynamic that I see in these types of discussions.
so the short way of saying it is it's a really important topic so the most effective way to deal with that is to respect the developers, respectfully engage The stakeholders and try to leverage the most effective technology not to misuse the topic itself as an excuse to be abusive because you feel you need to do that.
I think in order to discuss this we'd need to be clear about the actual solutions we're discussing...I'm not right now I'm sorry, so I can say no more than, in general, any additional data you send opens up the attack surface.
Tho I can say that, relevant to your idea, at least, in my RBI product[0], you can click somewhere in the viewport and say "Copy text" and then you get a HTML dialog open over the canvas viewport with the text. A screen-reader could potentially then read that.
But I think actual accessibility tools need to do so much more...Forgive me, I'm no expert in them.
Re the above tho, I don't see that as introducing a greater attack surface (tho I might be wrong) because on the server side we're just getting the innerText of the element the client clicked on, and sending that text back encoded in base64 (IIRC).
> But I think actual accessibility tools need to do so much more
Screen readers do more, but they are not rocket science. I am no expert either, but I've worked on adding accessibility to a project that had none. Screen readers have proactive & interactive modes. In proactive mode, they read whats visible on the page, perhaps just the high-level components, giving a lay of the land. In interactive mode, it gives more detail on the control/item that currently has focus and the actions available (follow link, expand/collapse section, etc), and one would tab to move focus between controls.
I'm no expert on RBI, but I looked at your product and it appears to respond in real time to user interaction (hover over elements), perhaps what is missing is a standardized way to integrate Screen readers this "streaming" information; most accessible sites have plain-text ARIA tags/attributes meant for screen readers (with fall backs to 'title' or 'alt'[1]). However, this is just plain text, so sending text to the client adds an attack surface, but not a very large one, IMO.
I believe every developer who makes user-facing software should be forced to sit down and use their app/site with the monitor off, interacting with just the screen reader in their headphones. www.a11yproject.com has really good information on how accessibility ('a11y') works, and how to implement it correctly on the web.
1. I'm simplifying by a lot here -screen readers do a lot of heavy lifting, especially for sites/software not designed with accessibility in mind
I agree with much of your vibe and attitude here. But in general while SR may not be rocket science, solving the problem of accessibility in a general and scalable way is rocket science.
It's a really important problem, and a good cause. Disabled people, for example blind people, have an awesome contribution to make to society and we need their voices to be heard, so to speak. In other words, we need their contributions to be made. They must have access. But the question is how to go about solving that?
I think the posed solutions of getting every website to adopt a certain standard is not a good technical solution. I think pointing AI at the problem and working out how to parse accessibility hints, possibly in a personalized and contextual way relevant to the particular person as well, is one approach to the solution that's better.
This part,
I believe every developer who makes user-facing software should be forced to sit down and use their app/site with the monitor off, interacting with just the screen reader in their headphones
No, just no. I appreciate the desire to do good, but I think your attitude here is in danger of falling into the trap in this topic of being abusive to others under the mere guise of a "righteous cause" -- and in the process hurting the very cause you pretend to stand for. The misuse of this issue by some bully-like people who want to abuse others by trying to dominate them with criticism and control is one reason I'm so scared to engage with this topic. They use the seriousness of the issue as a fake pretext to case the world in their own self-serving and ego-serving view of good vs bad, and go nuclear on anyone who disagrees with their stance. But this is just ape brain shit of bullying for compensation to make themselves feel better by pretending others are worse....Just avoid that.
There is a serious issue here, and a good cause. And any statement that seeks to coerce or force or minimize the feelings of any group of people, who could just be working together on a solution, don't get suckered by the delusion that such things are somehow the right way, they're not. They're just people being bullies because their lives suck, and they take it out on others instead of fixing their own stuff. These abusive misusers of the issue give disabled people a bad name, and hinder the very cause they are pretending to stand for by, among other things, creating unnecessary friction to collaboration, and pushback.
If you care about this topic, maybe you can do some AI work on it.
For what it's worth, I've known Matthew for many years. Although I wouldn't at all say we're close, I feel like I've had enough conversation to know who he is. Matthew is a good guy, I've never considered him to be tone deaf, and I genuinely believe he has the best interest of the many at his core. That said, the credence given to the visually impaired across the industry is categorically, absolutely, abysmally awful. I've never taken it as seriously as I should in my career, near all decision makers I know don't take it as seriously as they should, and I think shame on me and shame on everyone else. Things should be easier for visually impaired people, a) because it's the right thing to do and b) because it's low hanging fruit. While I don't think Matthew is unique, I do think he has a particularly significant responsibility given how important his technology is. As a shareholder, a friend, and a customer: I hope he takes this seriously, and I suspect he would.
> For what it's worth, I've known Matthew for many years.
And for what it's worth, I don't know him at all, and wouldn't dare to assume anything about his character. I appreciate that he responded at all to my cold email 18 months ago. I just wish the company would follow through.
I don't know you either, but if there's anything you can do to help my message get through, that would be greatly appreciated.
I submitted this on Friday, but for whatever reason, it didn't catch on then. Thanks to the HN mods for putting it in the second-chance pool. I've pinged Cloudflare and eastdakota again on Twitter, so let's see what happens.
Hey, I don't work on the Browser Isolation team, but want to let you know that there's a project in progress and your post is certainly being discussed. I'm hoping we can provide a solution that meets or exceeds your expectations.
PS-- Please ardon the throwaway account, CF employees have been getting targetted online.
I'm not targeting anyone and I'm not affiliated with Cloudflare. I used a throwaway account because sharing an opinion that goes against certain narratives is seen by some people as a valid reason to declare a personal vendetta against you, demanding that your employer fires you and any future one refuses to work with you. I am merely trying to avoid that, while expressing a point of view that I believe has merit.
I wish we lived in a free country and I didn't have to do that, but sadly this is no longer the case.
. I look forward to the results of that work in progress. In the meantime, I still think it's reasonable to expect an official response. As far as I can tell, Cloudflare has not publicly acknowledged the problem yet (please correct me if I'm wrong); even a disclaimer on the product page would be better than nothing. And the last private response I got about this was 4 months ago. But thanks for telling us what you can.
It’s not business hours for non-emergency press concerns until tomorrow at tech companies whose press office is in the US, such as Cloudflare. HN can be swell, but we don’t deserve weekend hours.
Fair enough. I just meant to say that I wasn't letting the company completely off the hook because of that response from a throwaway account, not that I expect an official response today.
It's a public company and there's probably only a few people who would be authorised and feel comfortable to speak on behalf of their employer. Most of them have been working hard building the company for years and shouldn't be expected to be on call for a non-production related concern being raised on HN on any given Sunday.
Cloudflare's management is exemplary when it comes to transparent comms, maybe we can wait a day for their response on this one?
This has been prioritized since long before Matt emailed me. It was specifically flagged during our diligence process of S2 Systems, the company we acquired for the Remote Browser Isolation (RBI) technology. It has been an engineering project that I have personally followed since we acquired S2 nearly two year ago.
Unfortunately, this has proved a non-trivial problem to solve, in spite of significant engineering resources dedicated to it, and we don't yet have an acceptable solution. But I'm confident we're on the right track.
The challenge is that the process of rendering content inert to local security threats also makes it also not compatible with current screen reader technology. Matt has helpfully suggested some ideas which are in-line with what we have been working on, but the diversity of the web makes the solution very complex in practice. While I appreciate his suggestion in this thread that if we would just hire him this could be fixed in a few months, I think he would acknowledge upon reflection that is flippant.
How the web is rendered and the diversity of web pages, especially dynamically updated pages, makes many solutions that seem obvious not tenable. We need to validate the solution we deliver will work across all the complexities of the web and across a broad range of accessibility devices while, at the same time, not introducing new threats. We already have a great team doing this work. RBI is still a new product for us, and it's only been recently that we've gotten the core technology to work to a level that's acceptable, but I'm confident with the work we're doing we will be the first RBI technology in the market with broad accessibility support.
In the meantime, we provide our customers a way to bypass the RBI technology to accommodate their visually impaired employees. In these cases, we recommend that additional safeguards be put in place for these employees' machines to guard against potential security compromise. This isn't a perfect solution, but it does help significantly reduce the surface area of attack while allowing visually impaired employees to do their jobs.
I hope that others in the space with similar technologies — including Mighty, Menlo Security, zScaler, and others — will also dedicate the resources needed to make their products as accessible as possible. Matt is right to call on the industry to prioritize the needs of visually impaired users. As we solve these challenging problems ourselves, we will share what we've learned, how we overcame challenges, and we will not do anything to restrict the intellectual property behind the solutions so the entire industry can benefit.
As for the rest of the discussion in this thread, I agree that Cloudflare is fundamentally in the trust business. It takes 5 minutes to sign up for Cloudflare, but only seconds to leave. We need to earn the trust of our customers, as well as Internet users in general, on a daily basis or we won't have a business. Appreciate everyone holding us accountable to that.
> It was specifically flagged during our diligence process of S2 Systems, the company we acquired for the Remote Browser Isolation (RBI) technology. It has been an engineering project that I have personally followed since we acquired S2 nearly two year ago.
Then why is it that, as far as I can tell, Cloudflare hasn't publicly acknowledged the problem before now?
For example, the blog post announcing the acquisition of S2 said:
> (4) Transparent user experience: S2 remote browsing feels like native browsing; users are generally unaware when they are browsing remotely.
This is emphatically not the case for screen reader users, and there was no acknowledgement that that was a challenge yet to be solved. There was also no acknowledgement in the product launch blog post during Security Week [2], and I haven't been able to find any in public documentation, though perhaps I just haven't hit upon the right search term.
> How the web is rendered and the diversity of web pages, especially dynamically updated pages, makes many solutions that seem obvious not tenable. We need to validate the solution we deliver will work across all the complexities of the web and across a broad range of accessibility devices while, at the same time, not introducing new threats.
To be clear, I know why the more simplistic proposed solutions, which amount to sending down the original HTML or some sanitized version of it, would go against the goals for this product, particularly around security. I guess it's also plausible that my proposed solution, using the Chromium accessibility tree to reconstruct just enough of an HTML DOM to expose the needed information, would reopen some types of local browser escape exploits. Your team certainly knows way more about those vulnerabilities than I do.
Edit: OK, I'm convinced; I just found a report of a use-after-free vulnerability (now fixed) in Chromium accessibility code [3]. I guess I really didn't grasp how hard this is.
> In the meantime, we provide our customers a way to bypass the RBI technology to accommodate their visually impaired employees. In these cases, we recommend that additional safeguards be put in place for these employees' machines to guard against potential security compromise.
I'm sure the mechanism for configuring this bypass is documented. But does your documentation specifically call out the accessibility limitation of your product, the need for this workaround, and the recommended additional safeguards for these employees' machines?
> As we solve these challenging problems ourselves, we will share what we've learned, how we overcame challenges, and we will not do anything to restrict the intellectual property behind the solutions so the entire industry can benefit.
I hope that Cloudflare will not develop these solutions in a vacuum, but will consult with blind people who have the expertise to help ensure you're on the right track. I still offer my advice, free of charge; as I said in my other reply, my intent in the earlier comment with the rough time estimate wasn't to push for you to hire me. But enough about me; the point is that accessibility solutions developed for us shouldn't be developed without involving us.
On reflection, I think the real problem isn't how long it's taking to make the product accessible, but the fact that you went ahead and launched the product without an accessibility solution and with no public acknowledgement of the problem (as far as I can tell). I don't think it's right to sweep our needs under the rug like that.
> Edit: OK, I'm convinced; I just found a report of a use-after-free vulnerability (now fixed) in Chromium accessibility code [3]. I guess I really didn't grasp how hard this is.
Appreciate your understanding. We also understand how important this is. While we don't publicly discuss every challenge we struggle with, we're usually pretty good at finding solutions to hard but important problems. And this is clearly an important problem, and a hard one. Do hope you'll keep up the pressure on us — as well as others like Mighty, Menlo Security, and zScaler — to prioritize this. And, whatever the best solution, if we find it, we're committed to sharing it with the rest of the industry.
> we don't publicly discuss every challenge we struggle with
Of course. But that's not what I, and hundreds of thousands (or more) of other working blind people, are expecting of you. This isn't like blogging about some obscure network performance problem that the team has been struggling with. Instead, the team has been keeping decision-makers in the dark about something that's crucial for them to consider when evaluating this product. If decision-makers adopt the product without having this information about an important limitation, they may inadvertently prevent blind employees from doing their work. Even if the customer ends up making the accommodations you suggest for their blind employee(s), they currently have to be reactive about it. And in the meantime, the blind employees' productivity is disrupted, particularly if they weren't tech-savvy enough to diagnose their inability to do normal web browsing, as SLJ7 pointed out [1]. That's why Cloudflare has an obligation to publicly disclose this limitation in the product.
Also, I read just a few minutes ago that Cloudflare is partnering with Accenture Federal Services to start deploying some of your network security technology in the US federal government [2]. I know this is starting with your DNS service; so far, so good. But I'm sure you would like to offer your Browser Isolation product as well. That product is currently not in compliance with the relevant accessibility requirements for products that are sold to the federal government. I was reluctant to reach for that particular stick, but maybe it will give the team more motivation to solve this problem.
This seems a bit of a failure of communication. Let's be honest: we all know that "thanks for your suggestion, we take this very seriously!" is business speak for "yeah yeah, go away" more often than not. Even if Cloudflare is better than this (I don't know), it's still the industry average and context in which Cloudflare exists.
So if you want to show you're actually taking something serious a bit more signalling is needed. I don't think anyone really benefited that there's a team actually working on this was only communicated after this article.
naive question, but why can't you run the screen reader on the remote instance and wire key presses through? I do something similar when I need to remote desktop without using my hands - I install hunt-and-peck on the target machine, then I can say the hotkeys to bring it up and say letters to click things in the remote windows.
even if you have a crappy screen reader, it's better to throw your disabled users some kind of bone than to make them wait for some perfect solution that will never get properly funded.
I'm afraid I might be partially responsible for the lack of this work-around. In a phone conversation with the Browser Isolation product manager a few weeks before the product launch in March (but remember, well over a year after I first contacted Cloudflare about accessibility in this product), I articulated some version of the problems with a remote screen reader that I laid out in [1]. But I may not have emphasized enough that this would be better than nothing. Since it was a phone conversation and not an email exchange, I unfortunately have no record of what I said. Still, I can't take full responsibility for the fact that, to all outward appearances, they have done nothing about this problem so far.
> For blind people, TTS settings are very personal.
Is there a whitepaper that articulates concrete solutions to reconcile the myriad flavors of screen reader configurations with Browser Isolation technology?
the other issue is that while this would work for screen readers, it wouldn't work for me. I can see fine, but I'm losing the use of my arms, so I use vimium with dictation to navigate pages. they'd have to bake vimium into it as well...
...which suggests to me, why not allow approved browser extensions to run on the remote side? you could have a screen reader extension, I could have vimium, it wouldn't be great but it would be secure, and again, better than nothing.
Your suggestion is probably the correct solution technically speaking, as it funnels the screen reader I/O stream through browser APIs.
The immediate objection is that most popular screen readers (JAWS, NVDA) are native apps and not browser extensions, (some?) extension-based screen readers being immature. mwcampbell articulated it as much in a different post, asking for a native desktop client as opposed to a browser based client. Alas, 'native desktop client' is a different technology than Cloudflare RBI, subject to different tradeoffs, which may well be at odds with the goals of Cloudflare RBI as a product.
A hypothetical browser accessibility protocol is likely to prove insufficient, as native screen reader apps will themselves become an attack vector.
Unlocking the situation requires a wider industry buy-in beyond Cloudflare. Screen readers must be rearchitected with security in mind. IT departments must manage accessibility apps. Advocacy groups must commit to roadmaps that include a lot of change, and that may even degrade the status quo for many years to come. Given that existing screen reader apps have decades of engineering already poured in, it will be hard and expensive to enact change. A good early step could be creating an industry standard various entities can rally behind.
I've struggled with security vs. accessibility myself. my work won't allow my dictation software on the secure workstations we have to use, at least for the near future. they allow Dragon, but Dragon sucks for interaction and programming. companies can't just throw their hands up and say "security" though.. or at least they shouldn't. they can and do, I guess.
>I'm sure the mechanism for configuring this bypass is documented. But does your documentation specifically call out the accessibility limitation of your product, the need for this workaround, and the recommended additional safeguards for these employees' machines?
This is super important. Remember that while a bunch of us are nerds who know how computers work, some blind people might just know enough to use the web and do their job--as most people in the world do. They won't understand why the product doesn't work, let alone know how to fix it. The problem with a solution this transparent is that a request will have to go way up the chain before someone will actually know enough to address it and determine the problem. Of course it's not the job of Cloudflare to fix corporate ignorance, but a note like this one in the documentation might be a good start.
Also, it's worth noting that when using Browser Isolation with a screen reader, the product itself doesn't tell the user anything informative, e.g. through one of those off-screen messages that are sometimes added to websites specifically for screen reader users. Instead, the user gets a debug UI that isn't even visible on the screen, followed by an unlabeled graphic. So as far as anyone on the outside can tell (at least, before today's conversation), Cloudflare has done nothing about accessibility in this product.
I think it's more to do with the timing (it's the weekend). You'd really want to talk to the relevant team before saying much. Given that this isn't an urgent worldwide problem, paging team members during their weekend would be the wrong move. They'll probably have a meeting on Monday and I think that's when we'd see an update from them.
FWIW, I completely agree with you. It would be unreasonable of me to expect a response today. Edit: And, in fact, it was a bad idea for me to send the tweet I did a few hours ago when this hit the HN front page. Apologies to any Cloudflare folks whose weekend I interrupted.
Because the only publicly acceptable answer would be to agree to all the poster's current and future demands, regardless of the cost, priorities, risk of breaking other features, etc. And it never works out because the demands tend to increase over time, and the PR damage of rejecting the very last demand is proportional to the number of ones previously accepted.
Make a thought experiment: think what if Cloudflare answered trying to explain the complexity, risks, and maybe cost estimates for supporting something like that, but refusing to add it right away. Nobody would listen to their reasoning. They would be immediately labeled as blind haters or whatnot, supported by endless news articles and retweets.
Make another thought experiment: assume they comply with the current demands and add the functionality at some fixed cost. Then in the future, the poster decides that the accessibility support is not sufficient and still makes life hard for blind people. He would come up with another set of demands and Cloudflare would again be forced to comply, because nobody would listen to their reasoning. And because it is physically impossible to make a blind person as productive at certain tasks as a non-blind one, there will be always room for improvement and room for more demands.
If you want to truly help the blind, please go ahead and launch a competing product. Or offer an ML-based tool working on top of existing products. Or create Wiki-like system where people would maintain semantic models of commonly used non-accessible sites, letting the accessible tools work over them. But all of that requires hard work, countless hours and numerous trials-and-errors. Trying to strong-arm someone else to put in that effort surely gives a much faster gratification, but it only results in further alienation and ghosting.
Sure, Cloudflare will release an official statement saying how they are committed and dedicated and working and planning and hoping, and the whole thing will get forgotten in a few weeks, but ultimately if you want to someone to help you, maybe try to understand their constraints and find a compromise, rather than trying to use the buzzwords to throw the mob at them.
> If you want to truly help the blind, [...] all of that requires hard work, countless hours and numerous trials-and-errors.
I do work hard on products to help blind people, and I have been for years, but I can't solve every problem by myself. I even quit my cushy job at Microsoft (on the Windows accessibility team) to develop a product that works around the inaccessibility of screen sharing in online meetings -- imperfectly, but still better than nothing. But neither I nor my tiny company are well-positioned to compete with Cloudflare in the field of security products (such as Browser Isolation) targeted at corporate IT departments. And unfortunately, this particular accessibility problem is not one that we can work around from the outside, at least not yet. So I felt it was worth some of my time to advocate for Cloudflare to make this product accessible.
> And because it is physically impossible to make a blind person as productive at certain tasks as a non-blind one,
Of course; vision is a higher-bandwidth medium than hearing or touch. But that full bandwidth isn't always needed. And unless you've watched a blind person who's proficient with their screen reader, you may be surprised at how productive they can be at a great many tasks.
> there will be always room for improvement and room for more demands.
I appreciate that you and others on this thread don't know me, but I've been active in the online blind community for about 20 years, and I don't believe I'm known for making endless demands of mainstream tech companies. And in this case, there's a natural stopping point: when the remote browser is either as accessible as a local browser on the same website, or as accessible as it can be within the constraints of the web platform (where the client for that remote browser runs). And my original advice to Cloudflare on this subject was targeted at getting the product all the way to that logical endpoint.
Having said all that, I realize that what you said may reflect what people at Cloudflare think; after all, they don't know me either. I vouched for your comment when it was dead because I felt someone should be allowed to say what others might well be thinking, and I didn't think your comment was too inflamatory. I'd appreciate suggestions on how to better signal that I won't, in fact, put them in a bad PR situation by making ever more demands of them.
I don't work at Cloudflare. I am merely trying to share my personal pragmatic point of view.
In this specific case I would argue that the problem is taken out of scope. The idea of browser isolation is to specifically replace the "smart" stream of data that is prone to attacks with a "dumb" pre-rendered version that is much more rigid. This eliminates the whole class of attacks by design.
Sure, it won't work for blind people. So if your organization employs them and you want to achieve comparable level of security, you set them up with a properly isolated VM, install the accessibility software there, and add an exception rule for that VM. Problem solved: the blind person has comparable experience to a regular browser, while the average level of security in the company has raised. If the employer specifically refuses to set up such a VM, it would be reasonable to demand it or sue them.
To put it into a perspective, a blind person cannot drive a car in regular traffic due to obvious reasons. So it's reasonable to provide them with alternate means of transportation, but it would be unreasonable to demand that all cars should be banned until they can accommodate blind drivers. It can be technically done if you make every car remote-drivable, but the cost and safety considerations make it completely unviable.
> I appreciate that you and others on this thread don't know me
mwcampbell has also been active on HN itself for a pretty long time, and reading over his past comments should make it pretty obvious that:
A) he knows what he's talking about.
B) he is putting in a lot of effort to be reasonable and accommodating to other people and businesses.
C) he is personally contributing to and supporting efforts to build products and tools to make things better, not just complaining.
mwcambell's response above is very charitable, and I applaud that; it's good to reach out to people diplomatically. But personally, I also feel like it really wouldn't require that much work for skeptics to go over a few of his past posts and to see for themselves whether or not he is the type of person who would "use the buzzwords to throw the mob at [Cloudflare]."
None of mwcambell's past or present advocacy efforts are secretive, he is probably one of the most recognizable blind/vision-impared advocates on HN right now. I'll risk being slightly less charitable than he is being, and I'll say that people can put in the 5 minutes of effort it would take to figure out whether or not he's a good faith actor -- especially in the context of suggestions to him that the blind community should go out and build their own Cloudflare competitor.
Beware the good intentions. You likely left the big company because you hated being a small cog in the machine filling out the TPS reports.
You went to work in a smaller company because you feel that you are actually making a change. You see the direct result of your actions and motivates much more than a steady paycheck.
I understand that making a small niche product and having to monetize it yourself could be extremely tough, and it looks like a much bigger change to talk a huge player like Cloudflare in following your path, although there's a caveat. If you want them to do the job, you will be always seen as an extra expense line and dealt with it accordingly.
Imagine that you are approached by another blogger demanding that you add support for right-to-left languages to your program, and due to some technicalities, it would push your release date another 6 months on. Or some people find the voice used in the program offensive. Would you happily take on the extra work, or would you just try to sweep them under the rug?
It's always the same formula. Requiring others to do what you believe is right (and they don't) sparks tensions. Offering others something that solves a specific problem they need gives money to you and satisfaction to them. Unfortunately, recently we see too much of the former and too little of the latter.
> Now, four months later, this problem is still not solved
Further I would have never expected something like this to get teed up right before the start of a quarter, and so of course it wouldn't be completed at the end of the quarter.
OK, that sentence probably should have been something like, "Now, four months later, there has been no visible progress on this problem."
Also, remember that Cloudflare first announced the technology 18 months ago, and I advised them of the need to pay special attention to accessibility back then. If I had first raised this 4 months ago, then of course I would understand why they couldn't have solved the problem in that much shorter time.
Public services, even online, which are not accessible to those with major disabilities, is a violation of the ADA. https://youtu.be/IQjUCqVo4II
This may apply in other ways to Cloudflare, and if so fines must be issued. It's 2021, there's no excuses for it other than not wanting to put in the work.
By that logic, isn't every screen sharing app violating the ADA? A screen reader can't read the text on someone else's screen in Zoom, Webex, Slack, etc. Zoom even admits to this in their accessibility FAQ and encourages speakers to supplement with notes.[1]
> By that logic, isn't every screen sharing app violating the ADA?
We'd love it if the legislation had that kind of teeth. As it happens, in my day job I've been developing a product to work around the inaccessibility of screen sharing in online meetings, starting with providing real-time access to PowerPoint slides. But I'm not here to plug that product.
Just curious, but where do you draw the line? To use a silly example: we don't legally require every that everyone who posts an image on social media include a written description. There must be some ratio of cost to benefit at which accommodations stop being reasonable.
If we required that screen sharing tools were compatible with screen readers, we'd have to revamp many layers of abstractions. It would require changes to every operating system, every UI framework, every browser, and every screen sharing application. An alternative would be to throw a bunch of machine learning at the problem (to try to turn pixels back into meaning), but that would have a lot of broken corner cases. The issues would likely be as bad as auto-generated subtitles, which are generally not good enough to be considered ADA compliant.[1]
My guess is that if the law changed tomorrow and mandated that screen sharing tools accommodate the blind, we'd end up with no cross-platform screen sharing tools. Microsoft would make their Windows screen sharing. Apple would make their MacOS screen sharing. Google would make their ChromeOS screen sharing, and none of them would be interoperable. Also desktop Linux would be SOL.
> My guess is that if the law changed tomorrow and mandated that screen sharing tools accommodate the blind, we'd end up with no cross-platform screen sharing tools.
Solving this problem in a cross-platform way is hard, but not impossible, especially for a company as well-funded as Zoom. And yes, I have ideas about how it could be done, though like my suggestion about the Chromium accessibility tree, they're not necessarily fully baked.
> we don't legally require every that everyone who posts an image on social media include a written description
Not that it takes too much away from your point, but I've experienced an interesting gap in this example. While not legally required, big chunks of the short-form-text fediverse (Mastodon/Pleroma/…) have had circulating posts recommending descriptive text for image posts, and I'm actually surprised by how many people get into the habit of complying naturally—perhaps because there's also an easily-noticeable slot in the UI for it? Ten or so years ago I remember it being like pulling teeth to explain to some people doing media projects on the Web that this kind of accessibility was important, and now with what seems to be culturally a similar crowd… huh, y'know?
> If we required that screen sharing tools were compatible with screen readers, we'd have to revamp many layers of abstractions. It would require changes to every operating system, every UI framework, every browser, and every screen sharing application.
Why?
You're basically putting half the screen reader on each side of the screen sharing tool. This requires a significant number of changes to the screen sharing tool, but shouldn't require changing anything else.
> UC Berkeley was forced to delete over 20,000 videos of lectures because their auto-generated subtitles weren't accurate enough
Compared to the effort of setting up all those courses, captioning services are really minor. I feel like they should have just fixed that. According to the document they even have an internal unit specifically for doing this.
When it comes to the complaints that the presentations themselves were done wrong, that seems more like a situation where "fix it or delete it" is a problem.
> Compared to the effort of setting up all those courses, captioning services are really minor.
Setting up those courses is how the university makes its money. The university exists for its students, current and former, and not necessarily the general public.
Spending money on transcription services, on the other hand, would not have benefited their students, who are already accommodated regarding accessibility in compliance with the law. It might not exactly help students for the videos of lectures to be publicly available online, either, but there are plenty of good reasons to record lectures for students (if they miss a lecture or want to review), and beyond the initial cost of setting up a camera, inexpensive. And once you're recording them anyway, it doesn't really hurt to make those lectures available online.
Meanwhile, captioning is expensive. It's not a simple fixed cost, you pay standard rates of $1.50-3.00 per minute ($90-180 an hour) and that's without accounting for the other transcription problems, including (but not limited to):
- technical vocabulary many people may not understand
- professors for whom English is not their native language and thus speak with a heavy accent
- students positioned far from the microphone who ask questions during the lecture
And for what? If they have a deaf or hard-of-hearing student, they can accommodate them for their specific classes, but otherwise it's an extremely expensive proposition to do so not just for every single class whether or not they have students who need it, but also for all the previous classes in the past for which they recorded lectures. Obviously in this case taking down the lectures was the rational thing to do, especially considering that people were going to download and mirror them afterwards anyway, so it wasn't as if the lectures would be lost to the public.
And my point is that discrimination is an active effort, which this is not. Things are, by default, not accessible, because things are generally crafted for able bodied humans.
Where did you get the idea that discrimination has to be the result of an active effort? Anything that makes one group of people excluded or treated worse is discrimination, even if it is the result of an oversight.
Your second sentence is basically exactly the problem: able-bodied people are arbitrarily treated as the “default”, and others are left out.
People like you are exactly why laws like ADA were created and collectively we have decided not to just disagree with you but to pass legislation that makes it illegal for people to follow this lazy and selfish position. The first fights were over physical access and in a lot of cases it required significant reconstruction or re-architecting of spaces at great expense. The next round of fights will be over online access, where the cost of compliance is significantly less -- expect tech firms to start losing these battles now that it is much easier to attach specific harm to failures to provide accessibility.
> Able bodied people are the default because they are the absolutely overwhelming majority.
Almost everyone develops some disabilities as they age. 10-15% of the population has some disability, which is a huge group. I hope you would not argue for discrimination against ethnic minorities on the same grounds.
> And my point is that discrimination is an active effort, which this is not.
That is an absolutely incorrect and indefensible point. Discriminators can be individuals, but discrimination is systemic. It can be a result of collective acts of malice over years or generations, or can be simple ignorance- being left out of the scope of the discourse and never really given a chance to get in the loop.
Discrimination absolutely does not require an active effort. Neglect is just as effective at keeping people out.
In any case Cloudflare's inaccessibility is a direct result of choices they "actively" made. Technical decisions, prioritization, maybe even company culture.
It's not a matter of agreeing; it's a matter of the US govt is saying these are the rules for doing commerce or hiring employees in the US. As codified by the ADA. Post domino case, that clearly applies to company websites.
> It's up the the site owner if they want to block Tor or not
No. Cloudflare does that automatically when the owner selects "high protection" without clarifying the impact of the choices or discouraging such practice.
> the site owner cloud just as easily have blocked Tor if they where using a normal server
Not at all, it's difficult to implement to the same level as cloudflare.
But is blocking Tor a decision the site owner has to make, or is it the default and requiring you to set up custom site protection rules if you want to accept Tor traffic?
Explicit, using the special "country code" T1. However, I also noticed that natural blockrates (on my non-CF servers) tends to be higher on Tor exit addresses due to (seemingly) more aggressive hacking attempts - probably the same on CF (the real anonymity of Tor is both a blessing and a curse)
You can explicitly block all TOR nodes, but by default the security settings is set to "Medium" which blocks the majority of them.
I'd also like to know Cloudflare's definition of "malicious traffic". I think the main fears are DDoS attacks (which is a nonexistent threat to the majority of site owners) and scraping email addresses for spam. Which can be addressed by informing site owners to use a contact form widget instead of putting their email on their contact page.
See my corollary comment on some of my non-CF servers and the blocking - Tor does provide important anonymity, and I understand that Cloudflare, which is bigger, can probably absorb it without much damage, but unfortunately Tor exit nodes have a much higher attack and hacking attempts than regular IP addresses. In high-security applications when anonymity is already lost anyway (logging into a bank, for example) it is reasonable, due to the inherent risk, to block Tor exit nodes.
Ironically, Cloudflare's default protections is probably the largest contributor to any radical usage of TOR. It's assumed you've a subversive motive since it's impossible to navigate the open web with it.
Edit: I'm also not sure what "attacks" and "hacking attempts" mean. I'm guessing credential stuffing of admin pages? Brute-forcing the SSH password for root? These also can be prevented in a myriad other ways that doesn't disenfranchise TOR users.
It's quite hard, because it's not just "use known vulnerabilities on this specific address" - you can block it easily, and there are projects (such as CRS: https://github.com/coreruleset/coreruleset) that tries to emulate this. It's more of combined specific attacks, which is amplified because if CloudFlare detected an attempt on a single high-profile site, then that IP address can be propagate to all of Cloudflare-protected "properties" (as they called it). Combine that with how random is an address allocated in Tor (and frequent rotations), and you've got blocks without using an explicit Tor list.
> it's not just "use known vulnerabilities on this specific address"
Ok, so they're not blocking complicated attacks. Just automation of attempts to exploit known vulnerabilities. And then their IP is marked as high risk. Rinse and repeat until the majority of TOR nodes are blocked. Definitely can't see that causing issues for TOR (or VPN) users.
Edit: And to comment on this:
> Funnily, there is silence on Fastly's filter
> Cloudflare is used by 80.6% of all the websites whose reverse proxy service we know. This is 17.4% of all websites.
> In high-security applications when anonymity is already lost anyway
There are countless sites that only serve static contents and yet cannot be accessed over Tor.
Furthermore, many other provide an optional login that could be made to block Tor exit node, but the default settings of cloudflare still block the whole site.
Additionally, "anonymity is already lost anyway" when logging on a banking website is incorrect. Users might want to protect their browsing from untrusted WiFi access points or nosy ISPs or country-level censorship.
> (logging into a bank, for example) it is reasonable, due to the inherent risk, to block Tor exit nodes.
How many attackers have the skills, experience and knowledge to successfully break into a bank and yet don't know how to anonymously rent a VPS or use a botnet or a compromised host or a starbucks WiFi? 0.0001%?
I personally don't use CloudFlare but do manage a website which uses one for a job, and there's a button to mangle e-mail addresses, so I don't think this is their concern.
DDoS attacks are surprisingly negligible, comparable for ordinary IPs, so I don't think that's what they're protecting at.
It's not just Tor, their DDoS protection fails with JavaScript disabled, so sites that strictly enforce it (e.g. linuxquestions.com) are effectively censored for UAs with scripting disabled.
Why not push the screen reader component upstream?
It'd be another service add-on, but it might also be useful for folks who want to have narrative browsing, e.g., the equivalent of someone reading the news sites to the listener without having to interact with the site itself.
> Why not push the screen reader component upstream?
Are you suggesting that a screen reader should run on the same remote machine as the remote browser and push its audio down to the client? Or something else?
That would be better than nothing, and if Cloudflare had done that, I don't think I'd be complaining publicly at this point. But there are still problems with this approach. The ones that come to mind:
1. Assuming the remote service only sends down streaming audio, this doesn't work for blind people that must use a refreshable Braille display, e.g. deafblind people. Perhaps one could hack a way to get their local screen reader to render specific text on the Braille display, but probably not without that screen reader speaking the same text. That leads me to...
2. A blind user is already running a screen reader, with its own text-to-speech engine, configured the way they want it. Adding a remote screen reader to the mix would mean two different TTS engines, and the user would need to have a way of configuring the remote one, e.g. to adjust its speed. For blind people, TTS settings are very personal.
3. The remote screen reader and the local one may clash on keyboard commands. And, depending on the screen reader, this is another thing that the use may have customized already; for example, some screen readers have desktop and laptop keymaps.
4. Also speaking of keyboard commands, some of them might not be implementable in a browser-based application. It's common, at least on Windows, for screen readers to use non-standard modifier keys, e.g. Insert or Caps Lock.
To point 1, text/plain can be streamed; as for point 2, there may already be limited options, subject to application security audits.
I hate to say this, but if there was one place I'd look for vulnerabilities within a purportedly-secure environment, screen readers would be near the top of the list.
Pipedream thought: A client-server model so the text can be provided by the server and the TTS engine can still run under the user's control.
Then again, I guess my pipedream is equivalent to "re-implement the chrome accessibility system except somehow magically without any user-after-free or etc. bug" :(
No, what you're suggesting is actually quite feasible. Using an off-screen HTML element marked as an ARIA live region, a web page can make the user's screen reader speak arbitrary text with its normal TTS configuration. The screen reader would likely even render that text on the user's Braille display if they have one, though I'm honestly not expert enough in the Braille implementations of various screen readers to know what the limitations might be.
So that solves problem #2 in my list (TTS), but may not be an adequate solution for #1 (Braille). And that still leaves the problem of keyboard commands.
However, I think Ins sends a normal keydown/keyup and while capslock is a bit more complicated https://stackoverflow.com/questions/39016292/keydown-event-i... suggests it's not that hard to capture it (for front end javascript values of 'not that hard' ;).
Using the 'correct' keybindings for any given screen reader would presumably require a sort of javascript 'skin' to handle that, of course, and that doesn't solve the key clash problem at all but I'm not sure what can really be done about that except maybe remap things that are in the way on the browser side.
(spitballing in the hopes some of my random thoughts give you ideas ;)
Heh, I get the sarcasm there. I appreciate that most developers don't know anything about this stuff. That's why I freely share what I know as much as I can.
> (spitballing in the hopes some of my random thoughts give you ideas ;)
Thanks for that.
I think the real problem here is the conflict with the local screen reader. That's also a problem for the screen-reader-specific modifiers (Caps Lock and Insert); the local screen reader intercepts those key-down and key-up events, so they will never get through to the browser.
That wasn't so much sarcasm as dry english self-deprecation in this case. I have a couple friends who do accessibility stuff who I ask for advice when I need it and are always happy to give such - that's part of where my motivation to spitball comes from cos I know they'd appreciate it as a paying it forwards sort of thing (once in person conferences return properly 'buying them beer' will also work, of course ;).
Yeah, this is where I was thinking client-server, wherein the reader would (in pipedream world) send some sort of request through to the other end to move between UI elements ... but (a) that requires said protocol to exist (b) we're back to attack surface problems.
Though ... I wonder if, rather than trying to put together all-of-a-chromium, you could do something with a seriously locked down build based on the tauri project (which I think it was you mentioned upthread somewhere and I'm now going "ooh" at) but I'm aware I'm handwaving a lot there.
A screen reader is a two way device since it needs to expose ways to INTERACT with the site and not just read it. I assume there's many different settings for screen readers including voices, speed, ways of interaction with site elements (click, voice command, shortcuts, etc.), etc. It'd be like forcing you to use IE 6 to browse the modern web and then if you're not as efficient as someone on modern Chrome firing you.
Is there a case for ML based advanced screen readers which do not need assistance from the application ?
The problem seems fairly tacklable . Learning what is on a display screen is relatively easier than most computer vision problem spaces. There are many repetitive patterns in typical application UX.
For example let say there is a label for Save Icon that is an image (a Floppy Disk in most apps) and not alt tagged. By visually reading the image of the screen the model should not have to much difficulty in tagging it that as Save button ?
Most consumer / biz app UX do follow many standard conventions if only out of convenience and lack of imagination, so building a learning algorithm around these components should be possible ?
This is being worked on. AFAIK, Apple is the first to incorporate this approach into a released product, with the Screen Recognition feature of VoiceOver starting in iOS 14.
Thanks for the response Matt. I leave the link here for others to look into [1].
Their effort seems currently limited to iOS based Phone screens. iOS is perhaps easier to solve given the strong Apple design guidelines for apps to pass the App Store review process.
Perhaps a community supported distributed approach to help build the database of annotated screens for the model to learn from, combined with open source models for all kinds of screens and applications( not just Apple) would be interesting project to work on.
Interestingly, iOS screen recognition also allows exploration of screenshots and remote desktop screens. I've heard of people using it to remotely install Windows as well. It would surprise me if Apple didn't have plans to put the same feature into its M1 mac.
This paper[0] takes a look at something like this, but it's notable that this is seen as a springboard for more accessible-focused design, rather than the beginning and the end (See "Discussion & Future Work").
Heck, a desktop application that launched from a hot key and immediately highlighted any possible buttons and input fields it can recognize on a screen/window and simulate click on selection is already very useful.
Why people are still using and promoting Cloudflare when the company is repeatedly trying to position itself as an internet gatekeeper?
There is already a consensus that internet gatekeeping is bad for people, so why people are volunteering for this?
This company already has a tremendous control over what people can or cannot see on internet since a lot of websites use it has CDN, but there should be a limit on what companies can do or cannot.
In this particular case, we have blind people blocked from internet, and it doesn't matter if this is not on purpose or it is just a side effect, because in practice they are been blocked, and yet something like this is unable to make a scratch its reputation.
I like Cloudflare, because it provides some very essential services with free tiers. It is big enough, so I can trust them. I can be sure that they won't inject ads into my HTML pages. I can be sure that their DNS will not replace NXDOMAIN with fake ad responses. I can be sure that they won't log my VPN traffic trying to extract passwords or something like that.
For sure I don't support their decision to ban blind users and hope to see that resolved. But that's not enough to change my mind, not even remotely.
> I can be sure that they won't inject ads into my HTML pages. I can be sure that their DNS will not replace NXDOMAIN with fake ad responses. I can be sure that they won't log my VPN traffic trying to extract passwords or something like that.
But they have built the perfect shim in the middle to do ALL of these things at some point in the future.
The only thing preventing it is a handful of moral executives, who someday will move on or retire. At that point a smart Wall Street type is going to figure out that a merger between CloudFlare and $adnetwork is going to generate a shit ton of money (think Google+DoubleClick).
I don't doubt that CloudFlare is full of smart well meaning people, but what they have built is a ticking timebomb. The solution is to have ten CloudFlares so that the path between consumers and websites isn't regulated by a single organization.
Edit: to be clear, the internet was successful because any host could talk to any other host. If people did dumb shit you could work around it in creative ways. Even in the most oppressive countries censorship is still bypassable. CloudFlare's business model is centered around convincing companies to effectively disconnect their services from the internet so they only talk to CF servers.
And yet Cloudflare is just one of many massive internet companies. Are you going to say the same about Akamai? What about all the ISPs and exchanges in the middle? What about all the clouds and datacenters?
The reality is we live in an interconnected world where everyone uses hundreds of vendors to live and work. There's a certain amount of trust involved, backed by business relationships and the law. It's not perfect but it works just fine.
If you really think Cloudflare is excessively risky then of course you don't have to use it, but it's a strange conclusion to arrive at after looking at their actions all this time.
CloudFlare positions itself as an all or nothing frontend to your site, not just a CDN you offload assets to. Even sites that fully front themselves with a CDN you can still poke around and find the origin servers.
For example you can drop requests to fbcdn.net (which last time I bothered to check was a good mix of Akamai) and still make a connection to Facebook itself and at least logged in and view HTML.
Obviously ISPs, internet exchanges, datacenters, and clouds operate very differently. But I imagine you know the difference.
What are you trying to say? You can use Cloudflare in a variety of ways, just like any other CDN.
My point is that there are lots of vendors with lots of control involved in pretty much every business transaction. There's nothing special about Cloudflare in this regard, in the same way you trust your bank or ISP or power utility or office custodial staff. Risk management is a mature process; no wild conspiracies required.
I was with you up until "The solution is to have ten CloudFlares so that the path between consumers and websites isn't regulated by a single organization."
This is hardly a solution, it just spreads the pain around. A solution would be a democratically planned organization, or group thereof, which is responsible to all shareholders including users, employees, executives, and investors.
Basically all of those companies are regulated, and none of them can cut you off, because you did something stupid. You can even murder someone, and they can't cut you off.
Well yeah, sometimes. In some countries (i believe france), they can only limit power to lightning (a couple of hundred watts limit, so not totally off) if you don't pay, and if your only cooking appliance is using electricity (electric stove), they can't even limit that.
> The solution is to have ten CloudFlares so that the path between consumers and websites isn't regulated by a single organization.
There are! Cloudflare is by no means the biggest CDN provider - plenty of others exist out there. Akamai, CDNs from Google/Azure/AWS, Fastly, at least.
What makes Cloudflare so unique in it attracting criticism like this? They're just a bog-standard CDN, the likes of which has existed long before Cloudflare. Is it just because they're the most "visible", having a free plan that people use?
The Cloudflare captcha is ridiculous really and makes sites completely unusable with a VPN. I even get captchas for different pages on the same domain! It used to be you only got captcha for form submissions. But somewhere along the line you started getting it for simply visiting web pages as well. Part of me wonders if I'm just getting played by these companies into labelling all their ML training sets for them.
There's not really any "lock-in" with CloudFlare, though. It'd take me a day, at most, to move off of their free services.
They provide me a lot of value right now, for free. If they ever started doing something shady, I trust that people like you would cause enough of an uproar/pushback that I (and other site owners) would find out about said shady activity... and then move off CF.
I'm not as concerned with the what-ifs of what a company could do in the future as I am with their track record so far.
To me saying any $X big company is a ticking time bomb is nonsense.
The fact is, a number of companies control a huge number of eyeballs. An unethical exec taking advantage of that would cause enormous PR nightmare. If you're making money with a great brand reputation, you don't mess with the recipe.
Yes, they do mess with the recipe. They've got money to mask it out and assist with conditioning the population to the new norm. And they can do this cause the service is sticky. Mass client exodus is very unlikely. And the ones that move out for morals are quickly replaced.
We have plenty of historical data to draw from here. Cynicism is the rational approach.
Corporations (beyond a certain threshold of market control) doing shady, consumer hostile things for profit is the norm. So I don't think the ticking time bomb concept is nonsense at all.
As a recent example, Google was an overwhelming net positive for years. They genuinely made the internet better. But the day they went public their eventual abuse of their market position, intentional or not, became inevitable. We're only in the early stages of seeing what that will look like.
Asking questions about whether we want to help give companies the market position to become abusive makes the most sense early, not after it's already happened.
Perhaps I wasn't clear. The fact that some corporations do shady things does not mean it is inevitable that all corporations do it.
I'm arguing against the logic: "every big company always ends up being a den of advertising evil". Cherry picking examples like Google is not proof of this.
Not every company is Google or Facebook. Is Apple selling its soul to advertisers tomorrow? Is Netflix going to insert ad breaks every 5 minutes any day now? Is Tesla going to have you watch an ad every time you start the car?
I'm not sure how we got to it being strictly about advertising. Nor did I say 'all'. But the vast majority of corporations with the market power to leverage in shady ways for profit, do in fact do just that.
> I can be sure that they won't inject ads into my HTML pages.
But they will harass your visitors with captchas for no good reason. I also sometimes run into Cloudflare's "this website is using a protection service" with no way around; it turns out it's a geoblock because it does load just fine when I use a VPN through Germany.
The internet was meant to be decentralized. The IP addresses were meant to be used for routing and for routing only, and otherwise treated equally.
>But they will harass your visitors with captchas for no good reason.
The other fun part about those captchas is they also gatekeep blind people in a way. They're using a service called HCaptcha which doesn't offer an audio alternative like ReCaptcha does. Instead they give you an "accessibility cookie" delivered to your e-mail address, which you can then use to automatically pass the captcha. (Very useful for everyone btw; give it a try.) The problem is that this cookie--and the e-mail address it's attached to--allow CF and potentially HCaptcha to track you around the internet. There's no way to anonymously browse the net through TOR or a VPN unless you create a throwaway e-mail address for that session.
HCaptcha recently expressed interest in creating a text-based alternative, but I wonder how this will stack up against modern AI. For now, it doens't bother me because I don't encounter it often and I have throwaway e-mail addresses, but it's just one more step I have to go through to remain anonymous where any sighted person could just click the traffic lights.
Depending on the service you're offering, it can make a ton of operation sense to simply blanket-ban a whole bunch of IP blocks, including some that correspond to certain countries. China and Russia, for instance, will provide nearly-zero income but a substantial percentage of exploit attempts, stolen credit card use/validation attempts, et c., for some companies. Just banning them might make a lot of sense.
I do some backend work for a small company that sells a downloadable software product.
As far as we can tell no one in China has ever bought our product in the ~15 years it has been available. None of our pages are localized for China. If someone in China wanted a product that does what ours does there are Chinese companies whose products are cheaper and probably better for Chinese users.
Yet last time I checked something like 95% of downloads of our product came from China. I took a bunch of IP addresses from the download logs and looked to see if I could figure out something about these downloaders.
All of them seemed to be at hosting companies, not end user machines. Looking at nearby IP addresses to see what else is hosted at the same hosting company they were mostly scam or borderline scam sites or porn sites. The later was a bit unexpected because at least according to Wikipedia porn and any involvement with it is prohibited in China.
I don't see any good reason I should not block Chinese downloads. We have to pay for the bandwidth they use, they are extremely unlikely to generate any revenue for us even indirectly, and they are coming from sketchy commercial IP neighborhoods rather than end users.
>What if I want to just look at a product with no intention to buy it?
Then they want you even less.
In any case, if a company doesn't want to do business with your country, that's it. What matters whether you want to buy it or not? (Not to mention a lot of the abuse towards developers comes from no buying customers as well - people who want some feature added "before they buy", who just use the trial or free version, etc.).
You can always find a competitor company that does serve you.
International customers are more trouble than it's worth when you're a small company and you as a seller are the one who absorbs the loss in cases of delayed, defective, lost or damaged items.
I find it deeply ironic and a little sad that you cite the intentions of the original designers of ARPANET and the Internet, then describe about how you've commercialized the Internet.
I'm talking about one use case of Cloudflare I've seen. I don't think I can be held responsible for the commercialization of the Internet when I make and freely distribute monkey movies.
If 99% of spam/abuse came from one location, and it wasn't a place I offered a service to at all, I could use something like Cloudflare to restrict their access.
Europe has GDPR, and a bunch of american news sites (even articles posted here) just block you, some even without giving a reason ("this site not available in your country").
> But they will harass your visitors with captchas for no good reason.
It is up to you to harass your visitors or not. CloudFlare does not enforce it. You can disable the firewall if you don't want that kind of protection.
They enable what exactly? It's a useful tool and should definitely be activated in some use cases.
We might argue about whether it should come turned on by default or not, but as far as I remember the default setting is not a strict but a moderate protection level anyway.
Not sure what point we're trying to make here. Any other firewall/CDN/WAF enable you to do the same thing, to the point of many also providing ready-made protection profiles... what makes this specific member of that group special? Can you clarify?
The Internet wasn't meant to be used for outrageous amounts of fraud and abuse. Sometimes you have to put a captcha on ASNs or CCs because many of them simply don't care about keeping the bad guys off their networks.
Be careful with that. To be trustworthy, a party has to be willing and able to act in your best interest.
As a company (or any group) grows, their ability increases, but beyond a certain point, history shows that their willingness to act in your best interest decreases.
For companies and countries this trend often correlates with political and/or economic power being concentrated among a few individuals.
Wow geez. There's been a lot of BS being thrown around about Cloudflare. I don't work for them, but I have been following the company for years.
On Cloudflare being a gatekeeper: yes, if you care about load, cost, and attacks, you need one. Cloudflare offers real value to their customers by providing these services. Will that lead to Cloudflare controlling the web? Well, you've got a number of direct competitors (Akamai and Fastly, to name two) in addition to the CDN offerings provided by cloud providers. Cloudflare isn't the first CDN, isn't the largest, and won't have a monopoly on being an internet middleman. Compare Cloudflare's network (https://www.cloudflare.com/network/) to Google's (https://peering.google.com/#/infrastructure).
On the necessity of gatekeepers on the internet: this is the way the internet works. You are responsible for peering with the rest of the worls at a physical location and dealing with the traffic that comes your way. If you want to be close to your users (to avoid bandwidth bottlenecks and provide lower latency), you need to install equipment all over the place and peer with other networks. If you want to deal with bad traffic, you need the capacity and software to handle/filter it. You can always build your own CDN if you want, but the only way to deal with these issues is a CDN. Maybe if the internet worked differently things would be different. But that would be a huge change, especially since someone has to foot the cost of building these services. I guess you could somehow distribute the cost (though I don't see how), but you'd also have to someone deal with the management and development of said infra, and I have no idea how such a thing would work without a central entity being responsible.
Eh, gotta call this out. The Internet is designed on an end-to-end principle, and at each layer the endpoints are expected to mediate behaviour via protocols.
By this architectural standard, middleboxes (including all HTTP proxies and CDNs and what have you) are kludges. They are not "how the internet works", they are the antithesis, they are symptoms of emergent pathology. These are barriers to federation and distributed systems, both enabling and enabled by centralizing forces that divert individual autonomy & value to institutional & commercial interest. They are evidence for Further Research & Development Required, and my belief is we'll eventually solve these problems at the end-to-end protocol level.
As for Cloudflare, particularly, their business strategy is to drive down the marginal cost of their own bandwidth, for use in revenue-bearing services such as DDoS mitigation. Every service provided for "free" (some of which, at the free tier, will increase your site latency and lower your visitor count, by the way) works to increase their volumes for use as leverage in peering negotiations. As ever, "free" = "you are the product".
> The Internet is designed on an end-to-end principle
Yes, this is true, and the end-to-end principle is great. But it's not always straightforward to follow, and certainly is not a religion. In the end, no one cares about the end-to-end principle. They want systems that are flexible, robust, and high performance. In some sense, it's a lot like simplicity. You try to and make your design as simple as possible, but sometimes, you have to have complexity. It's not ideal, but it's not a deal breaker either.
Additionally, you have to ask the question: what is an endpoint? "A" server, or can a distributed system be seen as an endpoint? After all, a single server is a bunch of independent components communicating with one another (via infinity fabric, PCIe, etc), so why would it matter if we spread those components across machines (and spoke RPCs, RDMA, whatever)? To me, a service running in a data center with a load balancer in front is "an endpoint" and no real violation of the end-to-end principle is taking place.
I think extending the definition of "endpoint" to everything behind a CDN is a stretch too far, but ultimately, I think "endpoint" isn't really defined well-enough to be the unit we talk about.
On the contrary, these are not muddy grey area topics that are open to barnum statements, gaslighting, and misrepresentation, such as:
> In the end, no one cares about the end-to-end principle
This assertion couldn't be more wrong. I care; many others care; caring about the architecture of the Internet did not die with John Postel.
> you have to ask the question: what is an endpoint?
No, we don't: it's covered in networking 101. Any party in a layered protocol whose interactions are opaque to the layers below and transparent to the layers above. And they're defined by those interactions, not by their implementation.
A CDN is a forward caching proxy for content layered over HTTP, and that's all that matters when it comes to realising their emergent properties. Don't be hypnotized by the shiny dangly extras that the providers wave around hoping to distract attention from what they actually offer, or why they do it, or the consequences.
I didn't mean to offend, sorry if my statement rubbed you the wrong way.
All I'm saying is that users of a system don't think about design principles, they are there for the developers and operators to manage complexity and meet higher-level objectives. They can do this even if they are not followed 100% perfectly.
Sort of, but nature / decentralization / emergence is messy. The internet still works pretty well without rigid intermediaries (besides unavoidable core routing paths and root DNS), but that open property is also what enables people to easily disrupt things, like with DDoS attacks.
In a hypothetical distant-future anarchistic society, it's very likely you're still going to have private security forces, analogous to Cloudflare's security offerings, and some of them will probably grow to be quite big.
Attackers have an asymmetric advantage. One person with a gun can quickly terrorize or kill a lot of people, and one kid with $10 on their parents' credit card or access to a botnet can instantly bring an organization's web presence to its knees at the click of a button or input of a command.
I definitely agree that any one entity controlling too much of the access route is a concern and a risk, but before Cloudflare it was Akamai. If they never existed, Akamai and CloudFront would be the de facto oligopoly. If Cloudflare dies, someone else will probably gain a similar market share.
You can try to make security enforcement as decentralized as possible, like Bitcoin tries to. But, it was probably inevitable that a few huge mining pools would come to dominate, just like a few big security/CDN companies have.
It's plausible that there could be future solutions that will offer similar security and performance and resource-conserving benefits for free without requiring any private intermediates, and I'd happily recommend them over Cloudflare/Akamai/etc. if they existed and were as good or better. They just don't seem to be here right now.
My point was: I see no reason why we couldn't accomplish everything Cloudflare does without a central authority. Markets are able to solve just about any problem without any central person pulling the strings. Case in point: the internet.
I'm speaking specifically against the statement that Cloudflare, acting as a central authority, can solve problems that cannot be solved without a central authority.
There’s nothing about capitalism that prevents, or is anathema to companies, organisations or individuals from collaborating or pooling resources. Communism is a specific political and economic system with explicit and deliberately coercive communalising policies. It doesn’t have a monopoly on community forming or coordinated community action or the pooling of community resources though.
Because without CloudFlare we would: Pay thousands in bandwidth costs per month; Double or triple our servers to handle peaks (they cache and serve the HTML for us); Be down constantly because of DDOS attacks.
Cloudflare detects the DDOS and will block it, notifying you by email. We almost never use the Under Attack Mode unless it's actually affecting us.
The biggest thing we do to help ourselves when we're under attack is making sure that the pages being ddosed (homepage, etc) is being cached by them. There will always be some requests that CF doesnt block, so the cache ensures they get served by them.
> The biggest thing we do to help ourselves when we're under attack is making sure that the pages being ddosed (homepage, etc) is being cached by them.
What about pages which can't be cached? For example an updated comment feed? How would you deal with dynamic data?
People who DDOS sites usually attack the homepage.
If they attack a dynamic page, check if you can cache them for 30 or 60 seconds. Pretty close to real time.
If you have cookie based authentication for those pages, its going to be difficult to cache them at all though. Which is where SPAs come in useful since auth is client side.
By that logic, every one who bought Teslas in the beginning helped pay for the later customers. That's just how almost all industries work - insurance companies being a big one.
I pay nothing, so I’m obviously not a customer. If Cloudflare decides to stop hosting my site free of charge, I will have to find another host. In that sense I depend on them. Is that what you meant by dependant?
When you pay for a service, you have some leverage with them. You funded part of the service, you're a stakeholder. If they mess up, they lose your business.
That’s arguable. If the free plans help cloudflare grow its brand and customer base and is an effective marketing tool, then it’s helping cloudflare become more profitable. That might make cloudflare a more scalable and efficient business, driving down its costs per customer and enabling lower prices from scale efficiencies.
This is a well known economic effect. I can’t demonstrate it’s the case with cloudflare but it’s quite possible and even likely. Even if it’s not actually driving lower prices, customers can benefit if their service provider is more economically healthy.
Their "self serve" tiers, and especially the $200 one (the only one with an SLA at all) are really, really good value, is why. Depending on your needs, their enterprise offerings are, too. And boycotts are, broadly, not effective enough to justify any personal risk/harm/expense at all.
1) Blind people are not "blocked from the internet". This is an accessibility issue with one of their security products. It's no different than an employer using other security measures that might limit usage for certain people, but it's the employer who makes the ultimate decision.
2) The reason people keep using Cloudflare is because it has the best product suite and pricing. There are competitors but none have approached the same features or (ironically) accessibility as CF.
3) Mission statements are nothing more than politics and PR. People put entirely too much faith in corporations and their associated mottos as if they're divine principles to live by. It's up to users to make their own rational decisions by weighing the risks, and in that regard, Cloudflare has actively helped fight censorship by helping improving connectivity and access to software, information, and privacy.
But they can. They just can't read the information because the software is not fully compatible yet. What if the screenreader software didn't exist or wasn't working? Are you going to make the same complaint?
> "People use cloudflare not because it is the best product"
Care to share some evidence? Are you just assuming you know better than everyone? The company didn't reach $35B market cap because of a free tier (which is also considered part of the product by the way).
> "says their PR is very effective."
Actually, I said PR should be ignored and you should instead look at their actions, which do back up what I claim.
It sounds like you're completely unfamiliar with the company and instead have some irrational vendetta against them. Not sure why, but it certainly doesn't lead to any productive discussion. Let's end it here.
More and more, "because security" has become the go-to reason, almost a thought-terminating cliche, for destroying freedom and privacy. It's really disturbing to see.
We usually quote 50-100% increase for agency web dev stuff (mostly marketing sites) and I'd say we've underestimated a few times. For basic html layouts it's not too bad but the minute you move away from something that looks like Craigslist or Wikipedia stuff starts to get hard. We've used 3rd party consultants to do reviews and every reviewer picks out different problems on the same exact site. I've implemented consultant recommendations line for line only to have that code flagged by a different reviewer at the same company as non-compliant.
I did screenreader support in a rather popular Android app. It took me several days to get from "can't focus anything at all on the main screen" to "all icon buttons are labeled and most of the functionality is usable, including the many very complex custom views with clickable elements inside".
Of course it matters. If your model of the world is “we need to spend infinite resources ensuring every system can be operated by anyone with any disability”, that’s obviously nonsense.
Accessibility is valuable but not infinitely so. Sometimes (usually) it’s best not to encumber an innovation just because the innovation doesn’t immediately apply to everyone.
The cost is considerably lower if you watch out for a11y from the get-go, retrofitting it is more expensive since you have to retain the existing behavior, sometimes of existing and complex but non-accessible components. Add to that the need to e.g. caption all the existing pictures and it gets even worse.
It really depends on the specifics; for something like this I suspect it's a non-trivial investment. For a lot of other things it's not that hard.
For a lot of things a18y features are just good features in general; zooming text for example is something loads of people do, not just blind or low-vision people.
For the specific project of making this remote browser accessible, my wild guess is that if Cloudflare were to hire me to work on the project (no, not available at the moment), it could easily take a few months, but probably not more than a year. They could probably cut down that time if they hired away someone from the Chrome or Edge team who's actually an expert on Chromium accessibility specifically; I admit my main expertise is in Windows accessibility.
It’s part of every product team’s baseline requirements to own and assess. It’s considerably easier to do that up front than to retrofit. Think of it as analogous to security in this situation.
We're probably headed for a world in which everything is rendered to an image server-side. The HTML/CSS/Javascript mess has become so bloated and attack-ridden that sending images needs less bandwidth and is simpler.
> Their “client” was basically a fancy, highly specialized graphics terminal; all the real work was done on the server. For example, when you issued a command to an object, instead of sending a command message to the object on the server, the client would send the X-Y coordinates of your mouse click. The server would then render its own copy of the scene into an internal buffer to figure out what object you had clicked on.
Canvas rendering is not server side computation and streaming video, it's turning the web browser into even more of a desktop application platform. After a certain point, html breaks down.
That wouldn't be so bad if the server sent down a tree of semantic UI elements, a.k.a. an accessibility tree, along with that image. That's basically what I advised Cloudflare to do ~18 months ago.
Except doing so is probably much more complicated than actually dealing with the CSS and HTML. Hell, it would probably take twice as much manpower to make this remote browser thing accessible than it took to make it work in the first place.
I doubt that. Chromium's internal accessibility tree is already serializable; it has to be, so it can be sent from the renderer process to the main process. So Cloudflare's modified Chromium could send that tree down to their JS-based client, which could then construct a DOM with the appropriate HTML tags and ARIA attributes. This DOM wouldn't have any JavaScript or any references to remote resources, so it wouldn't pose the same security risks as the original web page.
There are several problems with that approach. First, there's not enough information in the serialized accessibility tree to reconstruct the DOM.[1]
Second, the serialization format is an internal API, so there are no constraints on backwards compatibility. It can change in any version of Chromium. In fact, the interface is updated all the time.[2] Cloudflare would have to constantly update their JS client to handle those changes. It's not an abstraction that can be relied upon.
Third, the bandwidth and latency requirements for inter-process communication are far higher than what is available for most client-server communication. Even if the API were stable, I doubt it would be feasible to use on typical Internet connections. If you don't believe me, go to chrome://accessibility/ and click "Start recording" on a tab. I did this for an IRCCloud tab and got 4500 events in approximately 2 seconds.
> First, there's not enough information in the serialized accessibility tree to reconstruct the DOM.
There doesn't have to be enough in there to reconstruct the original DOM, just enough to expose all of the information that screen readers and other accessibility tools need. The fact that that information would be exposed through an HTML DOM in this case is irrelevant; we know the Chromium accessibility tree has all the necessary information.
> Second, the serialization format is an internal API, so there are no constraints on backwards compatibility.
OK, you got me there. Maybe the server side has to go all the way and construct the HTML.
> Third, the bandwidth and latency requirements for inter-process communication are far higher than what is available for most client-server communication.
OK, again, maybe the server side has to digest the data some more before sending it. But at least Chromium is already pushing serialized tree updates. I'll withhold a rant on how it could be much worse.
Does this handle (lots of) (sometimes large) page updates, particularly across a semi-slow, semi-reliable network? Think lazy loading, sPA-style diff-based page transitions, or realtime progress bars. What about element positions (i.e. for switch control overlays that visually mark specific elements on the page)? Assuming this just sends keys directly to the remote browser, what about cursor-related events in editing fields? If latencies are over a few ms with those, some screen readers get confused.
Good questions. You have an especially good point about the latency of responses to cursor movement commands; the developers of NVDA and JAWS might have to rethink their approach to that.
But as far as I know, Cloudflare hasn't even tried yet.
Since this DOM would be invisible, hidden behind the canvas, I'd say you'd need just enough CSS to make each element have the same bounding box as the original. Bonus points if you can safely do enough CSS to make the font size and colors match; screen readers do have commands for querying those things.
> And mutations to this dom would need to be tightly synced to image updates to not confuse the hell out of nvda?
Chromium has already taken pains to make sure this works, because its whole accessibility implementation is dependent on pushing tree updates from the renderer process to the main process.
Because the screenreader is set up and runs on the users local PC, unless you expect users to use whatever unknown-to-them screenreader setup CF happens to choose to run remotely.
Thats 1 option, but I think there is more to explore than that.
E.g. to look at canvas implementation it appears CF delivers a Chromium render to canvas.
Maybe what helps here is standardisation.
That render wasn't sufficient during the browser wars of ole, but isn't a point of contention now because of standardisation.
This has been prioritized since long before Matt emailed me. It was specifically flagged during our diligence process of S2 Systems, the company we acquired for the Remote Browser Isolation (RBI) technology. It has been an engineering project that I have personally followed since we acquired S2 nearly two year ago.
Unfortunately, this has proved a non-trivial problem to solve, in spite of significant engineering resources dedicated to it, and we don't yet have an acceptable solution. But I'm confident we're on the right track.
The challenge is that the process of rendering content inert to local security threats also makes it also not compatible with current screen reader technology. Matt has helpfully suggested some ideas which are in-line with what we have been working on, but the diversity of the web makes the solution very complex in practice. While I appreciate his suggestion in this thread that if we would just hire him this could be fixed in a few months, I think he would acknowledge upon reflection that is flippant.
How the web is rendered and the diversity of web pages, especially dynamically updated pages, makes many solutions that seem obvious not tenable. We need to validate the solution we deliver will work across all the complexities of the web and across a broad range of accessibility devices while, at the same time, not introducing new threats. We already have a great team doing this work. RBI is still a new product for us, and it's only been recently that we've gotten the core technology to work to a level that's acceptable, but I'm confident with the work we're doing we will be the first RBI technology in the market with broad accessibility support.
In the meantime, we provide our customers a way to bypass the RBI technology to accommodate their visually impaired employees. In these cases, we recommend that additional safeguards be put in place for these employees' machines to guard against potential security compromise. This isn't a perfect solution, but it does help significantly reduce the surface area of attack while allowing visually impaired employees to do their jobs.
I hope that others in the space with similar technologies — including Mighty, Menlo Security, zScaler, and others — will also dedicate the resources needed to make their products as accessible as possible. Matt is right to call on the industry to prioritize the needs of visually impaired users. As we solve these challenging problems ourselves, we will share what we've learned, how we overcame challenges, and we will not do anything to restrict the intellectual property behind the solutions so the entire industry can benefit.
As for the rest of the discussion in this thread, I agree that Cloudflare is fundamentally in the trust business. It takes 5 minutes to sign up for Cloudflare, but only seconds to leave. We need to earn the trust of our customers, as well as Internet users in general, on a daily basis or we won't have a business. Appreciate everyone holding us accountable to that.
> For the specific project of making this remote browser accessible, my wild guess is that if Cloudflare were to hire me to work on the project (no, not available at the moment), it could easily take a few months, but probably not more than a year. They could probably cut down that time if they hired away someone from the Chrome or Edge team who's actually an expert on Chromium accessibility specifically; I admit my main expertise is in Windows accessibility.
And of course it's possible that even what I wrote there is too optimistic.
I'm sorry I was unclear. What I meant was that I could see the project easily taking at least a few months, and maybe up to a year, but likely not more than a year.
Also, the intent of that comment was to give my answer to a question about how big a project this would be, not to suggest that Cloudflare should "just" hire me. I even suggested that I wouldn't necessarily be the best person for the job.
Anecdotally, even with websites like Twitter that obfuscate their CSS class names to prevent the use of selective adblock, they still leave the readable ARIA strings in predictable places, allowing uBlock Origin users to create blacklist rules matching them. I'm wondering if those two features are at odds.
Do we know that Twitter is intentionally doing that to defeat adblockers? It’s a common speculation I see about them (and maybe it’s a convenient side-effect), but these sorts of mangled class names are also a common feature of popular CSS-in-JS libraries. (I work on an internal app that does the same thing, and it’s incredibly annoying but definitely not explicitly intended to be hostile.)
Compatibility for supported assistive technologies such as screen readers, braille devices, and screen magnification features, will not be impacted by the canvas-based rendering change. We will continue to ensure assistive technology is supported, and work on additional accessibility improvements enabled by canvas-based rendering
Flutter is (somewhat) accessible with the help of an alternate, hidden DOM, only provided if an "enable accessibility" button is pressed, for performance reasons. Unfortunately, some privacy zealots prevented web browsers from communicating that a screen reader was detected, so we need to press an extra button anytime we visit a Flutter app.
Google Docs has had two relatively good accessibility implementations for a long time, none of which relied on the original DOM, which was hidden from screen readers. The default one relies on pushing raw strings for the screen reader to speak, while the other one (called Braille mode, as the first method couldn't provide braille display compatibility), uses more modern APIs to provide the required information in the DOM, relying on special announcements only where necessary.
Have you tried using a screen reader with Flutter apps or the canvas-based Docs?
From the very first result on “Flutter accessibility”:
>> We strongly encourage you to include an accessibility checklist as a key criteria before shipping your app. Flutter is committed to supporting developers in making their apps more accessible, and includes first-class framework support for accessibility in addition to that provided by the underlying operating system
Enforced accessibility would be horrible. What if I want to make an application just for me? Or a game or something else where the basic concept isn't fundamentally accessible for blind people?
A lot of the open source software I release is for one reason and one reason only: it's useful for me. I generally try to make it a bit useful for others as well, but that's mostly just a nice bonus. I do care about accessibility in general (actually, I've been meaning to ask Matt about accessibility on CLI programs) but it's not really something I think about on these kind of programs, just like I usually don't consider most use cases outside of my own. If someone were to bring it up then I'd see if something could be done (like any other issue people bring up), but this depends on my available time and "if I feel like it" as well.
The alternative would be to never release it at all and keep it in my ~/code directory. I think that would be a loss.
> (actually, I've been meaning to ask Matt about accessibility on CLI programs
Assuming you meant me and not some other Matt, go ahead. In general, I'd say it's pretty hard to make line-oriented CLI programs inaccessible. Screen-oriented (e.g. ncurses-based) programs are, in my experience, harder to use with a screen reader, but still generally not terrible. Anyway, happy to answer any specific questions you have.
Some time ago I was drafting an article on CLI UX principles, and I wondered if there are specific a18y issues or annoyances that could be included. I couldn't find a lot of resources on this.
I do remember this old bsdtalk interview from years ago[1] about a Braille user, and what she said pretty much mirrors your comment: "CLI apps are usually really good, curses can be tricky". My feeling was that there wasn't much written about it because there's not much to write about: "it just works".
Still, there might be (small) things that might make a difference; as you pointed out in your other reply, it's hard for me to truly "experience" this. I thought it might be a good idea to check in with some people.
Your statement contains a misguided assumption that adoption of Flutter on the web explicitly breaks accessibility; it's no wonder that you didn't receive a response.
Under 15 employees, Title I does not apply to an organization's website.
Above that number, and, provided that it's part of the design phase, ADA Title I and/or Title III compliance can be achieved by ensuring that each element, attribute and operation is sufficiently tagged; this validation can be built into widget testing in the same manner as one might do for React components.
OCR is a poor substitute since it can't really effectively navigate things due to lack of navigational information, recognition of semantic elements like headers, etc.
I'm not blind myself, but I've tried to use some screen readers in the past to get a feel of what it's like. While I'm a very inexperienced user, one thing I noticed is that even with the best designs it's actually really time-consuming compared to regular browsing. I would imagine that an OCR solution would be even more time-consuming, if it even works well at all.
Please be careful about drawing conclusions on what web browsing must be like for blind people, based on your limited experience with a screen reader. One of my blind friends put it more eloquently: https://news.ycombinator.com/item?id=9284744
A sibling comment makes a good point about blind people running their speech synthesizers at high speeds. Experienced screen reader users are also good at using their screen reader's many keyboard commands to jump around a web page.
Sorry, I didn't mean it to come off as definitive or to say that it's exactly like your experience – that would of course be silly and misguided.
It's one thing to listen to people talk about it, but it's another to actually use it. Not to be stubborn about it, but wouldn't you agree that while you can certainly be effective with screen readers, that in general it's (or can be) less convenient than "normal" computer usage and comes with some downsides? After all, if it was of equivalent convenience then loads of people would be using it, no?
I should get back to this; but unfortunately I found it very hard to get a screen reader running on Linux :-/
In an ideal world where products are all accessible, I would say we could be just as efficient at most daily tasks. Obviously this is not an ideal world, but if we give ut screen-reader support equal weight compared to visual design, it probably comes closer than you think. But if we look at this in terms of the web as we know it, there are going to be a ton of websites where sighted people can navigate efficiently because the website was built for sighted people to navigate efficiently.
> After all, if it was of equivalent convenience then loads of people would be using it, no?
It's hard to approach this with a sufficient lack of bias because I don't have any sight, but wouldn't you say that for most people, sight is sort of a "lazy sense" in that people will resort to doing things in a visually-intuitive way long before they'll learn an alternative method? That's the whole reason computer interfaces were designed the way they were. It's the most efficient way, but part of that is because our brains are wired for it to be the most efficient way. If you take away that possibility, sure I'll be less functional with one of my senses missing, but between the frustration of being less efficient and the removal of the remote possibility that I could learn to do things using sight, I have a lot of bandwidth for learning and discovering other ways. Of course, I'll never know whether I would be more efficient with sight if I had grown up with it, and there's a possibility I may never know in general. I suspect a power user who has mastered keyboard shortcuts could probably navigate most interfaces more quickly. The bottom line is that the average blind person has more incentive to learn the inner workings of technology, so many people will be able to navigate at a speed approaching that of the average sighted person or possibly faster.
It's possible to run a screen-reader on Linux, but I wouldn't rely on it as a testing mechanism. You'd be better off with Windows or Mac, which both have built-in screen-readers now. I am aware of blind people who use Linux as their primary OS, but the community is much smaller and unfortunately it just isn't as polished, nor does every desktop environment and app offer the same level of accessibility.
> Not to be stubborn about it, but wouldn't you agree that while you can certainly be effective with screen readers, that in general it's (or can be) less convenient than "normal" computer usage and comes with some downsides?
Of course. Vision is a higher-bandwidth medium than speech or Braille. But you don't always need all of that bandwidth. And, at least in my experience, sighted people tend to underestimate how well a blind person can compensate for their impairment, in this case by being really good at using a screen reader. That's why I replied the way I did. Sorry if I came off as too accusing.
BTW, I'm not even an especially skilled screen reader user. I have enough sight to read the screen up close with largish fonts, and I used computers that way for a long time before I started routinely using anything resembling a modern screen reader. (I did use early screen readers as a child in school, but didn't have access to them at home.) Even now, I do my programming visually. But make no mistake, there are blind programmers who are very productive programming with a screen reader; I'm just not one of them, at least not yet.
> I found it very hard to get a screen reader running on Linux :-/
Unfortunately, IMO the best screen readers are on Windows.
I've heard that actual blind people train themselves to use a speed of speech that is almost unintelligible, so it might be significantly faster for them to use the same software
They sort of do. Voice Over on iOS, and it's screen recognition, is probably the most notable example. It even tries to recognize some UI controls and emulate common behaviors (like sliding a slider), for example. It's far from perfect. It might help when you need to click the odd inaccessible button, but is definitely not enough for daily web browsing.
Are there large companies that have deliberately made their products less accessible to those with disabilities, because they're completely hostile to scrapers (and the open web)?
Is it even possible to make a completely closed/hard-to-scrape web app that is still 100% accessible to the blind?
> Are there large companies that have deliberately made their products less accessible to those with disabilities, because they're completely hostile to scrapers (and the open web)?
I'm not aware of any, but that doesn't mean they're not out there, in some specialized niche perhaps.
> Is it even possible to make a completely closed/hard-to-scrape web app that is still 100% accessible to the blind?
I would guess not. The headless browsers that scrapers are already using could be extended to expose their accessibility tree to scripts as well as the DOM.
It is easy to agree that accessibility is important; it is another thing to make sure new products are accessible to all I am interested to see the response to this open letter. As a blind person myself I know how vital accessibility is in employment. . .
Accessibility is important. Four months is not a lot of time for any large scale software project with a large team. Every little feature takes time. Why is it assumed that Cloudflare is not working on accessibility?
The open letter states the author contacted Matthew Prince (CEO, Cloudflare) 18 months ago, and received a response;
"...assuring me that the team was taking accessibility into account. In particular, you wrote the following, referring to your company’s mission: “Agree with you that it’s critical we not take a step backward as we’re working toward building a better Internet.”
If I had first told them about the problem 4 months ago, then of course it would be too soon to expect a solution. But as I wrote further down in the OP, I first contacted them about this roughly 18 months ago. As far as I can tell, they haven't done anything about it in all that time. And though I was previously in contact with the product manager, it has been 4 months since the last time he wrote to me, despite my recurring requests for an update.
Also to be clear, I didn't choose to escalate this now because it has been 4 months. The trigger was Cloudflare's "Impact Week", which included a blog post about their Flarability employee resource group.
If my understanding is correct, Cloudflare first released Browser Isolation 4 months ago.
If my experience in the industry is relevant, they just barely released an MVP to get ‘something out the door’.
I don’t know where accessibility is on their feature backlog (for all I know, maybe it isn’t) and I understand your point but I don’t think that 4 months is a long time for these things.
This makes logical sense. Smaller companies have fewer innovation tokens; large organizations like Cloudflare carry heavier burdens when releasing new products (i18n and a11y primarily among them).
Yes. But then you have to hire a lawyer after just losing your job, survive during the time the lawsuit will take, win the lawsuit ("plaintiff was let go because position was redundant"), collect, resume your job or job hunt with a "trouble maker" label.
I really wish HN contributors would not suggest the legal system as a solution for these types of problems, it's totally unrealistic.
We are in a new world when it comes to corporate PR. Companies are doing so much horrible shit right now, I don’t think you can expect bad PR to have any effect at all.
IMO this is a pretty clear-cut discrimination case. I'm aware that lawsuits can be problematic for quite a few reason, but just eating it up would be a just as horrible suggestion.
Aside from practical concerns such as time and money, these kind of battles can be very emotionally draining. Some of the most stressful experiences I've had in life is when some company or person did me a serious injustice and it's hard to get your rights.
I found it's better to let go, for my own sake. It's very stressful and very easy for the situation to consume you, which isn't healthy and on balance you may be worse off if you factor this in. Everyone is different, and other people may experience these kind of things different, but I've seen the same in various other people, both publicly and in my private life.
Of course this really sucks and is very unfair. But it doesn't change it.
He got lucky; as I mentioned in another comment [1], which links to more details on what happened, he was quickly rehired in a different role. But for a short time before then, he went through everything that comes with unfairly losing a job. And again, it might not have ended so well.
Its clear cut discrimination, sure, but discrimination based on disability is only prohibited if it is against “a person with a disability who meets all of a position's legitimate job requirements and can perform the essential functions of the position with or without reasonable accommodation.” [0]
The question isn't “is this discrimination” but is the requirement to use the software in question a “legitimate job requirement” and/or an “essential function” that the worker cannot do without accommodation, and for which no reasonable accommodation is available with which the worker would be able to perform the function.
what is the legal situation here? wouldn't laws that require the employer to make accommodations for the disabled simply force the company to not use this tool for blind employees?
the company would have to prove that using this tool is strictly necessary, which i believe is hard to prove, because if it was strictly necessary then everyone at home should be using it too.
there should only be few places where such a tool is strictly necessary, and those places already use it. anyone who only starts using it now when it gets more convenient can't make the claim that they could not do their work without it because they could until now.
We may disagree on whether browser isolation is strictly necessary. But to the extent that Cloudflare's marketing efforts convince IT departments that it is, and that it's important to adopt it company-wide, that's bad for blind people unless Cloudflare makes the product accessible. I don't know if their marketing efforts are succeeding, but I'm being proactive here.
well, i mean strictly necessary in the eyes of the law. but that's something we won't find out until affected people start suing employers for discrimination or whatever the appropriate claim here is. and until then there will be casualties as you already predict.
Why is everyone here saying the same thing, given that we had a Cloudfare employee clarifying that this feature can be disabled, for now, in the machines of those that are visually impaired?
i didn't say anything to the contrary. of course it can be disabled. but am i going to allow it to be disabled for some of my employees if my customers start demanding that i use this feature while i develop their software? probably not until there is a lawsuit that clarifies which need takes precedence.
TBH it only becomes an issue when its required for the blind people to use this browser. If I was running a company and ran into this, I would just say the blind people and other unserved edge cases should just use normal chrome until cloudflare delivers the full version.
Security is a probability spectrum, not a binary as many are fond to think of it.
I hope any companies that adopt this product agree with you on this point. But in case they don't, I still think it's important to urge Cloudflare to make this product accessible.
A small company TBH would not adopt this kind of browser, and a large company that might is too paranoid about lawsuits & CYA behavior to not make such an exception once it got escalated. And if it became very wide spread, I think it would have that stuff built in too, because to get some big company / govt contracts an accessibility requirement eventually gets thrown in somewhere.
I hope then, at the small company you can just talk to the person and ask them to let you use the normal browser, just like you would if any other tool was interfering with your edge case, be it disability related or not. The nice thing about many small companies is they are biased towards less 'paperwork' and more action.
I find in most companies that you are not a minimum wage worker, the only real blocker towards not being able to do something is compliance law preventing you from not doing something. That conflict of laws is where most companies seize up. I hope something like this doesn't become a mandatory thing for compliance security things one day without proper accessibility support.
The legal situation is akin to speeding. While technically it is illegal to drive 56 in a 55, you won’t get a ticket for it. And lots of places the flow of traffic will be 85 in a 65 and the cops are not about to hold things up.
Same with accessibility only there are powerful economic interests at play too.
> And lots of places the flow of traffic will be 85 in a 65 and the cops are not about to hold things up.
They sure will. They'll pull a traffic break when something is wrong. They get out in front of a block of traffic, throw on their lights, and begin swerving across lanes, instructing the speeding flow of traffic to collectively slow down. I've seen cops routinely do that in both California and on the East Coast.
Cops will do that for various reasons, including safety purposes (if something has happened up ahead) or just to reassert control if they decide the flow of traffic is going too fast. Here is a safety example of it in action in Utah:
The German example was about debris on the traffic lane(s) that had to be removed ASAP, and for a safe working environment, the traffic has to be slowed down/stopped.
> Why does a networking infrastructure product affect the browser visual UI in an way?
Because, as the original technology announcement [1] (which I linked in the OP) explains, they're running a remote browser and sending the rendered graphics from that browser down to the local client. So, since they're not putting in the extra work to send the semantic information required by screen readers and other accessibility tools, this breaks accessibility.
> If this happens to you, please call a lawyer. This is an easy case to win.
You're the fourth commenter on this thread to make that suggestion. Please check out the responses to the other three. [2] [3] [4]
When requesting new functionality please complete the “revenue opportunity size” field in the Jira and indicate what quarter you expect this opportunity to close.
You're not wrong, and the answer is that this sort of thing needs to impact their bottom line somehow - either because customers insist on it as part of a purchase checklist, or because the legal system will actually go after violations, or because they'll lose important employees.
I don't have a real sense of which of those is most realistic.
I'm not so sure that there's a legal recourse for this on Cloudflare's part, but it's certainly possible for the customer–at which point, the demand will increase to a tipping point.
Sad but typical and not just from big "evil" companies (not suggesting that CF is!)
I just ran Jekyll to migrate my Blogger blog to self-hosted and with the default importer and default theme, I clicked the Web Accessibility button and immediately got some several hundred contrast errors (lots of blog post links) and some incorrect heading levels. Just basics but people are too unaware of accessibility requirements that this even happens before a release.
What is missing? Is there not an online checker like w3c does for markup or acid does for browser tests? Oh yes, it is here: https://wave.webaim.org/ and there is also a browser plugin so no real excuses.
I don't know what you did exactly, but the default Jekyll theme is fairly simple black-on-white and doesn't seem to have any major issues from quick spot-check.
Silicon Valley is famous for its 'patina of accessibility': https://medium.com/@nicklum/silicon-valleys-patina-of-access...