I went to a talk on accessibility last night by these good people:

Northern User Experience: Accessibility in Practice
http://northern-user-experience.org/2012/01/24/next-leeds-event-monday-27th-february-accessibility-in-practice

There were some really interesting things highlighted, but a key issue for me was to do with the use of auto playing videos.

Users hate auto play

I recently lab-tested a tourist attraction website with a group of their potential customers. The site had several auto playing videos on it, and every test participant expressed a dislike for them.

Regardless of this the client wanted their videos to auto play, so auto play they did.

What hadn’t occurred to me while I was trying in vein to stress that they were “bad usability” was that they are also “bad accessibility“.

Let me explain:

The JAWS screen reader

Visually impaired users will typically use a Windows-based screen reader application called JAWS. There are other screen readers but JAWS has about 75% market share, so it’s as good as the defacto standard.

JAWS reads aloud the active content on a PC screen.

It also has special extensions to add extra functionality within Internet Explorer web browsers, allowing it to interact with elements on a web page in a more advanced manner than simply reading the page contents aloud.

The talk I went to last night highlighted that a typical JAWS user will do the following when landing on a new web page:

1. When the web page has fully loaded the screen reader will read out the page title
2. The user will then make a decision based on this page title:
   • If they think they are on the correct page they will then bring up a dialogue box that lists all the subheadings on the current page – the application starts to read back this list to the user, allowing them to choose one they want to hear more about
   • If they do not think they are on the correct page yet, they will bring up a different dialogue list of all the links on the page, which the application starts to read back to the user

Note that in both instances, the screen reader is speaking back the page’s content – this is critical to understanding why auto play videos are A Very Bad Thing.

Imagine now if that web page has an auto playing video on it, with music, effects and even vocal soundtracks. The user is unable to hear their screen reader because the video is drowning it out.

Also, because the videos are usually written in Flash, the screen reader is unable to guide the user on how to stop the video. This means it’s even worse if the video is set to automatically loop as they have no way of ever stopping it.

I’ve seen this in action and it’s a cacophony of clashing sounds. It’s all the user can do to get off the damn page as quick as possible. It’s a very unpleasant experience and effectively bars the user from ever seeing content on that page.

Lawsuits are expensive as well as bad PR

To underline this, a group of American women recently sued Disney for a bucket-load of cash over various accessibility issues at their parks and on their website, one of which was the use of auto playing videos on their site.

http://www.undpegov.org/taxonomy/term/313

As I understand it, Disney settled out of court without actually fixing the issues on their site, and so the RNIB have since taken up a similar lawsuit against them to try and get the underlying problems addressed.

You’d think that with Disney being a major tourist resort they would be trying to be as “inclusive” as possible wouldn’t you?

Forehead-slapping moments

There were several other forehead-slapping insights from last night’s talk that we should all be listening to as web designers and developers, but this one was especially relevant for me given my recent experiences lab testing a tourist attraction site with auto playing videos.

http://is.gd/elE7y

Fascinating article from @sixrevisions about how proximity/grouping/etc effect #ux

A link went around the office this morning about a Dabbleboard, an online white-board tool.

While the tool itself is nothing out of the ordinary, comments were made about the way they have integrated mouse gestures into the application.

For example, drawing the first part of an oval will cause the app to draw a complete oval, thus negating the need to keep going to the toolbar and selecting the “draw oval” tool.

Doing this:

Draws this:

Neat, huh?

So, gestures: are they the future?

For more experienced users, or in instances where users have been trained to use a system they can certainly boost productivity, but I’d be very wary about unleashing them on the general public, where they may fall into the hands of novice users.

For example, I have “active screen corners” set up on my Macbook: when I move the cursor to the top-right of my screen it reveals the desktop, the bottom-left shows all active windows and the bottom-right shows the dashboard in all it’s widgety glory.

Configuring active screen corners:

Showing all active windows:

I find this setup allows me to navigate through my open applications and my dashboard widgets quickly and easily. I’ve been using that setup for so long it actually feels restrictive when I’m on a computer that doesn’t run like that. It’s become instinctive. For me.

However, when my wife tries to use my laptop she gets herself into a bit of a muddle with it: windows whizz around & disappear seemingly at random and she doesn’t understand why it’s happening. She used to think she had done something wring, or worse that she had “broken it”, but after explaining to her what’s happening and why, she now asks me “how can you work like that?”.

The gestures are a very personal preference, and while they make perfect sense to me, for her they create make the user experience a frustrating one, and longer sessions usually result in her proclaiming how much she hates Macs.

It’s a fine line between a feature that aids productivity and one that is unpredictable, unintuitive or so twitchy it just gets in the way.

For experienced or trained users, gestures can be a great productivity enhancement, just make sure they’re appropriate for your users, that it’s obvious they’re enabled and that their effects are clearly sign-posted!

And having said all that, I admit I’ve never quite got my head around Opera’s mouse gestures. They’re weird, and it feels like they fight against the natural shortcuts within the O/S.

Maybe I need a training course in how to use them?

http://is.gd/9AK6Y

Includes overview and links to tools, resources & reading material

#ux

http://is.gd/5c4iR via @sixrevisions

#ux #accessibility

One of the most interesting things about the article is the video footage of people using the JAWS screen reading software.

Typically, when we think about website accessibility we tend to focus on providing assistance for the visually impaired. However, the users in this BBC article demonstrate a number of different forms of disability, including visual impairment, dyslexia, cognitive problems and RSI-like motor dysfunction.

The article’s videos serve as a useful reminder that there are other types of disabilities we need to be considering. They also demonstrate some practical considerations for designers and developers to make the most out of the JAWS software.

Article extract:

The World Wide Web Consortium (W3C) has announced a new standard to make sites more accessible to older and disabled people.

Version 2.0 of the Web Content Accessibility Guidelines (WCAG) will apply to text, images, audio and video.

It also covers web applications and is said to give developers more flexibility than the old guidelines.

According to the consortium, WCAG 2.0 should also be easier to understand and use

Full article here: http://news.bbc.co.uk/1/hi/technology/7789622.stm

Complying with accessibility guidelines can seem like a massive undertaking. However, addressing 5 simple problems can make a huge difference to your site’s accessibility.

Essentially these are:

• poorly described images
• badly labelled links
• no alternatives to media
• reliance on javascript
• user controlled text

The article outlines quick fixes that it claims addressed 80% of issues.

These might seem like pretty basic fixes, and any web UI developer worth their salt will have been working within these parameters for years, but sometimes its worth reminding yourself of why you do the things you do…

(Source: http://boagworld.com/accessibility/quick_fix_accessibility/)