RE: Buttons vs links

I want to apologize for all the CCs I added - I'm used to mailing lists that magically set the reply-to just to the list's email address, and it would seem that this one doesn't do that, and I didn't pay close attention to the list of CCs....

-----Original Message-----
From: Jeremy Echols <jechols@uoregon.edu> 
Sent: Friday, May 8, 2020 11:35
To: Janina Sajka <janina@rednote.net>; Andrews, David B (DEED) <david.b.andrews@state.mn.us>
Cc: Savage, Angela (ITS) <Angela.Savage@its.ny.gov>; Jan Hellbusch <jan@hellbusch.de>; w3c-wai-ig@w3.org; Léonie Watson <lwatson@tetralogical.com>
Subject: RE: Buttons vs links

Using the spacebar is "safer" when you're in a form.  If the thing is coded incorrectly, or I don't have the focus where I think I have it, an "enter" hit will submit data if you're anywhere on the form despite not going to the submit button directly.  I tend to prefer to use spacebar because it's a non-destructive operation unless you're actually on a specific form submission button.

It's simply not as black and white as "just make one element".

-----Original Message-----
From: Janina Sajka <janina@rednote.net>
Sent: Friday, May 8, 2020 11:23
To: Andrews, David B (DEED) <david.b.andrews@state.mn.us>
Cc: Savage, Angela (ITS) <Angela.Savage@its.ny.gov>; Jan Hellbusch <jan@hellbusch.de>; w3c-wai-ig@w3.org; Léonie Watson <lwatson@tetralogical.com>
Subject: Re: Buttons vs links

Why do people do what they shouldn't? I suppose one can pick one's favorite glib response, e.g. "original sin."

More interesting to me is why the two are created by HTML standards as entities supposedly distinct.

I would rather ask what's the difference to the mouse wielding sighted user? Either is responded to by the same click event. So, at best they look different on screen and that's supposed to mean something that's intuitively understandable. I rather suspect it just means more confusion especially to the tentative tech user.

And, if it is just a "look and feel" issue -- oops, make that just a "looks" issue, then why isn't the look accomplished via styling?

And we screen readers users could just as readily not worry about the theoretical distinction and keep pressing enter. It's not as though we obtain some kind of benefit by remembering to press the space-bar for the button. There's no reward for that especially, as you correctly note, these two entities are often miscoded anyway. Enter is more reliable.

Best,

Janina

Andrews, David B (DEED) writes:
> One problem with this button/link thing can impact screen reader users. Sometimes designers make links look like buttons, and visa versa. We are then told to find XYZ button, which our screen reader sees as a link. So we tell the sightling, there is no button!  
> 
> Links are links, and buttons are buttons. Why do people need to make it so complicated!
> 
> Dave
> 
> 
> 
> -----Original Message-----
> From: Janina Sajka <janina@rednote.net>
> Sent: Friday, May 8, 2020 9:14 AM
> To: Savage, Angela (ITS) <Angela.Savage@its.ny.gov>
> Cc: Jan Hellbusch <jan@hellbusch.de>; w3c-wai-ig@w3.org; Léonie Watson 
> <lwatson@tetralogical.com>
> Subject: Re: Buttons vs links
> 
> This message may be from an external email source.
> Do not select links or open attachments unless verified. Report all suspicious emails to Minnesota IT Services Security Operations Center.
> 
> ________________________________
> 
>  I must confess I've always found the buttons vis a vis links  distinction one without much of a difference from the user perspective.
> 
>  Either way most users click to invoke the associated result.
> 
>  Those of us who are mouseless by necessity may press spacebar for  buttons, but pressing enter also works. And, there are two many  instances where that which perports to be a button won't respond to  spacebar. Enter seems always to work. Off hand I can't think of an  exception.
> 
>  Thus my distinction without a difference conclusion.
> 
>  Best,
> 
>  Janina
> 
> Savage, Angela (ITS) writes:
> > Thank you for the responses. These have been helpful!
> >
> > -----Original Message-----
> > From: Jan Hellbusch <jan@hellbusch.de>
> > Sent: Thursday, May 7, 2020 12:28 PM
> > To: w3c-wai-ig@w3.org
> > Subject: RE: Buttons vs links
> >
> > ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails.
> >
> > Hi,
> >
> > according to HTML spec, links are for resources and buttons are for actions.
> > There are exceptions:
> >
> > * in general, use links for going to a new page or downloading a document.
> > * links can also be used within a web page (skip navigation links etc.)..
> >
> > * buttons are used for sending forms (most often to a script).
> > * Otherwise they should be used for performing actions on the web page (e.g.
> > widgets).
> >
> > * Actions can, of course, mean calling a new resource in a process. It will not always be clear, whether a button or a link is more appropriate.
> >
> > Jan
> >
> > > -----Original Message-----
> > > From: Savage, Angela (ITS) <Angela.Savage@its.ny.gov>
> > > Sent: Thursday, May 7, 2020 6:02 PM
> > > To: w3c-wai-ig@w3.org
> > > Subject: Buttons vs links
> > >
> > > I was wondering what is the proper usage for a button and a link 
> > > when
> > building
> > > an accessible application or website?
> > >
> > >
> > >
> > > I'm reading multiple articles on this topic and I read an article 
> > > from the
> > Nielsen
> > > Norman Group on command links and they state that buttons should 
> > > not be used for navigation and that users should click a plain 
> > > link to move to
> > another
> > > page of information. Multiple articles I have read  on using 
> > > buttons and
> > links
> > > when creating an accessible application or page mention this too.
> > >
> > >
> > >
> > > Article: Command Links
> > > <https://urldefense.com/v3/__https://gcc01.safelinks.protection.ou
> > > tlook.com/?url=https*3A*2F*2Fw__;JSUl!!C5qS4YX3!VnLwZtkhgsmDOldd-e
> > > EG8SynJKugmVV2TUIP8qXapEo39BHVRuLGSyzVO78U0iRQBw$
> > > ww.nngroup.com%2Farticles%2Fcommand-links%2F&amp;data=02%7C01%7Cda
> > > vi
> > > d.b.andrews%40state.mn.us%7C188d88af482640d242ea08d7f35afdf9%7Ceb1
> > > 4b
> > > 04624c445198f26b89c2159828c%7C0%7C0%7C637245444443445544&amp;sdata
> > > =5 iYs02cNgOnbItrZcOmT%2FrXzZS99QvXpBcdtPqXZZvk%3D&amp;reserved=0>
> > >
> > >
> > >
> > > Thank you in advance,
> > >
> > >
> > >
> > > Angela Savage
> > >
> > > Accessibility Auditor
> >
> >
> >
> >
> 
> --
> 
> Janina Sajka
> 
> Linux Foundation Fellow
> Executive Chair, Accessibility Workgroup:       https://urldefense.com/v3/__https://gcc01.safelinks.protection.outlook.com/?url=http*3A*2F*2Fa11y.org*2F&amp;data=02*7C01*7Cdavid.b.andrews*40state.mn.us*7C188d88af482640d242ea08d7f35afdf9*7Ceb14b04624c445198f26b89c2159828c*7C0*7C0*7C637245444443445544&amp;sdata=FDUgrI9vYLMO*2FiczzF2hkkvbGTXAqhQOeCu2Jp40T5g*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSU!!C5qS4YX3!VnLwZtkhgsmDOldd-eEG8SynJKugmVV2TUIP8qXapEo39BHVRuLGSyzVO7_bW7enrA$ 
> 
> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> Chair, Accessible Platform Architectures        https://urldefense.com/v3/__https://gcc01.safelinks.protection.outlook.com/?url=http*3A*2F*2Fwww.w3.org*2Fwai*2Fapa&amp;data=02*7C01*7Cdavid.b.andrews*40state.mn.us*7C188d88af482640d242ea08d7f35afdf9*7Ceb14b04624c445198f26b89c2159828c*7C0*7C0*7C637245444443445544&amp;sdata=paal2ZHHyMiFya*2BUSWt*2FPzn0gOhkrEHHLg*2Byq9Vt3sU*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJSU!!C5qS4YX3!VnLwZtkhgsmDOldd-eEG8SynJKugmVV2TUIP8qXapEo39BHVRuLGSyzVO78vTwjjEQ$ 
> 
> 

-- 

Janina Sajka

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup:	https://urldefense.com/v3/__http://a11y.org__;!!C5qS4YX3!VnLwZtkhgsmDOldd-eEG8SynJKugmVV2TUIP8qXapEo39BHVRuLGSyzVO7_H8XQJ3Q$ 

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Accessible Platform Architectures	https://urldefense.com/v3/__http://www.w3.org/wai/apa__;!!C5qS4YX3!VnLwZtkhgsmDOldd-eEG8SynJKugmVV2TUIP8qXapEo39BHVRuLGSyzVO7-n5k8fOg$ 

Received on Monday, 11 May 2020 12:18:01 UTC