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.

1. www.employment.gov.au
The inaccessibility of CAPTCHA
How you may be undermining the
accessibility of your online service

2. What is CAPTCHA

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

7. Alternatives
• Google’s reCaptcha
– Users only need to tick an option

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

12. Background reading
• Breaking CAPTCHA
– www.troyhunt.com/breaking-captcha-with-
automated-humans/
• Artificial intelligence smart enough to fool
Captcha security check
– http://www.bbc.com/news/technology-41775968

13. Other alternatives
• Form submission times
• Honeypot
• Email verification

14. Form submission times
• If a form has been submitted quickly consider
it’s been sent by a bot
– Ignore the input

15. Honeypot
• Include a hidden
form field on the
page
– If this is filled
ignore the input

16. Email verification
• Ask a user to confirm their email address by
clicking a link emailed to them

17. All reasonable responses
• Use layered
security to
improve the
security
system
Email verification
Form submission times
Honeypot

18. Other approaches
• Asking a user to add two number together
• Asking a question

19. Number CAPTCHA problem
• If bots can submit a form, bots can probably
work out this

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