E-mail List Archives
Thread: The buttons versus links debate
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
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