Accessibility and user experience are not black and white. Here we take a look at some shades of grey, and user scenarios that we need to take into account when we’re testing web sites and applications. We need to test for correct cases, incorrect cases, and moving efficiently from the incorrect state to the correct state.

We often see code like this in web applications that we’re evaluating for accessibility and usability:




What does this code do when it’s used in a form field? Why is it there in the first place?

It is mostly used to clear out “default input” that is already in a form field.

Here is an example: Click or Tab to place the cursor in the field. Then type something into it. Then Tab away from the field to the Go button. Then Shift+Tab back to the field.

What’s wrong with this picture?

Yes, I know. It is just bad code. You can get around this partially by improving the JavaScript. Something like:

onclick="if (this.value==this.defaultValue) this.value=''"

That way the JavaScript only clears the field if the defaultValue is in the field still. You could also use HTML5’s placeholder attribute, with some fallbacks for those browsers that don’t support @placeholder yet.

And, yes, I know that if you’re reading this, you’d never use code that indiscriminately removes whatever input is in the field. But someone out there did and does, because we see it in apps we’re testing all the time.

Why do we build things like this?

I can’t say for certain that this is always the case, but I think part of the reason we see it often is because people consider only two cases when they’re coding, or unit testing or doing Quality Assurance testing on a web site or application. Or it was done in a hurry. Or it was copied and pasted in haste from a bad tutorial site somewhere and nobody caught it when testing. The problem here is that this code indiscriminately clears the data out of the field, even in cases when you don’t want it to. It assumes that if there is *any* data in the field at all, that it should be cleared out.

How this relates to testing

There are two basic cases most people would test for (in acceptance or Quality Assurance testing, for example). The correct case and incorrect case.

The correct case: with a default value in the field, the user would place the focus in the field, the default would disappear and they’d enter some correct data in a field and submit the form.

The incorrect case: with a default value in the field, the user would place the focus in the field, enter some incorrect data in the field and submit the form.

A QA tester would look at the results of the form submission and determine that the system responded appropriately or not. Tests complete. They might even test that the form has a label.

But user experience, and certainly accessibility, need to take into account many different scenarios. Not just a simple “the user entered information correctly” or “the user entered information incorrectly.” To understand the full impact of this code faux pas on user experience, we have to understand a bit more about how people with disabilities use the web, and we need to look not just at the “correct” or “incorrect” case, but the “correction” case where the user enters incorrect information, realizes they’ve made a mistake, or needs to check to see if they made a mistake before they submit the form. Here are a few scenarios:

Typing difficulties

Javed enters a phone number with the correct number of digits, but mistypes. He needs to correct only the second last digit of the phone number as the rest of the digits are right.

A person that has difficulty typing—whether they’re using their hands, a mouth or head wand or some other device—might take a significant amount of time to enter a phone number into a field. How frustrated do you think Javed might feel when he encounters this type of script? Picture this: it takes Javed 30 seconds to type a phone number—something that you might type in less than 2 seconds.

And when he tabs or clicks into the field to fix that one digit, that JavaScript takes away all the digits that it took him 30 seconds to type. Now, he needs to start over.

Voice recognition software

Susanna’s browser auto-filled her phone number correctly but in the wrong field. It auto-filled her mobile phone number into the work phone field, and her work phone number into the mobile field. She needs to swap the numbers, even though both numbers meet the required pattern for phone numbers.

She tells her voice recognition software to focus on the phone number field for her mobile phone number and intends to tell her software to “select that” and “cut that” so she can move to the work phone number field and paste the phone number in there. And what happens when she uses the software to focus on the field? Her data disappears and she has to enter it again using her auto-fill which is may get it wrong again, or she has to dictate it—more work than she would have had to do with a simple cut and paste.

Using a screen reader

Latosha types her phone number into the field, but she doesn’t know if it is correct or incorrect until she double checks with her screen reader.

Think about Latosha. She types her phone number into the field, leaves the field to fill out more of the form, and then comes back to the phone number field to double check and suddenly her data is gone. Latosha can type quickly, but now she’s confused. A form field she thought she had filled in is now blank. What does that mean? Is there another phone number field to be filled in that she missed the first time around? Is this a different form on the same page? Is this even the same page?

Transitional cases

Let’s be clear: every single one of these issues is a usability issue that would affect all of us. But, they are issues that have a much more significant impact on people with disabilities than they would on people without.

These are all “transitional cases” that need to be tested and accounted for in an application’s design. You can’t simply design or test for the correct case (“the user entered information in the right format”) and the incorrect (“the user entered incorrect data”) case and be done with it. You must test for the transition from the incorrect state to the correct state.

We’ve only described three cases where we don’t want to automatically clear out data that is in the field. There are countless others.

But you don’t need to count them. You just need to know that you almost never, ever want to use this line of code in your app:


And if you test for the ability to check your work, or make corrections with Javed, Susanna and Latosha in mind you’ll catch it.

Next actions

  • Examine your apps for code that removes data from fields. If you find it, it’s time to have that difficult conversation with your manager, or colleagues. You need to revisit this with them.
  • The next time you’re wireframing, designing, creating user stories or test cases, use these descriptions above to make sure that you’re not creating something that is less usable than it should be.
  • Make sure that when you’re testing your applications you’re not just testing to see if the application recognizes correct and incorrect input. Test to see how easy or difficult it is to move from the incorrect state to the correct state.

2 thoughts on “Accessibility testing: correction scenarios”

Read comments

  1. Nancy Johnson says:

    The scenario I’ve run across is that the design comes and is approved by the client with a search input box at the top of each page. Inside the search input is the word “Search”. I cannot change the design.

    I use the simple onclick js code mentioned above that is not good, I do not use onfocus here. We are supporting IE7 and IE8.

    Not being an expert in javascript, is there a better way to code this? Thank you.

    1. Nancy – we outlined a few options in the following paragraph:

      onclick="if (this.value!=this.defaultValue) this.value=''"

      is definitely an improvement.

      You could also use the @placeholder attribute available in HTML5, with a fallback for browsers that don’t yet support @placeholder.

Hi there! We've closed the comments after a week of spirited discussion on this post. If there's something we've missed, please reach out and let us know.