E-mail List Archives

Search E-mail List Archives for

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

From: Iaffaldano, Michelangelo
Date: Fri, Jan 25 2013 1:02PM
Subject: The buttons versus links debate
No previous message | Next message →

I would argue that in your scenarios either option is equally usable, provided that the link / button text and placement make the action very clear. But only usability testing can answer that with some certainty. This is equally true of no-AT users.
Cheers,
Michelangelo

-----Original Message-----
From: Sarah Ward [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: January 25, 2013 4:25 AM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] The buttons versers links debate

Hi everyone,

I'm trying to clarify when we should use a button rather than a link so that we can use the two consistently and provide the most appropriate experience to AT users.

Most of the time this is pretty simple: Use a link when it takes the user to another page, and use a button where the action is creating, adding, editing or deleting something. But there are a few scenarios I'm still struggling with and would like your advice on, particularly from what a screen reader user would expect or look for in these situations.

Situation 1) 

We have an 'Email to a friend' button (or link?) which opens an overlay which acts like a modal dialog. The user can then enter the appropriate details to send their information to a friend and submit (which definitely should be a button). Selecting the link that triggers this overlay is not actually editing any data at this point, its just showing some additional view/content and moving focus, so would this be classified as an internal link, or a button because the user is making an action to do something even though it is not modifying any data?

Situation 2)

We have a long form that is split into sections, and these sections collapse and expand as the user moves thorough the process on a single page. However the user can edit a section already completed using an 'Edit' link (or button?) Upon selecting this, the section expands and allows the user to edit the information they originally provided. My concern here is that all that happens by pressing this button did is expand information and display the appropriate form fields again. The user has not actually at this point edited any data. I don't think this can be considered an internal link either. The page unfortunately would not work at this point without JavaScript (a decision out of my control) in case this would be a deciding factor.

I would be interested to know which you think would be best in each case. Does anyone know of a good resource that defines when to use a link or button. My google searches have so far had mixed results. There's also the 'close' link debate to add to the overall confusion.

Thanks,
Sarah

From: Dylan Barrell
Date: Sat, Jan 26 2013 10:19AM
Subject: Re: The buttons versus links debate
← Previous message | No next message

Although this topic might appear to be independent of accessibility
concerns, it is not.

There are a couple of accessibility concerns:
1) name, role, value and state need to be clearly conveyed
2) link purpose needs to be determinable

Dealing with the second issue first, having a bunch of "Edit" links on a
page is an accessibility concern. You should place the link around the
entire form section name. Once you do this, you will notice that the "edit"
becomes problematic, so you will probably just remove it. Although this
causes a problem initially, it is ultimately an improvement (see below)

For the first issue, there are some simple rules that will get you 80% of
the way there:

1) if it looks like a button, then use <input> or <button>. So what if it
goes to a new page? That does not matter, because many buttons cause page
refreshes. If your UI team is doing their job and decided that it should
look to a sighted user like a button, then you should represent it that way
to all AT users.
2) As long as you are adhering to basic accessible styling guidelines and
have not eliminated the underline styling of links and have a good visual
focus indicator, then if it looks like a link, then use a link.

What about the other 20% - in a particular the expand-collapse?

This is where WAI-ARIA can help. An expand-collapse, is really either a
menu (for example where it exposes further navigation options), or it is a
tab list (for example where it exposes and hides pieces of content). My
recommendation here would be to use WAI-ARIA role="tablist", role="tab"
etc. OR role="menu", role="menuitem" etc. and related aria attributes (e.g.
aria-selected). Then make sure you implement the DHTML style guide for
keyboard interaction and you should be good to go.

In your specific situation, your "Edit" link is acting like "tab selection"
and you should implement it like that. If you have followed the above
recommendations i.e. surrounded your link around the entire form section
label, removed the "edit" and implemented WAI-ARIA attributes and keyboard
handlers then this will make sense to all users.

--Dylan