How you may be undermining the accessibility of your online service. This presentation explains why current CAPTCHA are inaccessible, discusses some common alternatives and I explain what I think is the best approach for securing online systems whilst still remaining accessible.
3. Why use CAPTCHA?
• It’s a way to stop bots from compromising
your online service
– Creating accounts
– Spamming users
– Commenting on forums
4. Why use CAPTCHA?
• It’s free, fully automated and pretty straight
forward to add
• Requires no effort to continue using it
5. How they work
• When a challenge is
completed correctly the
user can continue the task
6. Problems
• CAPTCHA is not accessible
– Many are difficult to use via the keyboard
• Especially with a screen reader
– Very difficult to use if you’re vision impaired
– Difficult to understand any audio challenge
8. Google reCaptcha
• Uses a range of criteria to determine
humanness
– User behaviour on the page
– If the user has a Google account
9. Problem solved?
• No
– In cases when the risk analysis engine can't
confidently predict whether a user is a human or
an abusive agent, it will prompt a CAPTCHA to
elicit more cues, increasing the number of security
checkpoints to confirm the user is valid
10. Do you feel confident using it?
• If you can’t be sure users will never see a
CAPTCHA, can you recommend using it?
– An accessible website is made inaccessible
11. Captcha has been compromised
• Services exist where people solve in bulk
– CAPTCHA farms, using human labour
20. Word CAPTCHA problem
• Need to create 100’s of question and answer
combinations to ensure they don’t repeat
21. Besides is this a good look?
• Asking trivial questions doesn’t look good on a
government website
– “what colour is the sky?”
22. The problem
• CAPTCHA is a frontend solution to a backend
problem
– Why should users have to prove they are human
23. Most viable alternative
• SMS text message
• Self declaring on the account signup
• Staff assistance if the user is having problems
• Application behaviour monitoring
24. SMS text message
• Send a text message with a code before the
user can perform a task
25. SMS text message downside
• Can incur significant cost if all users are now
receiving a text message
– Be discerning and provide the text message option
for those who actually require it
26. Self declaration
• Ask if the user requires extra screen reader
support
– use the SMS text message option instead of
CAPTCHA
Do you require extra screen reader support?
27. Self declare downside
• Users may not want to self-declare to be
identified as different or requiring extra help
28. Staff assistance
• If you can’t avoid CAPTCHA, ensure there is
help available
– Confirm the user outside of CAPTCHA
29. Staff assistance example
• A link asking the user to contact you if they
encounter difficulties
If you are having problems
contact us
30. Staff assistance
• Can be a suitable stop-gap whilst a long-term
strategy for moving away from CAPTCHA is
decided
– Be pragmatic
31. Application monitoring
• Large number of unused accounts created
• Large number of requests from the same IP
address
– Investigate and block
32. The trade off
• Security and accessibility can co-exist
– Except when captcha is used to provide the
security
33. Summary
• Current CAPTCHA implementations are not
accessible
– Some may adhere to certain WCAG 2.0 criteria
– Assume all are inaccessible
34. Summary
• The Digital Service Standard advocates user
needs and putting the user first
– What user need is there for using CAPTCHA?
– It’s a business need, not a user need