Accessibility and Security

Accessibility is important. Security is important. These topics are rarely discussed together. This is just an introduction to these topics. I’m scratching the surface and giving you information to get going further.

Table of content

Abstract

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.

If “Easy to use” then “Easy to break”?

From an accessibility and usability perspective, we want things to be easy to use. From a security perspective we want things to be difficult to break. Do these requirements conflict? No. We have to be careful, because the complexity of code often grows as we make applications easier to use and this introduces room for more vulnerabilities. But an “easy to use” application does not have to be “easy to break”.

Unintended Consequences

“Without reflection, we go blindly on our way, creating more unintended consequences, and failing to achieve anything useful.”Margaret J. Wheatley

We often do things a certain way because it’s the way things have always been done. We adopt policies because we’ve seen them elsewhere. We carry-on and do our job, sometimes without really thinking about it. We don’t look in our rear-view mirror, and we miss seeing the car crash we caused, which could have been prevented had we planned a little better.

We must think it through all the way. Otherwise we might create unsurmountable barriers.

Double Arm Amputee

In 2009, Steve Valdez went to cash a check at a branch of Bank of America in Tampa, Florida. The check was written by his wife, who had an account at that branch. Valdez himself did not have an account there. Bank of America has a no-exception policy of requiring a thumbprint if you want to cash a check without having an account with them.

Valdez was not able to provide a thumbprint, because he was born without arms.

While he was offered two solutions (open an account, or go get his wife), they were not reasonable within the context. The cashier even noted that he could not provide a thumbprint.

Sometimes, a company has to be willing to make exceptions to their policies.

Online petition for blind folks

Such an exception was exactly what a petition on the White House’s petition website wanted to achieve. A petition was created to allow, among other things, media shifting so folks with disabilities could access content of digital books. The primary stakeholders that would have benefited from this change were people who are blind.

Because of CAPTCHAs on the White House’s petition site, blind users were not able to sign the petition. While an audio alternative was available, the audio was so muddled that it was incomprehensible. What’s more, to send an email to provide feedback or seek assistance, you also needed to complete a CAPTCHA.

The White House stated that the website was fully compliant with Section 508 of the Vocational Rehabilitation Act

Just like in the case of Bank of America, an alternative was provided, but it was not a workable one.

Incidentally, the petition “failed to meet the signature threshold”.

Accessibility Dilemma

Things are rarely perfect. Decisions taken to improve accessibility may cause problems in other areas. What is accessible for one person may not be accessible for another. What happens when someone uses a guide dog, but one of their co-workers is severely allergic to dogs? Hard surfaces are better for wheelchair users but are often too slippery for cane or crutch users. CAPTCHAs generally reduce accessibility but protect from SPAM – do you do away from that protection?

Which decision is right? Which is wrong? What is just, what is unjust? Sometimes, you have to pick the lesser of two evils, accommodate, and find workarounds. Sometimes a change in policy is required (like the BoA policy requiring thumbprints).

What we must keep in mind, however, is that our decisions often have unintended consequences.

Why Accessibility?

There are legal requirements and commercial incentives to ensuring a website’s accessibility. It’s also the right thing to do. The question of “why web accessibility?” requires a lengthy discussion in and of itself. The following section is a quick overview of these matters.

Legal requirements

While it is not possible to go into details of each jurisdiction in the context of this paper, it is safe to say that there are legal requirements for website accessibility in most of the western world. Some countries have adopted specific web accessibility legislation. Other countries have anti-discrimination legislation that should, in theory, cover web accessibility. Several countries have also adopted standards and guidance to improve accessibility. It is worth investigating the situation in your area, or the legal standing of your clients.

Typically the varying legislations target different types of websites. Government agencies, educational institutions, and commercial entities are the groups most discussed in legislation.

Specific legislation

These are policies that are specifically requiring access to website, or digital communications. Arguably the most obvious example of such legislation is Section 508 of the United States Vocational Rehabilitation Act (§508). §508 requires Federal US Government organizations and agencies to follow specific guidelines to ensure accessibility. Another example is the Accessibility for Ontarians with Disabilities Act 2005 (AODA), which introduced guidelines for website accessibility compliance as of January 2014. Failure to comply with web accessibility rules of the AODA could result in fine of up to CAD$100,000 per day!

Anti-discrimination legislation

The requirement for accessible website can be inferred from anti-discrimination legislation such as the Canadian Human Rights Act, NZ Human Rights Act 1993, the UK Disability Discrimination Act 1995 (UK DDA), the Americans with Disabilities Act 1992 (ADA), or Australia’s Commonwealth Disability Discrimination Act 1992 (Australia DDA). These legislations have a common goal of ensuring equality of opportunity and freedom from discrimination. Most of the anti-discrimination legislation was written before the web was “a thing”, so they don’t specifically address web access.

At an international level, the United Nations has a Convention on the Rights of People with Disabilities (UNCRPD). Many countries including Canada, New Zealand, the United Kingdom and Australia have ratified the UNCRPD. Articles 4, 9, and 21 of the UNCRPD provide explicit requirement for accessible government websites. The United States have not yet ratified the UNCRPD.

Disability rights activists often make the argument that if a business is not allowed to discriminate against a customer on the basis of disability in their “brick & mortar” premises, the same is true of their web presence. The first significant lawsuit for web accessibility on the basis of an anti-discrimination law was a case against the Sydney 2000 Olympics. The plaintiff (Bruce Maguire) claimed that alternative text was not available on most images and the Schedule and Results pages were not accessible. The defendant said that to implement these fixes would cause undue hardship. The court found in favour of the plaintiff and stated that people with disabilities were being discriminated against “by lack of provision”

Another well-known case was settled out of court in 2008. Target was sued by the US National Federation of the Blind (NFB) because their website was not accessible and that the lack of accessibility violated multiple US State and Federal laws. The settlement agreement included payment of US$6,000,000 and implementing website accessibility.

Will you and/or your organisation be sued?

It’s hard to tell. In physical accessibility lawsuits, it’s not uncommon to see the architects and builders as well as the building owners being named as plaintiff. It would not be a surprise if web accessibility lawsuit did similarly and named the designers and developers as well as the site owners in lawsuits.

But the decision of implementing accessibility shouldn’t be made purely on the basis of legal requirement.

Commercial incentives

Numbers

People with disabilities represent 19% of the American population as of 2010. Assuming a conservative 2:1 ratio of family and friends, we can add 38%. This means that potentially 57% of people have knowledge of, interest and desire to use accessible sites.

According to a 2005 study by the Royal Bank of Canada (RBC Financial Group), people with disabilities in Canada wield a combined spending power of $25 billion annually.

62% of people with disabilities say they are more likely to do business with companies that have a commitment to diversity and equal treatment of employees.

73% of people with disabilities are head of household.

The reality

Now that I’ve given you impressive numbers, what’s the real impact on your business? The truth is, nobody knows!

We can’t claim that because 20% of the population has a disability, 20% of your site’s visitors have a disability. It is possible that would be the case, but not necessarily. That said, even if 20% of your visitors had a disability, it does not necessarily mean that their disability would impact their ability to use your website. There are no metrics to determine whether or not a site’s visitor has a disability, nor to tell if a non-accessible website causes barriers because of that disability.

Playing with numbers from the US Census Bureau we can tell that 8.2% of people have a mobility impairment, 4.8% of people have a cognitive impairment, and 3.6% of people are either blind or deaf. People with these types of disabilities are the most likely to require an accessible site. Assuming half of those individuals need an accessible site, we can estimate that about 8% of people actually need an accessible site.

Will your site experience an increase of 8% in revenue / site visits as a direct result of increasing accessibility? Probably not. Can your company afford to miss out on even 1% of increased revenue? Probably not either. Will you ever be able to tell whether or not you gained customers because of increased accessibility? Not likely. In this day and age, every customer counts.

Right thing to do

Businesses and organisations are becoming increasingly aware of their social and ethical responsibilities. Ensuring a barrier-free environment is the right thing to do.

Security Features / Barriers

CAPTCHAs

Completely Automated Public Turing test to tell Computers and Humans, commonly known as CAPTCHAs, are a popular way to reduce the amount of spam submitted via contact, comment, subscription or other online forms.

“It is important to note that, like seemingly every security system that has preceded it, this system can be defeated by those who benefit most from doing so. For example, spammers can pay a programmer to aggregate these images and feed them one by one to a human operator, who could easily verify hundreds of them each hour. The efficacy of visual verification systems is low, and their usefulness is nullified once they are commonly exploited.”W3C – 2005

What most people refer to as CAPTCHA is the display of a garbled image of text or numbers, that a user has to type into a form field. This is only one of several methods, and require user input. This form of CAPTCHA is rarely accessible, even with an audio alternative, and often unusable even by people without disabilities.

The following techniques are ways to avoid relying on user input, or making user input much simpler, while still separating bot entries.

No single way

There is no panacea to combat form spam. Applying a variety of methods at the same time are likely to be more effective than using a single technique.

Check for content

Arguably, the main purpose of a spambot is to deliver spam. The obvious solution is to automatically check for spammy content in the forms!

Honeypot

Most spam scripts tend to complete every field they encounter in a form. With that in mind, you may add a honeypot, or trap, field in your form, then check if something was entered in the field. If something was entered, you reject the submission as spam.

<span  style=”display:none; visibility:hidden”>

<label for=”kamate”>Do not fill in this field. If you enter anything in  this field, your comment will not be sent. This field is used to trap spam.</label>

<input type=”text” id=”kamate” name=”kamate”>

</span>

The css will hide the field from everyone who hasn’t disabled CSS, including most screenreader users. In the event where CSS has been disabled, the label message should be clear enough to avoid most people completing the field.

Form Verification Page

Instead of sending the form data immediately after the user has clicked on the submit button, you may redirect to a data verification page.

Such a 2-step process may annoy some of your users and should be considered in conjunction with the importance of the data being sent. A verification page may resolve compliance issues with WCAG 2.0 success criterion 3.3.4 as discussed later on under “Data Validation”.

Time Limits

Spambots are likely to complete a form much faster than a human would. They may also try and grab the form and get back to it at a later time, in batches. You could insert the time the form was first loaded through a hidden field in the form, then calculate the time difference between that time and the time the form is submitted. You may exclude forms submitted too quickly, or too slowly.

Inserting the time:
<input type="text"  name="timeviewed" value="<?php echo time(); ?>" />
Checking against “timeviewed”:
if($_POST['formtime'] < time()-3600)  {

    $spam=true;

}

Caution

While an hour might be safe for most people completing a form, it is possible that you could end up flagging as spam a genuine user with disability, especially if you have a long or complex form. While this is not technically a session time-out, the effect is similar: The data can’t be sent.

Simple questions

One alternative to the image-based CAPTCHA that seems to be quite popular is the use of simple questions. However, answers are not always obvious.

Most people would answer “blue” to the question about the sky’s colour. But is it light blue at noon, or dark blue at dusk, or midnight blue in the middle of the night? Is it fiery sunset red? Is it light grey because of cloud cover, or dark grey because a storm is brewing?

As for the relative size of an elephant and a mouse, again most people would respond correctly by saying that the elephant is larger. But will they say “yes”, or “yes it is”? Would a non-native English speaker answer in their maternal tongue “oui” or “ja”? What if someone has musophobia (unreasonable and disproportionate fear of mice)? Could their perception of a mouse’s size be so skewed as to make them answer “no”?

As for the third question about which US State is New Zealand in, it’s a bit of a joke, as it wouldn’t likely be something asked as a challenge question to stop spam. Yet, I am amazed at the number of people who have told me they thought New Zealand was near New Jersey. Any geography related question is likely to stump a large proportion of people.

Logic or math puzzles

Another method consists of asking a simple math question.

This seemingly simple question could easily be parsed by a bot. An alternative could be to ask:

Is the answer to this “3” or “three”?

More in line with accessibility issues, even such simple math questions might stump someone who has dyscalculia (between 3% and 6% of the US population). Dyscalculia is a specific learning disability causing difficulties with mathematics.

Are you human?

Here’s one from the realm of “unintended consequences”. Many times, we tell our user something along the lines of “to prove that you are human…”, or “if you are human…”.

On the surface this is a perfectly legitimate question – we are fighting spambots. The problem here can, in fact, be quite serious. Asking someone if they are human may trigger PTSD events in survivors or abuse or torture. Torturers dehumanize their victims by, among other things, asking “are you human?”.

Simply rephrasing the statement or question to “prove you are not a spambot” would avoid this exceptional but very real issue.

Session Time-Out

People with disabilities may require more time to complete some activities, and timed sessions can pose problems.

Unless the time limit is longer than 20 hours, all timed sessions should be able to be turned off, adjusted, or extended, unless it is essential for the activity.

Essential

Timing might be essential to an activity. For example, if you are running an online auction, giving the user the ability to change or extend the timing would denature the outcome. The guidelines grant an exception to the timing requirements in such situations.

Turn off the timing

Provide a means for users to turn off timing on forms. This could be done by providing a button to click or a checkbox to tick. Your form script can look to the checkbox and stop the timer if it has been checked. The checkbox could be placed outside the form itself, to avoid being picked up by spambots.

Adjust the timing

Some processes may go over several pages, like flight or concert tickets reservations. These often have a time limit between each step.

Warn the user at the start of the process “each step is expected to take 1 minute”. Then offer a means to extend that timing. WCAG suggest up to ten times the original amount of time.

  <legend>Would you like to adjust the  time limit?</legend><br></br>
  <input id="1min"  name="min" type="radio" /><br></br>
  <label for="2min">1  minute</label><br></br>
  <input id="2min"  name="min" type="radio" /><br></br>
  <label for="2min">2  minutes</label><br></br>
  <input id="5min"  name="min" type="radio" /><br></br>
  <label for="5min">5  minutes</label><br></br>
  <input id="10min"  name="min" type="radio" /><br></br>
  <label for="10min">10  minutes</label><br></br>

Extend the timing

You may also offer to extend the timing. At least 20 seconds before a page is about to refresh, or a session about to expire, warn the user of what is about to happen and ask them if they need more time. Offer a simple way to extend the time. WCAG suggest “press the space bar”.

Re-authentication

Sessions sometimes time out even if you’ve provided the user with means to stop, adjust or extend timing. Sometimes a user will begin a process on their tablet but opt to finish it from their computer (as an aside, this often happens because a site isn’t working well on mobile platforms!).

Save the data to be used after re-authentication

Make sure the server retains the form data for a logged in user when their session times out. When they log back in, you can present the user with the data and ask them if they wish to continue the process and submit the form.

Encoding user data as hidden or encrypted data

If there are legal restrictions or security implication in saving data to the server, you can inform a user that their session has timed out, give them the opportunity to log back in. The data is passed as hidden and/or encrypted data from the original form.

Data Validation

Data validation normally happens “under the hood”. As such it rarely creates a direct accessibility barrier. But client-side validation should work for both keyboard or mouse users. You also can’t be sure that a user’s browser will support scripting. Don’t depend on script functionality or event handlers to validate the data. Use both an URL action value in the form and client-side validation:

<form action=”checkit.php”  onsubmit=”return checkdata()”>

This would process the script if scripting works, otherwise there is a fall-back.

Guidelines

WCAG 2.0

WCAG are the Web Content Accessibility Guidelines. There are 3 levels of conformance (A, AA, and AAA). There are 4 principles (Perceivable, Operable, Understandable, and Robust). Each principle is broken down into guidelines and success criteria. Each success criterion has associated techniques.

Note, however, that the WCAG are not the be all and end all of web accessibility. They are solid guidelines, but we should beware to rely on them absolutely. Sometimes best practices may conflict with the guidelines (as was the case with Accesskeys, which were part of WCAG 1.0, but were removed from WCAG 2.0). Other times, we can figure out a solution simply by thinking about the possible barriers.

The following are some of the success criteria that are of particular interest and may come at play from a security perspective. I recommend reading their associated techniques.

Online Resources

There are a lot of resources available for developers, but finding the right one can sometimes be difficult.