E-mail List Archives
Thread: The buttons verses links debate
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
its a horse not a bear smile
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Tim Harshbarger
Sent: Friday, January 25, 2013 12:08 PM
To: Sarah Ward; WebAIM Discussion List
Subject: Re: [WebAIM] The buttons versers links debate
Sarah,
I was in a meeting with several interface designers where the topic of links
and buttons came up. I think it was also unclear to them exactly when to
use either buttons and links. Like you, they felt quite certain about some
situations, but there were others they were less certain about.
Based on the way you view the usage of links and buttons, I would think
buttons would be what you want to use in both situations. Neither situation
leads to the user going to another page. The first situation just is a
quick side trip to complete a task which ends up leading you back to the
same page. The other situation seems just to perform actions on the page.
If you are using ARIA though, you may want to look over the design patterns.
It is possible that your second situation may fit better with another design
pattern--like accordions.
I've not seen or heard a clear concise description of when to use links or
buttons. In fact, the reason the designers ended up discussing the topic is
because I asked them how they made that decision.
My own opinion tends to be that , if it is unclear, that would be a great
time for user testing. However, if you can't conduct user testing, another
good approach is to come up with your own approach and apply it consistently
across your application interface. If it turns out the approach is not
quickly intuitive, it at least means that once the user figures it out one
place that they will know how it works across the rest of the application.
And if you can't get the data you need to make the decision now, at least
you can do something to lessen the impact if the guess is wrong. Also, it
means if you have to fix it later, you will find it easier to locate where
you need to apply the fix.
I wish you the best of luck with your button-link dilemma. I would be
interested in hearing how you decide to resolve it.
Thanks,
Tim
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sarah Ward
Sent: Friday, January 25, 2013 3: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: 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
-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Lucy Greco
Sent: January 25, 2013 3:11 PM
To: 'WebAIM Discussion List'
Subject: Re: [WebAIM] The buttons verses links debate
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
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Tim Harshbarger
Sent: Friday, January 25, 2013 12:08 PM
To: Sarah Ward; WebAIM Discussion List
Subject: Re: [WebAIM] The buttons versers links debate
Sarah,
I was in a meeting with several interface designers where the topic of links
and buttons came up. I think it was also unclear to them exactly when to
use either buttons and links. Like you, they felt quite certain about some
situations, but there were others they were less certain about.
Based on the way you view the usage of links and buttons, I would think
buttons would be what you want to use in both situations. Neither situation
leads to the user going to another page. The first situation just is a
quick side trip to complete a task which ends up leading you back to the
same page. The other situation seems just to perform actions on the page.
If you are using ARIA though, you may want to look over the design patterns.
It is possible that your second situation may fit better with another design
pattern--like accordions.
I've not seen or heard a clear concise description of when to use links or
buttons. In fact, the reason the designers ended up discussing the topic is
because I asked them how they made that decision.
My own opinion tends to be that , if it is unclear, that would be a great
time for user testing. However, if you can't conduct user testing, another
good approach is to come up with your own approach and apply it consistently
across your application interface. If it turns out the approach is not
quickly intuitive, it at least means that once the user figures it out one
place that they will know how it works across the rest of the application.
And if you can't get the data you need to make the decision now, at least
you can do something to lessen the impact if the guess is wrong. Also, it
means if you have to fix it later, you will find it easier to locate where
you need to apply the fix.
I wish you the best of luck with your button-link dilemma. I would be
interested in hearing how you decide to resolve it.
Thanks,
Tim
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sarah Ward
Sent: Friday, January 25, 2013 3: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: 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
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Lucy Greco
> Sent: January 25, 2013 3:11 PM
> To: 'WebAIM Discussion List'
> Subject: Re: [WebAIM] The buttons verses links debate
>
> 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
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Tim Harshbarger
> Sent: Friday, January 25, 2013 12:08 PM
> To: Sarah Ward; WebAIM Discussion List
> Subject: Re: [WebAIM] The buttons versers links debate
>
> Sarah,
>
> I was in a meeting with several interface designers where the topic of
> links
> and buttons came up. I think it was also unclear to them exactly when to
> use either buttons and links. Like you, they felt quite certain about some
> situations, but there were others they were less certain about.
>
> Based on the way you view the usage of links and buttons, I would think
> buttons would be what you want to use in both situations. Neither
> situation
> leads to the user going to another page. The first situation just is a
> quick side trip to complete a task which ends up leading you back to the
> same page. The other situation seems just to perform actions on the page.
> If you are using ARIA though, you may want to look over the design
> patterns.
> It is possible that your second situation may fit better with another
> design
> pattern--like accordions.
>
> I've not seen or heard a clear concise description of when to use links or
> buttons. In fact, the reason the designers ended up discussing the topic
> is
> because I asked them how they made that decision.
>
> My own opinion tends to be that , if it is unclear, that would be a great
> time for user testing. However, if you can't conduct user testing, another
> good approach is to come up with your own approach and apply it
> consistently
> across your application interface. If it turns out the approach is not
> quickly intuitive, it at least means that once the user figures it out one
> place that they will know how it works across the rest of the application.
> And if you can't get the data you need to make the decision now, at least
> you can do something to lessen the impact if the guess is wrong. Also, it
> means if you have to fix it later, you will find it easier to locate where
> you need to apply the fix.
>
> I wish you the best of luck with your button-link dilemma. I would be
> interested in hearing how you decide to resolve it.
>
> Thanks,
> Tim
>
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sarah Ward
> Sent: Friday, January 25, 2013 3: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: 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@suberic.net
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 its a link or even more offal something a screen
> reader can't tell is clickable .
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Chagnon | PubCom
> Sent: Friday, January 25, 2013 3:45 PM
> To: 'WebAIM Discussion List'
> Subject: Re: [WebAIM] The buttons verses links debate
>
> << 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
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - - 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.
>
>
> > > messages to = EMAIL ADDRESS REMOVED =
>
> > > >
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 its 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
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Chagnon | PubCom
> Sent: Friday, January 25, 2013 3:45 PM
> To: 'WebAIM Discussion List'
> Subject: Re: [WebAIM] The buttons verses links debate
>
> << 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
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - -
> 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 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.
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R.
Gunnarsson
Sent: Tuesday, January 29, 2013 11:47 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] The buttons verses links debate
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.
>
>
> > > list messages to = EMAIL ADDRESS REMOVED =
>
messages to = EMAIL ADDRESS REMOVED =