E-mail List Archives

Search E-mail List Archives for

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

From: Lucy Greco
Date: Fri, Jan 25 2013 1:11PM
Subject: The buttons verses links debate
No previous message | Next message →

Hello:
I don't have a clear answer to this ether but the one thing I would say as
a screen reader user is sites that use links and then make it look like a
button or even add the word button drive me crazy if it looks like a horse
it’s a horse not a bear smile

From: Corbett, James
Date: Fri, Jan 25 2013 1:14PM
Subject: Re: The buttons verses links debate
← Previous message | Next message →

What about a bare horse?

Jim

From: Birkir R. Gunnarsson
Date: Fri, Jan 25 2013 1:30PM
Subject: Re: The buttons verses links debate
← Previous message | Next message →

Technically a link should take you to other document content, be it
page or parts of your own page, whilst buttons initiate an action
(submit, download, open external document .. though this one is a grey
area of course).
Make a button something that is the main "action" on a page, and make
it stand out.
For instance, I like "previous" and "next" to be buttons, same with "search".
There is a formal discussion on this here:
http://www.zuschlogin.com/?p=18
It is somewhat lengthy, but I find it a good read.
One may not necessarily agree with all of it, but it definitely made
me think, which is good ..not everything can these days.
hth
-B

On 1/25/13, Corbett, James < = EMAIL ADDRESS REMOVED = > wrote:
> What about a bare horse?
>
> Jim
>
>

From: Greg Gamble
Date: Fri, Jan 25 2013 3:11PM
Subject: Re: The buttons verses links debate
← Previous message | Next message →

The way we do it here ...

Buttons are for actions: submitting, resetting ....

Links are for redirection: Link to a new location on the page(Anchor Link), Email link (Redirection to your default email app), Link to a different page or site.

Generally, menus are simply a styled list of links.

Greg Gamble
SBCTC - Olympia | Information Services
p - 360-704-4376
 think before printing

From: Don Mauck
Date: Fri, Jan 25 2013 3:52PM
Subject: Re: The buttons verses links debate
← Previous message | Next message →

Greg, I agree with the way you were doing. I have always felt that buttons are actions and links are things to take you to places. It frustrates me when people code links as buttons because it looks pretty yet I'm assistive technology package doesn't see it as a button. I prefer consistency if it's a button make it a button. If it's a link make it a link!

From: deborah.kaplan
Date: Fri, Jan 25 2013 4:05PM
Subject: Re: The buttons verses links debate
← Previous message | Next message →

Don Mauck wrote:

> It frustrates me when people code links as buttons because it looks pretty yet I'm assistive technology package doesn't see it as a button.

Agreed. I care less about the purpose (submit info vs. take you somewhere) and more about the look and feel. Depending on browser, voice and keyboard users can need to use different controls to access links and buttons. If it looks like a button but I can't access it like one, I get deeply confused and start renadomly guessing.

Many forms near the bottom have almost identitical appearing button-looking objects (submit/reset, for example), and if they don't act as designed I don't know how to control.

Basically you have a visual designer who says "they should look the same" and a UI designer who says "buttons and links are for different things' and the end result is troublesome.

-Deborah
--
Deborah Kaplan
Accessibility Team co-lead
Dreamwidth Studios, LLC

From: Chagnon | PubCom
Date: Fri, Jan 25 2013 4:45PM
Subject: Re: The buttons verses links debate
← Previous message | Next message →

<< I have always felt that buttons are actions and links are things to take you to places.>>

Wait. Wait.
This conflicts with the marketing, public relations, advertising, and publishing goals of nearly every website out there.

WCAG is fairly limited in what it calls a "button" — a submit button or radio buttons, both of which are in forms. But to web developers, "button" means anything graphical that I want the user to click.

If a web manager wants to highlight a new product, he'll make a button-like graphic that catches sighted visitors' eyes and encourages them to click and navigate to a webpage about the product. It's a fancy graphical button that takes the user to a new page on the website, so by your definition, this button acts like a link. Same thing about the Twitter and Facebook buttons common on webpages.

I could just as well design a website with a link that submits a form, rather than a button that submits it. It might not be the convention to do that, but I can do it.

So in web development, a discussion like this comes down to splitting hairs over the semantics between the words "button" and "link."

Is this, really, what we want? Do we, the accessibility community, want to alienate marketing directors and web developers by preventing them from using "buttons" as links to their internal pages or to Twitter pages because of how we've defined those 2 words?

Doesn't WCAG 2.0 gives us the guidance we need? Have meaningful text that defines the purpose of the link, whether that link is in the form of a button or text. If it will submit a form, tell the user. If it will take them to a new webpage, tell them.

Maybe WCAG can improve on how we notify users about the difference between "an action that will take place" and "navigation to someplace new," but if we redefine the words "button" and "link" for web developers, we'll win a skirmish and lose the war.

As a former editor, I could easily argue that "taking you to a new place" is just as much an "action" as submitting a form.

—Bevi Chagnon

From: Lucy Greco
Date: Fri, Jan 25 2013 5:02PM
Subject: Re: The buttons verses links debate
← Previous message | Next message →

I can't believe that you don't see how a screen reader user interacts with tech people you don't know how many times I have been told click the button and there is no button it’s a link or even more offal something a screen reader can't tell is clickable .

From: Chagnon | PubCom
Date: Fri, Jan 25 2013 6:44PM
Subject: Re: The buttons verses links debate
← Previous message | Next message →

And you're making my point, Lucy!
When we use ambiguous, multi-meaning words like "button" and "link" that mean different things to different people, there will be misunderstandings and confusion such as what you describe.

In your example, what the web developer called a "button" wasn't a button to you, a screen reader user. He meant the graphical thing with a link attached to it, which is what sighted website visitors would see and understand. Screen reader users needed more clarification to understand what they need to do and what will happen when they do.

But here's what is left out of this discussion: buttons have links.
The link could be one that takes the user to a webpage (a destination), it could open an email or other program, it could open a file, it could process something like submitting a form, or perform a function like adding up a total, but they are all forms of links.

Most graphical buttons are not neatly defined like the submit button or radio buttons in a form.

So when we say that a "button does this" and a "link does that," we confuse the heck out of web developers. In many cases there is no difference between the two. And when web developers don't correctly inform screen reader users, they confuse the heck of out them.

I believe we're after the same goal, Lucy: to make information accessible to everyone.
And I believe that if we hardwire define what a button is versus a link, it won't be used by web developers because we've misused 2 words that often are one and the same thing to developers.

So we have to find another way to give screen reader users what they need. I don't know what that is, but I do know that it isn't a redefinition of the words "button" and "link."

In your example, "how many times I have been told click the button and there is no button it’s a link," is exactly the case I'm making: in web development, they are most often one and the same.

—Bevi Chagnon

From: Birkir R. Gunnarsson
Date: Fri, Jan 25 2013 6:56PM
Subject: Re: The buttons verses links debate
← Previous message | Next message →

Hi

The article I quoted (see link above), is a general usability article,
and does not, particularly, have an accessibility focus.
I think the buttons vs. links debate debate is, I believe, a usability
discussion over an accessibility one. Both links and buttons are
perfectly usable by users with disabilities. In some cases the html
control types matter, especially to speech recognition users (I am not
an expert, want to sit down and test speech recognition software for
web browsing to get a better feel for the problems of that end users
group).
The A.T. perspective on this, I believe, is that using an html control
type that is different from the rest helps users navigate forms
quickly. For instance,prev or next being buttons as opposed to links.
I have a very hard time navigating through a check out process, or a
series of forms where I have to look through a long list of links or
headings, or use my browsers find function (for words like submit,
prev, next, check out, complete, or other words on links indicative of
the action I want to perform), to see how to get to the next step in
the process. If next and prev are links, there are hndreds of other
links on the page, so distinguishing these from the rest can be
difficult.
It is doable, and I feel the button vs. link debate should not
necessarily be an accessibility discussion, even if it has some effect
on accessibility.
Cheers
-B
p.s. If you guys have time, definitely read that article. It is a bit
long, the wording is a bit aggressive at times, but it definitely got
me thinking about webpage design and usability, which can be fun,
after all the fact that we are here shows that we are not doing our 9
to 5, but are genuinely interested in accessibility *grin*.

On 1/25/13, Lucy Greco < = EMAIL ADDRESS REMOVED = > wrote:
> I can't believe that you don't see how a screen reader user interacts with
> tech people you don't know how many times I have been told click the button
> and there is no button it’s a link or even more offal something a screen
> reader can't tell is clickable .
>
>

From: Chagnon | PubCom
Date: Sat, Jan 26 2013 12:16AM
Subject: Re: The buttons verses links debate
← Previous message | Next message →

Birkir wrote " The article I quoted (see link above."

Can you give us the link again? It was dropped from your post.
Thanks,
--Bevi

From: Birkir R. Gunnarsson
Date: Sat, Jan 26 2013 8:19AM
Subject: Re: The buttons verses links debate
← Previous message | Next message →

Oh, did not realize the link did not come through, take 2:
Links and other "wrong" controls:
http://www.zuschlogin.com/?p

or of course
<a href="http://www.zuschlogin.com/?p">Click Here :)</a>
I know, I know, it wasn't particularly funny, but it is Saturday
morning, the best that I can do right now.
Cheers
-B



On 1/26/13, Chagnon | PubCom < = EMAIL ADDRESS REMOVED = > wrote:
> Birkir wrote " The article I quoted (see link above."
>
> Can you give us the link again? It was dropped from your post.
> Thanks,
> --Bevi
>
>
> > > >

From: Greg Gamble
Date: Tue, Jan 29 2013 9:34AM
Subject: Re: The buttons verses links debate
← Previous message | Next message →

No disrespect intended ... but maybe it’s the marketing, public relations, advertising, and publishing people that are wrong and just need to be educated on what works and what does not. Many times I've had a user wanting to have a certain "Look" only to realize, after I point them out, the usability problems it causes. The way a page looks does not always correspond to how it works ... hope that made sense. :-)


Greg Gamble
SBCTC - Olympia | Information Services

From: Birkir R. Gunnarsson
Date: Tue, Jan 29 2013 7:44PM
Subject: Re: The buttons verses links debate
← Previous message | Next message →

It makes perfect sense.
I am currently working with a lady who has been learning web design,
and she insists on having this flashing carousel on the website,
because "it looks so cool" and "took me such a long time to program
all by myself".
I am sure she's right on both points, she's very smart and quite
capable, but it doesn't change the fact it causes huge accessibility
issues.
The artof selling accessibility is always a tricky one.
Cheers
-B

On 1/29/13, Greg Gamble < = EMAIL ADDRESS REMOVED = > wrote:
> No disrespect intended ... but maybe it’s the marketing, public relations,
> advertising, and publishing people that are wrong and just need to be
> educated on what works and what does not. Many times I've had a user wanting
> to have a certain "Look" only to realize, after I point them out, the
> usability problems it causes. The way a page looks does not always
> correspond to how it works ... hope that made sense. :-)
>
>
> Greg Gamble
> SBCTC - Olympia | Information Services
>
>
>

From: Chagnon | PubCom
Date: Tue, Jan 29 2013 9:36PM
Subject: Re: The buttons verses links debate
← Previous message | Next message →

Birkir wrote: "The art of selling accessibility is always a tricky one."

No, not really.
Basic sales techniques are:
1. Demonstrate the benefits of your product to your prospect.
2. Ask your prospect what they need or want.
3. Provide your prospect with what they need or want.
4. Make it easy and convenient for your prospect to buy your product.

How can you translate those techniques into "selling" accessibility?
Remember, web developers are creating websites for 75-80% of the population
(the majority of visitors) that does not experience accessibility barriers.

How can you make it easier for a web developer to include the 20-25% of the
population (a minority) that has a disability?

Regarding carousels on websites, web developers will continue to use them
because they are very successful mechanisms for the majority of visitors.
They work very well for a visual audience. Since a developer's job is to
produce statistical results of sales or visitors to the site, carousels
improve those statistics which makes their bosses and clients happy, which
in turn keeps web developers employed.

How can you convince developers to make carousels accessible?
Have you asked web developers what they need to make carousels accessible?
How can you make it easy for web developers to make web carousels
accessible?

Salesmanship 101.

Bevi Chagnon
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -
www.PubCom.com - Trainers, Consultants, Designers, Developers.
Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.
New schedule for classes and workshops coming in 2013.

From: Birkir R. Gunnarsson
Date: Tue, Jan 29 2013 9:47PM
Subject: Re: The buttons verses links debate
← Previous message | Next message →

Hi Bevi

Good post as always, can´t expect anything else from you.
May be I should create a new topic for this, but I have not found any
way or examples of making an animated carousel accessible, at least
not to screen reader users. The animation always affects the screen
reader focus, and the only approach I have found so far is to use
aria-hidden on the div surrounding said carousel, which hides its
entire contents (which can includes news stories and articles, special
offers etc) in addition to simply images.
It seemed to me like the ARIA role "marquee" would be perfect, but as
far as I know no screen reader has implemented it.
So, basically my particular problem is that I don't have the answers
for the developers. Offering a button to stop the animation is one
thing, but then the button needs to be readily accessible and easy for
users to find and activate before their screen reader focus is moved
elsewhere.
I have provided a lot of solutions, and seen excellent examples of
accessible tabbed browsing, accessible sliders and so on, but never
one iof a carousel with animation that is still accessible and does
not affect screen reader focus.
I may merely have been missing something, and I realize this is at
best a new topic and perhaps even belong more on an ARIA dedicated
list.
But, yes, it is hard to sell unless you have a readily available
solution to what the customer needs. I always have up till now, but
thissituation is troublesome.
Cheers
-B

On 1/29/13, Chagnon | PubCom < = EMAIL ADDRESS REMOVED = > wrote:
> Birkir wrote: "The art of selling accessibility is always a tricky one."
>
> No, not really.
> Basic sales techniques are:
> 1. Demonstrate the benefits of your product to your prospect.
> 2. Ask your prospect what they need or want.
> 3. Provide your prospect with what they need or want.
> 4. Make it easy and convenient for your prospect to buy your product.
>
> How can you translate those techniques into "selling" accessibility?
> Remember, web developers are creating websites for 75-80% of the population
> (the majority of visitors) that does not experience accessibility barriers.
>
>
> How can you make it easier for a web developer to include the 20-25% of the
> population (a minority) that has a disability?
>
> Regarding carousels on websites, web developers will continue to use them
> because they are very successful mechanisms for the majority of visitors.
> They work very well for a visual audience. Since a developer's job is to
> produce statistical results of sales or visitors to the site, carousels
> improve those statistics which makes their bosses and clients happy, which
> in turn keeps web developers employed.
>
> How can you convince developers to make carousels accessible?
> Have you asked web developers what they need to make carousels accessible?
> How can you make it easy for web developers to make web carousels
> accessible?
>
> Salesmanship 101.
>
> Bevi Chagnon
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - -
> www.PubCom.com - Trainers, Consultants, Designers, Developers.
> Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
> Accessibility.
> New schedule for classes and workshops coming in 2013.
>
>
> > > >

From: Chagnon | PubCom
Date: Tue, Jan 29 2013 10:42PM
Subject: Re: The buttons verses links debate
← Previous message | No next message

<< but I have not found any way or examples of making an animated carousel
accessible, at least not to screen reader users. >>

This is a good example of how we have to "sell across the industry." That
is, sell our goals not just to web developers, but also to:
1. Manufacturers of assistive technologies.
2. Manufacturers of software browsers.
3. Manufacturers of the software code and widgets that create carousels, and
other fancy items like them.
4. Manufacturers of WordPress and other CMS (content management systems).
5. Manufacturers of website templates that web developers purchase.
6. Manufacturers of web development tools, like Adobe Dreamweaver and
Microsoft Expression Web.

We can create all the WCAG and ARIA guidelines we want, but that won't get
these key stakeholders on our team.

Keep in mind that web developers generally don't code carousels, slideshows,
scrollers, navigation tabs, and other fancy visual doodads that are common
on websites. We buy the code and insert it into our website's HTML,
customizing where we can. We also buy entire website templates with the code
pre-written and we drop in our content and graphics.

So if a carousel is not working for you, see if you can read the HTML source
code and find out who is the manufacturer of the code or widget, which often
is hidden in a comment line in the webpage's code.

Ask them: what do they need to produce an accessible carousel?
Who knows! Maybe their engineers don't realize that there's an accessibility
problem and they might be willing to work out a solution.

By the way, there is one manufacturer that I know who is on this list and is
very responsive to the assistive community: Al Spaber of Project 7. Many
professional web developers purchase his company's templates, widgets, and
menu systems. Visit their webpage at http://projectseven.com/

We need more industry partners like this on our team. And it could help if
there was a central portal or webpage where developers could go to find the
manufacturers of these accessible widgets, tools, etc.

Maybe this is something WebAim could consider undertaking.

And, unfortunately, I don't have a good solution for making a carousel
accessible. The best I can think of is a "clickable thing" (notice that I'm
not calling it a button or a link) at the very top of the code that when
clicked will disable animations, carousels, etc. It could appear right
before a skip-nav link so you'd access it first.

—Bevi Chagnon

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -
www.PubCom.com — Trainers, Consultants, Designers, Developers.
Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.
New schedule for classes and workshops coming in 2013.