E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 2 (In chronological order)

From: Birkir R. Gunnarsson
Date: Sun, May 26 2013 6:27PM
Subject: "next" and "previous" steps in a user interaction, link or button?
No previous message | Next message →

Hey gagn

This is mostly out of theoretical interest.
I have read a lot of articles by accessibility experts, such as mr
Karl Grove's, talking about the link vs. button debate, a link is a
link and a button is a button.
Links take you to a new location, either on the same page or to a new page.
A button performs a user action, such as submitting a form, completing
a registration etc.

What when an object does a bit of both?
A good example is to complete one step of a process and moving on to
the next one (or to a previous one if one wishes to modify previously
submitted info).
This is very common, for instance when booking a trip or purchasing a
product (adding to shopping card, verifying order, providing shipping
info and options, providing billing info).
Going to the next or previous steps loads a new page, and, therefore,
should be served up as a link, but it is also an action, albeit part
of a set of actions, so one could argue that a button is more
appropriate.

From a screen reader perspective, I would advicate the use of a button
here. I do this mostly because users should have a clear, simple and
immediate way to complete the process they are undertaken. Therefore
they should need an HTML object that is unique to the page and simple.
Using a link in this scenario is not good because every other item on
the page (or most of them) is a link as well .. product image,
description, navigation menu etc.
If these be made into buttons, they usually are the only buttons on
the page, so a user of pretty much any screen reader can navigate to
these immediately.
But the world does not revolve around screen reader users, definitely not.
What about speech recognition software or keyboard simulators.
I would think that having these actions presented as buttons rather
than links enables these users to quickly navigate to them as well.
Are the next and previous links often presented in a unique way
visually (such as deploying a different background or color .. I often
see special .css classes applied to these things).

If anyone has given this a thought, has an official recommendation, or
would like to contemplate further, definitely drop this list a line.
Cheers
-B

From: Elle
Date: Sun, May 26 2013 7:24PM
Subject: Re: "next" and "previous" steps in a user interaction, link or button?
← Previous message | No next message

Birkir:

Based on my experiences from usability testing and extensive research from
Nielsen Norman Group about application design and user interaction models,
I think buttons usually make more sense for the "Back" and "Next" actions
in this scenario. This is because, like forms, you're really talking about
a system or application-like interface when you go into a multi-step
process. Website pages are informational in nature, whereas applications
are task-based in nature. For this, the path to completion becomes an
essential component. Often times, just like with web forms, in a multi-step
process interface you may have contextual help links and other
supplementary information that's activated via hyperlink as on-page
information. Having the "Back" and "Next" actions as buttons helps to
distinguish them from site navigation and other in-page links. In other
words, it helps to separate what a user can do within the page itself
(largely static information, again, like a website) from what a user can do
to advance to the next step or go back to the previous step (i.e.
task-based, application).


Cheers,
Elle





If you want to build a ship, don't drum up the people to gather wood,
divide the work, and give orders. Instead, teach them to yearn for the vast
and endless sea.
- Antoine De Saint-Exupéry, The Little Prince


On Sun, May 26, 2013 at 8:27 PM, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> Hey gagn
>
> This is mostly out of theoretical interest.
> I have read a lot of articles by accessibility experts, such as mr
> Karl Grove's, talking about the link vs. button debate, a link is a
> link and a button is a button.
> Links take you to a new location, either on the same page or to a new page.
> A button performs a user action, such as submitting a form, completing
> a registration etc.
>
> What when an object does a bit of both?
> A good example is to complete one step of a process and moving on to
> the next one (or to a previous one if one wishes to modify previously
> submitted info).
> This is very common, for instance when booking a trip or purchasing a
> product (adding to shopping card, verifying order, providing shipping
> info and options, providing billing info).
> Going to the next or previous steps loads a new page, and, therefore,
> should be served up as a link, but it is also an action, albeit part
> of a set of actions, so one could argue that a button is more
> appropriate.
>
> From a screen reader perspective, I would advicate the use of a button
> here. I do this mostly because users should have a clear, simple and
> immediate way to complete the process they are undertaken. Therefore
> they should need an HTML object that is unique to the page and simple.
> Using a link in this scenario is not good because every other item on
> the page (or most of them) is a link as well .. product image,
> description, navigation menu etc.
> If these be made into buttons, they usually are the only buttons on
> the page, so a user of pretty much any screen reader can navigate to
> these immediately.
> But the world does not revolve around screen reader users, definitely not.
> What about speech recognition software or keyboard simulators.
> I would think that having these actions presented as buttons rather
> than links enables these users to quickly navigate to them as well.
> Are the next and previous links often presented in a unique way
> visually (such as deploying a different background or color .. I often
> see special .css classes applied to these things).
>
> If anyone has given this a thought, has an official recommendation, or
> would like to contemplate further, definitely drop this list a line.
> Cheers
> -B
> > > >