Did you hear about the double arm amputee who was refused service at a bank because he could not provide a thumbprint? Did you hear about the online petition to increase services for blind folks, that blind folks couldn’t sign because of CAPTCHA? These are examples of security practices that cause barriers to people with disabilities. We don’t set out to create barriers, but some policies or code can have unintended consequences. Security can create barriers to access for users, with or without disabilities. However security doesn’t have to reduce accessibility!

Does your application use CAPTCHA or session timeouts? Does it validate data, or get users to confirm entered data before transactions? Is there data loss after re-authenticating? If you answered yes to any of these, this session’s for you.

We will begin with a brief overview of the business case for accessibility. We will then explore the main security features that can impact accessibility. Relevant W3C accessibility guidelines and techniques will also be investigated. Finally, a list of online resources will be provided.

Security should be built into applications, not tacked on as an afterthought. Accessibility should also be built into from the get go and not offered as an add-on. It can be complex to work both accessibility and security together from the start – yet it is mission critical to make it happen.

Practical Skills:
Increasing understanding about the junction between accessibility and security on the web. Examining specific aspects of security, and teaching how to consider accessibility in these things