Survey researchers take special care to ensure the instruments they develop are valid measures of what they aim to study, as well as being designed in an easy-to-follow format which minimizes burden and non-response in any mode. In recent years, technological advancement has enabled us to explore the web as a new mode for questionnaire design and administration. By using the web to administer questionnaires, survey professionals have often reduced not only some production costs (associated with labor for administration or entry), but also reduced respondent burden by offering another choice for mode of completion. Many publications have addressed web survey issues such as: who responds, when they respond, and whether there are differences in data quality between the web and other modes of administration. However, very little literature exists discussing how survey professionals can construct web surveys which follow the principles of Universal Design (UD), and are, therefore, fully accessible to a broad spectrum of people.

UD in web surveys takes into account how respondents engage with their computers when they do not receive directives or cues in a visual way through the pages. It also addresses the needs of respondents who do not use a mouse to navigate the screens. Research has shown the state of website accessibility, broadly, is in dire need for improvement (Nomensa 2006). For example, in 2006, the United Nations commissioned a study which entailed a global audit of five key sectors of websites used in daily life, including: travel, finance, media, politics, and retail. The study found 97 percent of the websites tested from 20 countries did not comply with basic accessibility regulations, despite disability legislation existing for over half a decade (Nomensa 2006). These findings have implications for survey researchers administering surveys on the web. While it may not be possible to assume websites and web surveys are equally inaccessible, it is important to consider three key issues. First, web surveys can be embedded within a website which itself may have accessibility barriers. Second, programmers who program websites may also be responsible for the design of web surveys and share a knowledge base. These groups may have had limited exposures to UD concepts. Lastly, survey researchers may not be considering respondent burden or unit non-response from a UD perspective, as evidenced by the dearth of literature discussing the use and features of UD in web surveys.

Why Use Universal Design (UD) in Web Surveys?

Minimizing unit non-response is a critical issue in high quality survey research, as it improves our ability to generalize the findings. Even among the population of digitally literate people with access to the web, opportunity exists for significant non-response bias stemming from programming techniques. When we do not use Universal Design (UD) in web survey programming, we impede the participation of distinct segments of the computer-using population and increase the likelihood of unit non-response bias. These populations include users of either antiquated or cutting-edge technologies, as well as persons with disabilities. Having a disability does not preclude someone from accessing the web, though it may impact navigation. Examples include: people with mobility disabilities who may not be able to use a mouse and navigate a questionnaire via keyboard functions alone; people with cognitive disabilities who may have difficulty navigating complex layouts, or be unable to complete tasks within a predetermined amount of time; and people with a visual impairment who may use a screen reader or may increase the font size on their screens. Other issues can also prevent those without disabilities from participating in web surveys, including: users having antiquated machines or slow internet connections (difficulty downloading image-heavy designs or complex layouts); those with older browsers; and those using new technologies such as: smartphones, Personal Digital Assistants (PDA’s), and other hand-held devices. Following UD strategies enables potential respondents to use a wide range of technologies to participate in web surveys and these users span the socio-economic spectrum. This paper fills a gap in the web survey literature and presents practical strategies for using UD in the programming of web surveys.

Applying Universal Design in Web Survey Programming

The goal for a universally designed web survey is for it to be “usable” by all users, regardless of ability and situation (Clark 2003). This entails a blend of three components: 1) properly crafted HTML forms; 2) the capacity to interface with assistive technology (AT); and 3) adherence to governing standards. Each is described below.

1. Properly Crafted HTML Forms. Respondents experience web surveys as a series of HTML forms where they interface with the design and provide responses. Forms are the foundation for all the interaction between the respondent, the instrument, and the data collected. However, sometimes the design of these forms is inaccessible to some groups of users when forms:

Contain elements such as images or movies that a screen reader cannot interpret or convey to the user.

Contain a graphical logo or a diagram which does not have accompanying text to communicate what was being expressed.

Cannot be navigated via keyboard alone.

Do not have labels and identifiers attached to specific fields of response categories, so respondents cannot determine which question matches which response field.

Expect a timed response, where the page forwards or the form itself expires after an allotted amount of time has passed.

Performs an action without the respondent explicitly telling the page to do so.

Programmers use several techniques to add sophistication to their solid HTML forms, including: Cascading Style Sheets (CSS), client-side scripting languages (such as JavaScript), and server-side languages (exp. PHP, Perl, and ASP). These techniques are also applied in web surveys. Examples include:

CSS stylize the HTML forms to be more attractive.

Client-side scripting allows for the manipulation of forms and input data (ex. JavaScript used to verify range checks or critical items were not left blank).

Server-side languages which can run more sophisticated input checks (ex. checking that an email address is valid) or server-related tasks (ex. sending email receipts).

Developers can both enhance the survey experience and follow principles of UD by using CSS to separate the styling from the content. Understanding HTML (XHTML) forms and form interaction to an expertise eliminates the need to create complex layouts, scripting, or other add-ons. As a result, respondents will experience the web forms as “intuitive and easy-to-use.” Appendix A describes how these forms, the AT, and UD standards apply in several features common to web surveys.

2. Interface with Assistive Technology (AT). A universal design approach to programming promotes the inclusion of users of AT, as recent technological advances have enabled access to the web to people who are blind or visually impaired. Examples include:

  • Screen Readers. A software program that reads contents of a screen aloud to a user, presenting “a two-dimensional graphical web page to a user who is vision impaired as a one-dimensional stream of characters, either spoken or displayed in Braille” (Thatcher et al. 2002, p. 54).
  • Voice Browsers. A web browser which presents an interactive voice-user interface, presenting information aurally, using pre-recorded audio file playback or using text-to-speech software by obtaining information using speech recognition and keypad entry.
  • Screen Magnification. Interfaces with a computer’s graphical output to present enlarged screen content (typically between 1.5x to 32x). (Thatcher et al. 2002).

Older respondents who have digital literacy and access to computers (e.g. aging baby boomers) may be more likely to utilize screen magnification or screen readers as they participate in web surveys. This demographic may not consider themselves “people with disabilities,” but may interact technologically in similar ways to those with disabilities.

3. Governing Standards and Organizations. Advocacy organizations are attempting to bridge the gap between those who design and construct HTML forms and those who use these forms with the help of AT. One such organization is the World Wide Web Consortium (W3.org/WAI), which launched the global “Web Accessibility Initiative” (WAI). It develops resources to help make the Web accessible to people with disabilities and leads the effort to create standards and guidelines for programmers. Governments are also responding to this need. United States legislators incorporated Section 508 as an amendment to the Rehabilitation Act of 1973 to eliminate barriers in information technology, to increase opportunities for people with disabilities, and to encourage development of technologies to achieve these goals.

These three guidelines provide the foundation for all UD web survey construction. The next section discusses how to incorporate UD standards into web survey testing.

Universal Design and Web Survey Testing

It is standard practice to test web survey instruments to ensure they follow programming specifications. Survey researchers can also easily incorporate adherence to UD standards in the testing process in several ways, including: testers using AT or technological devices such as PDAs, testing on slow dial-up connections, and using different web browsers to access the survey. Microsoft’s “Explorer” is among the most popular web browsers and is heavily connected to assistive technologies like JAWS. However, the “Firefox” browser offers an architecture that allows user-developed extensions to the browser. For example, the “Web Developer” extension allows testers to view a web survey in different modes, such as: images turned off, CSS disabled, and deprecated elements highlighted. It also allows users to validate forms against standards. Firefox’s “Firebug” extension allows programmers to debug forms more easily, as well as see the connections between the CSS styling, JavaScript scripting, and the actual web form. Using any browser, it is also ideal to test the following conditions: style sheets and images are disabled; without javascript; without the use of a mouse (i.e. keyboard only); text size set to very large and with screen size very small or very large; use of an alternative stylesheet (high contrast, large text); and with screen reader AT. There are also online tools available for testing accessibility of a web survey or site, including: Cynthia Says, LIFT, WAVE, and WebXact. They run automated tests, evaluate accessibility, and output possible errors or areas of improvement. However, they should always be used in conjunction with hands-on testing simulating the users’ experience as closely as possible, as no one tool can ensure accessibility.

Conclusions

As technology evolves and the computer-literate population diversifies, survey researchers must approach web survey design considering the many possible ways respondents can access a web survey. Programmers must follow guidelines set forth by the World Wide Web Consortium to ensure the forms interface successfully with AT. Failure to take these steps results in inaccessible forms, which may have a negative impact on response, even among digitally literate people with access to the web.

Programmers have made great strides to correct mistakes made in the past, where many forms were built without regard for usability or accessibility. A push for standards by web users, developers, and browser developers has helped to bring the technology to where it is today. With the sudden rush of new technologies (from the Web 2.0 revolution), developers may not have learned from the mistakes of the past, as many new technologies (such as AJAX, and heavy uses of JavaScript) have been brought into production with seemingly no regard as to UD and compatibility with AT. While survey researchers and programmers have an opportunity to make web surveys more dynamic and interactive, they also shoulder a responsibility to create a virtual space that is accessible for all.

Appendix

Appendix A  Accessible design issues in common elements of web surveys.
Feature Challenge to UD Applying UD Method

Sophisticated Layout/Use of Color
  • While visually appealing, layout may be based on illogical markup.
  • Color is not recognized as emphasis for screen readers.
  • Use “well formed” markup to code the form, using CSS to handle layout.
  • Avoid using tables if possible.
  • Use a combination of color, shading, font style and decoration to communicate.

Grid or Table Layout for Scaled items
  • Using tables for layout mixes content with layout.
  • Without labels, users won’t know which response category an option links to in the table.
  • Separate content from layout but coding the form in unstyled HTML and add separate CSS to style it.

Hyperlinks
  • Using link text like “click here,” “more info,” and “next” can confuse screen reader users who need the link text to describe what it is linking to.
  • Use descriptive text, clearly expressing where the link leads.
  • For added information, use the TITLE tag to embed even more information.

Pop-ups
  • Can interfere with screen readers’ ability to interpret a form.
  • An unannounced change in focus of respondent can be confusing.
  • Find another way to communicate the message communicated by the pop-up.
  • If you must use it, announce that the action results in a pop-up window.

Navigation Process
  • User unable to easily tab through survey in logical order because the HTML form is not well-formed.
  • Labels are not logically placed near the inputs.
  • Without page headers, sequence or location in the instrument will be difficult.
  • Mark-up the HTML form to work without the use of tables or CSS.
  • Validate against a W3C standard then add styling with CSS.
Appendix B  Technical guidelines for programming accessible web surveys.

Mark-Up
  • Use xHTML and CSS to separate content from style.
  • Use proper mark-up for form elements.
  • Organize pages in a logical manner, meaning they will read correctly, top-to-bottom, without CSS styling.
  • Use headings (<h1>, <h2>, etc.) and fieldsets and legends to organize forms.
  • Use a logical tabbing order.
  • Do not use deprecated tags like <font>, <b>, <i>.
  • Use tables only for displaying tabular data (with rare exceptions). General page layouts will be done with CSS.
  • All pages will have unique and meaningful title tags. Standard format will be “page name [or survey title], name of site.”
  • Use text in place of images when possible.
  • Use <abbr> and <acronym> elements when appropriate. Use the title attribute to define the abbreviations and acronyms.
  • Use<fieldset> and <label> elements for forms.

CSS
  • Try to not rely on “classes” too much. Rather, write your stylesheet to format tags within a specified <div>. Also avoid using <span> tags.
  • Avoid “div soup,” which is when you overuse divs or have many nested divs.
  • Do not rely on browser-specific hacks. A few might be necessary, such as the @import hack to prevent NS4 from using CSS, but don’t write separate styles for separate browsers.
  • The majority of measurements within pages will be done with “em” or “%”. Control fonts with CSS keywords (small, x-small, etc.). Use pixels only with images and related items.

Design
  • Pages will be designed to use a “liquid design” technique. This means a technique that does not rely on fixed sizes. Users can resize windows, view the site on small screens, and increase or decrease fonts without breaking the design.
  • A design does not need to look perfect in an unsupported browser, but it does have to “degrade gracefully” and still look logical and usable.
  • Use contrast between foreground and background colors.
  • Use client-side scripting (JavaScript, ECMAscript) sparingly. No page should require client-side scripting to be usable.

Content
  • Avoid contextually meaningless link text, like “Click Here”, “Learn More”, or “Go”.
  • Links should describe the destination page/resource.
  • Use title attributes to provide additional contextual meaning for links.
  • For the sake of screen readers, avoid combining two words into one, such as “homepage”. Instead you would use “home page”.
  • Make it short. Design navigation with the least amount of steps and clicks.

Best Practices
  • Layout the form in a logical way in that additional ‘tabindexes’ are required in a minimum. Tab order should be naturally in the correct order. “Skip to content” could replace a complicated behind-the-scenes tab ordering scheme.
  • Avoid using scripting if possible; if not possible, allow form to operate if scripting is turned off.
  • Use labels and id’s to connect form elements to their labels.
  • If possible avoid use of access keys due to conflicting use with AT products.
  • Avoid using javascript at all to make dropdowns have actions. Keyboard-only users cannot navigate the dropdown without inadvertently selecting an option and invoking that option’s action.