Simon Jaeger on Nostr: I've lost all hope of HCaptcha being a company that cares about accessibility. I had ...
I've lost all hope of HCaptcha being a company that cares about accessibility.
I had major trouble getting the accessibility cookie to work in Firefox yesterday, though I eventually solved it by disabling both Privacy Badger and the enhanced tracking protection built into Firefox.
So I e-mailed the company with an accessibility inquiry. I suggested that when requesting an accessibility cookie by e-mail, the user should also be given a code they can enter into the HCaptcha challenge. This would save users from having to deal with cookie problems, and would also allow them to solve a captcha in something like Discord, where the captcha is embedded in the app and there's no way to use the cookie at all.
Support responded and said that it was up to each app developer to implement a way to use the accessibility cookie in their app.
I responded with the following:
> Now it sounds like we're shifting the burden of accommodating HCaptcha onto developers instead of users. Developers want to implement a solution that is accessible already. If they have to design their own UI for accommodating the accessibility cookie, the solution is not accessible. Why is HCaptcha so opposed to solving this problem once so that developers do not have to solve it over and over again?
And they responded:
> The reason is because cookies are supposed to be used in a web browser. If you open Discord or Signal in a web browser, it will work. However since the apps aren't web browsers they won't be able to consume it. We have other clients that have implemented ways to consume the accessibility cookie in their apps, so it's up to the developer.
Am I crazy or does this go 0% of the way to addressing anything I said in the previous e-mail?
#Accessibility #Captcha #HCaptcha
I had major trouble getting the accessibility cookie to work in Firefox yesterday, though I eventually solved it by disabling both Privacy Badger and the enhanced tracking protection built into Firefox.
So I e-mailed the company with an accessibility inquiry. I suggested that when requesting an accessibility cookie by e-mail, the user should also be given a code they can enter into the HCaptcha challenge. This would save users from having to deal with cookie problems, and would also allow them to solve a captcha in something like Discord, where the captcha is embedded in the app and there's no way to use the cookie at all.
Support responded and said that it was up to each app developer to implement a way to use the accessibility cookie in their app.
I responded with the following:
> Now it sounds like we're shifting the burden of accommodating HCaptcha onto developers instead of users. Developers want to implement a solution that is accessible already. If they have to design their own UI for accommodating the accessibility cookie, the solution is not accessible. Why is HCaptcha so opposed to solving this problem once so that developers do not have to solve it over and over again?
And they responded:
> The reason is because cookies are supposed to be used in a web browser. If you open Discord or Signal in a web browser, it will work. However since the apps aren't web browsers they won't be able to consume it. We have other clients that have implemented ways to consume the accessibility cookie in their apps, so it's up to the developer.
Am I crazy or does this go 0% of the way to addressing anything I said in the previous e-mail?
#Accessibility #Captcha #HCaptcha