Bug #16795
No audio in Unsafe Browser breaks accessible CAPTCHAs
0%
Description
Accessible CAPTCHAs use audio: https://captcha.com/accessibility/captcha-accessibility-criteria.html#audio_captcha_accessibility
For example Google’s reCAPTCHA: https://www.google.com/recaptcha/api2/demo.
Captive portals might have CAPTCHAs on them.
Subtasks
Related issues
Related to Tails - Feature #12213: Wayland in Tails 5.0 (Bullseye) | In Progress | 2017-09-02 |
History
#1 Updated by sajolida 2019-06-10 16:47:27
- Parent task set to Feature #14522
#2 Updated by intrigeri 2019-06-11 07:57:33
- related to Feature #12213: Wayland in Tails 5.0 (Bullseye) added
#3 Updated by intrigeri 2019-06-11 07:58:16
We’ll likely have to (or want to?) fully redesign how we run the Unsafe Browser once we switch to Wayland so it’s good that we’re gathering such issues now, that can be turned into a list of potential constraints for the new design :)
#4 Updated by intrigeri 2019-08-15 11:53:14
- Subject changed from No audio in Unsafe Browser to No audio in Unsafe Browser breaks accessible CAPTCHAs
#5 Updated by zersiax 2020-05-01 17:20:01
If I am understanding this problem correctly, it is far more than accessible captchas that will break because of having no way for the browser to render audio.
Wouldn’t pretty much any resource that uses audio for it’s modality become inaccessible if there’s no transcript?
#6 Updated by intrigeri 2020-05-07 09:15:51
> If I am understanding this problem correctly, it is far more than accessible captchas that will break because of having no way for the browser to render audio.
FTR, the bigger accessibility issue about the Unsafe Browser lacking screen reader support is tracked on Bug #7502.
> Wouldn’t pretty much any resource that uses audio for it’s modality become inaccessible if there’s no transcript?
That’s true.
The only use case for which we support the Unsafe Browser is: logging into a captive portal.
Are there other resources that use audio, in captive portals, than CAPTCHAs?