Posts Tagged ‘surveys’

Online surveys – top 10 assumptions to avoid

Tuesday, February 9th, 2010

When considering some of the recent online surveys that I’ve seen or been involved in setting up, I’m reminded of the saying:

Never assume. It makes an ass of u and me.

Anon

It may be hackneyed, but it does ring true for many of the observations I’ve made around surveys. Here’s my list of the 10 most common assumptions to avoid when conducting an online survey.

See the top 10 assumptions to avoid

Don’t just sit there – debate!

Wednesday, March 25th, 2009

I love argument, I love debate. I don’t expect anyone just to sit there and agree with me, that’s not their job.

Margaret Thatcher

Debate and discussion are vital to the progress and development of web accessibility. With that in mind it’s great to see that, as ever, there is plenty of discussion going on out there in the fora, blogs and Tweets of those interested in the subject.
(more…)

Screen Reader Survey results

Monday, February 2nd, 2009

WebAIM have recently published the results of their Survey of Screen Reader user preferences. There’s already been a lot of coverage of the results, but I’ve summed up a few keys points that I found particularly interesting.

Summary of respondents

  • 1121 responses
  • 90% of respondents were full-time Screen Reader (SR) users
  • 58% considered themselves expert or advanced SR users
  • 74% use JAWS, 23% Windows Eyes, 8% NVDA, 6% Voice Over

Some key points

First visit to a page

35% of respondents tend to navigate through or listen to the links on a new page, whilst 46% read through whole the page. The latter tended to be the behaviour of more proficient users, who will usually have their verbosity and read speed settings cranked up to make page reading a lot faster.

Skip links

Only 22% of respondents always use Skip Links, where available. 10% claimed they never use them. Regarding the naming of Skip Links, 22% preferred ‘Skip to Content’, 28% preferred ‘Skip to Main Content’, whilst only 6% liked ‘Skip Navigation’. This would seem to be a very useful finding.

Headings

An important one, this. 52% said they always use Headings to navigate a page, whilst 24% do so often. Also, the more proficient the user was, the more likely they were to use Headings in this way. This underlines the importance of correctly structuring your pages with Headings.

Search

As you’d imagine, over half of the respondents like to use Search, where available. Again this underlines the importance of making any Search function usable and relevant.

Pop-up windows

A mixed response to this one, with 25% saying they found pop-ups very difficult to handle, whilst 17% said they were not at all difficult. This could be clearly linked to the users’ proficiency, so whilst it may not affect the experts, avoiding pop-ups will greatly help the less proficient users.

Identification of photos

Quite a big surprise… 80% would prefer the alt description “Photo of the White House” over just “The White House”. This contradicts the assumption that we should always keep things as short as possible. Important to note that we may not be able to say the same of other such situations (i.e. other types of graphics).

Flash

No great surprise to see that 71% of users found Flash content somewhat difficult or very difficult to access. There are some very accessible implementations of Flash out there, but generally content presented in Flash will cause problems. This was apparently backed up by many strong comments from respondents about the inaccessibility of Flash.

Conclusion

The overall conclusion drawn by WebAIM was that all SR users are unique in their use of the technologies and how they interact with web content. We can make assumptions, informed by research and user testing such as this, but ultimately there will never be a 100% ideal solution. Conforming to international standards, and getting rid of the obvious barriers, are just the first steps to making your content truly accessible to SR users.

Screen Reader survey

Saturday, December 20th, 2008

WebAIM are conducting a survey of the preferences of Screen Reader users.

“If you are a full-time, part-time, or even occasional screen reader user, please take a few minutes to complete the survey and provide us with a few details on your screen reader usage and preferences…. The results of the survey will be made public in a few months. We believe the results will be very useful to those who are developing accessible web content.”

The results could be very enlightening, and I’d hope that anyone in a position to reply would do so to help inform best practices in designing websites sympathetic to the needs of these users.

I’ll be sure to report the release of the results in the new year, so watch this space or head over to WebAIM to get it from the horse’s mouth!

Survey Monkey useful features

Thursday, December 18th, 2008

I’ve been using Survey Monkey within my organisation for two months now (see my original post about its accessibility, which I’m still looking into). I must say I’ve been very impressed by the customer service – I’ve had a few questions which the (generally excellent) help section has been unable to help me with (mainly because contact with a person was necessary), and they’ve always been quick to respond.

I thought I’d mention a couple of things I’ve done since taking over the account. The lessons learned apply to any similar function, not just Survey Monkey.

SSL enabled

Firstly, I was surprised to see that the account did not have SSL enabled. This costs just $100 extra a year which, for a organisation such as mine, is peanuts. Compare that with the disasters that could await if not using a secure protocol and it’s a no-brainer. Sadly this only really came to my attention when I heard about a survey we’d run to gather parent’s opinions on school buildings. A local parent council blog had flagged up the potential security risk, and quite rightly so. We were asking for a few personal details, although to be fair these were not mandatory. Even so, those unaware of the difference between http and https may not have appreciated the risks (however small) and that’s not really on. Needless to say we’ve now upgraded, so people’s response are collected securely at their end and the results are downloaded securely at this end.

Friendly URLs

Secondly, a nice “courtesy feature”* is the ability to request friendly URLs. So instead of the usual string of alpha-numeric characters you can get something that actually makes sense (e.g. www.surveymonkey.com/mysurvey). This is really useful, especially if there’s a chance that people may need to type in the address, or if you want to refer to it in print. To underline the great customer service, I requested one to be set up and it took just a couple of hours.

Something to be aware of, if also using SSL, is that your users will need to include the https:// at the start of the URL. If they just type in from the www… they’ll get directed to the insecure version. Survey Monkey does not offer the ability to always redirect to the secure version, which they say is for the benefit of any systems that can not access the secure pages.

*Presumably a “courtesy feature” is something they’ll probably do, but aren’t obligated to. Hopefully, then, they’ll continue to offer this (and for free).

Loop to start

You’ve got various options for where to direct the user on completion of the survey (i.e. to a thank you page, another website, or even close the window). Another option, though, is to loop the user back to the start of the survey. This function has proved useful recently when we used Survey Monkey as the basis for an audit. Each auditor would typically be looking at 5 or more things, each requiring a unique response, so once one audit was complete they’d be going straight back into the survey to do another. The ‘loop to start’ function was, obviously, the perfect solution for this.

Invitations by e-mail

A tremendously useful feature is the ability to set up Survey Monkey to e-mail a list of recipients with an invitation to complete your survey. Each recipient gets a unique URL, enabling the system to track who has and hasn’t responded. This then means that you can easily send reminders targeted only at those who are yet to respond.

I thought it worth mentioning this function in the privacy statement that I am developing to accompany any surveys, and accordingly included this on the front page of the survey:

If you arrived at this survey via an e-mail invitation, it will be possible for us to link your answers with your e-mail address. Any information you provide will be kept secure and only used for evaluating the results of the survey.

UK accessibility survey

Wednesday, October 22nd, 2008

A UK taskforce of charities and associations has launched a survey to find out about ICT Accessibility awareness and practices.

The initial aim is to produce an ICT Accessibility Business Case with case studies and implementation plan, followed by other potential tools and information, to help companies plan and incorporate ICT accessibility. The business case is expected to be published in March 2009.

The survey is open until 1st November, and participants can opt in to receive the survey results and final business case once published. No previous knowledge of accessibility is required.

Find the survey at http://cs.createsurvey.com/c/45/45/survey/507-Z0TuTA.html

The taskforce is made up of the following organisations:

  • AbilityNet
  • British Computer Society (BCS)
  • City University
  • Employer’s Forum on Disability (EFD)
  • Intellect UK – Representing the UK Technology Industry
  • Leonard Cheshire Disability
  • Radar – The Disability Network
  • Society of Information Technology Management (SOCITM)
  • Worshipful Company of Information Technologists (WCIT)

Survey Monkey accessibility

Thursday, October 16th, 2008

I’ve been approached to take on some responsibilities for my organisation’s Survey Monkey account. Survey Monkey claims that it has a single purpose: “to enable anyone to create professional online surveys quickly and easily”. We use it for internal and external consultations, as a 3rd party alternative to the clunky CMS which is currently running our corporate sites.

The first thing I was keen to establish was whether Survey Monkey was accessible. If we’re using it for important Council consultations and some of our users face barriers in completing the survey then we, quite rightly, risk claims of discrimination. Moreover, if the surveys are poor in terms of usability, the response rate is likely to suffer.

My first port of call was Survey Monkey itself, which had the following to say:

Your SurveyMonkey survey designs are now Section 508 compliant and accessible!

SurveyMonkey is now the only online survey application whose surveys are Section 508 Certified. We ensure that by using our standard survey designs, your survey will meet all current US Federal Section 508 certification guidelines. Our developers have updated our SurveyMonkey survey design system across the board in all accounts. All standard survey designs are accessible and 508 certified and compliant for respondents with disabilities. This has all been accomplished without changing the appealing look or function of your survey.

  • You do not need to add any special settings or change anything within your survey design.
  • If you are using a standard survey theme in your survey design, it is automatically 508 compliant.

This seems quite encouraging. However, compliance to Section 508 does not inherently mean complete accessibility, and is also not a legal benchmark here in the UK.

I next came across a Survey of Survey Tools done by the Web Accessibility Centre at the Ohio State University, looking at the accessibility of six of the top survey tools. This identifies a few issues which it suggests have not been solved by the recent efforts to comply with Section 508.

The overall grade given to Survey Monkey in this survey was B, meaning the majority of it was accessible. Problem areas included accessibility for sighted keyboard users, especially when in Windows’ High-Contrast mode. It was also found that a keyboard user would not be able to navigate as an administrator. This means we could risk discriminating against our own staff as well as the end user.

I now intend to carry out some direct testing, and will publish the results here when that is complete.