Categories
jobs mobile testing

Accessibility Jobs, Sept 2014

Categories
design disability mobile

Vestibular Issues in Parallax Design

Over the last year or so, a design trend in the web and mobile world has been transition animations, parallax effects, and the like. For many users, this can cause vestibular issues; the symptom is usually vertigo, or a feeling of motion sickness.

The issue was not well recognized until iOS 7 was released and overwhelmed users with an excessive amount of visual effects, especially parallax. Numerous articles were written about this issue, including iOS 7 and motion sickness by iMore. In a poll displayed on that article, about 28% of users reported having either mild or serious motion sickness with iOS7; this is not a formal study but still makes quite a statement. And at the time of writing, there are 100 comments on the article!

Pro tip! To reduce the parallax effect in iOS 7, go to Settings > General > Accessibility > Reduce Motion.

Pros and Cons

study by Purdue University found that “although parallax scrolling enhanced certain aspects of the user experience, it did not necessarily improve the overall user experience”. Let’s take a look of pros and cons of parallax design.

Pros:

  1. May possibly increase user engagement.

Cons:

  1. Makes many users sick.
  2. Requires additional code which makes web pages more complex longer to load.
  3. Does not function smoothly across all browsers.
  4. Difficult to implement with responsive and mobile design.
  5. Can make it difficult or frustrating for the user to consume content due to excessive scrolling.

Recommendation

There are obviously many more negative points for using parallax design as there are positive. My recommendations are:

  • Use parallax effects (and animations) with much discretion and tolerance, if at all.
  • Ensure complete browser testing on desktop as well as mobile devices.

UPDATE: The CSS Reduced Motion Media Query can now be used to turn off (or reduce) animation and motion effects when a user has the setting on in the user agent, if supported.

Related Articles

Related Tweets

Categories
design forms links

Proper Use of Buttons and Links

After years of arguing for proper use of form elements and link elements, others are finally doing the same. More recently, this includes the articles The Anchor Button: Bad for Accessibility, Bad for Usability by Matt Long and Reinventing the hyperlink (with much humor!) by Heydon Pickering.

The main point is, please do the basics. When designing a website, ensure controls with button-type behavior (submitting form and opening a modal dialog) are designed as buttons and regular text links (go to an external page, anchor on page, or external document) are designed like text links (such as blue underlined text).

When developing a website, ensure buttons are coded as buttons (the button or input element) and links are coded as links (the anchor element). You could also use ARIA roles to denote button and link, but it’s always better to use the semantic HTML elements.

Here are some reasons why it’s so important:

  • accessibility and usability
    • provides user with expectation of the control’s behavior
    • avoid conflicts with voice-control user agents (speech recognition software) such as Dragon NaturallySpeaking
  • a more robust website (support older user agents, non-JS, etc.)
  • lighter and less complex code
  • more consistent implementation so easier to maintain

Remember that for accessibility, no matter how much ARIA and trickery is done, there will mostly likely still be problems. When blurring the distinction between a button and a link, assistive technology (and/or the user) can be confused as to what’s what. View the beginning of this presentation by Derek Featherstone for a good example of this.

This is a button; this is a text link; don't mix them up.
Button versus text link.

This advice sounds simple, but this elementary guideline is broken quite often; once you start to look, you’ll find it everywhere on the web, especially web apps. There’s no need to create confusion (the design) and to re-invent the wheel (the development). Sticking to the basics will make it easier for everyone, most importantly the user.

For an example of proper implementation, check out Easy Chirp.

Further reading:

Addendum:

Last updated April 2023.

Categories
apple jobs yahoo

Web Accessibility Jobs, July 2014

Wanted (all in U.S.):

To learn of new positions, remember to follow me (@webaxe), @accessible_jobs and @a11yJobs on Twitter!

Categories
conference presentations review

Open Web Camp 6 – a brief review

Recently I attended Open Web Camp 6 (@OpenWebCamp) at the beautiful PayPal headquarters in sunny San Jose, California. Like every year, the event is coordinated by @JohnFoliot. If you want to review the Twitter feed, the hash tag is #OWC6.

Like last year, the cost of the event was only $10, and attendees get a nice lunch, a t-shirt, and some other swag. The networking was good and the energy was great!

Featherstone standing in front of a projected slide
Derek Featherstone presenting at OWC6

There was a variety of topics but accessibility was the most prominent. Here are the highlights:

  • Derek Featherstone (@feather) presented Accessible Design: Which “everyone” do you mean? where he discussed accessibility challenges for users of assistive technology such as voice recognition and screen magnifiers.
  • Dylan Wilbanks (@dylanw) presented a thought-provoking session Meditations on making fire-proof, failure-proof, future-proof things.
  • Dirk @Ginader presented Teach your Browser new tricks where he discusses longdesc and browser extensions.
  • @KarlGroves spoke about accessibility testing and his app Tenon.
  • The Twitter talk “Connecting to the pulse of the planet” was disappointing. It was much more of a 25-minute sales pitch than a tech talk.

All in all, it was another successful web event. Hoping for an OWC7!

Factoid: I’ve attended every OWC event since its inception at the first Open Web Camp at Stanford, and spoke about the then newly created @EasyChirp (then called Accessible Twitter).