I have nothing against the actual article, I guess I have some thoughts against some "practices" that should be "deprecated" from my point of view, and I'm fine with them being "errors" instead of "warnings".
First: I know folks style anchors to look like buttons, but I would argue that you shouldn't do that at all. Why would you do something like this...
<aclass="btn"role="button"aria-pressed="false">I'm a button, trust me</a>
Instead of just:
<buttonclass="btn">Don't trust the other button, I'm the real one</button>
If the reason is: "I want it to look like a button, but I want it to redirect me to a new place" I have two possible answers:
Drop the "I want it to look like a button" and think better your design.
Use a button and the "click" event.
I think this issue generally comes from designers that just think about "a e s t h e t i c s" and they don't even consider a11y/UX. Generally the same kind of folks that don't consider i18n, responsiveness and other "variables" that directly affect the designs.
The other issue I have is with stuff like <a name="sectionName">. As you said it, that's a really outdated way of doing things, so marking it as an error is perfectly fine from my point of view. Yeah, I know is "valid", but eval is also a valid JS function and you should still avoid it. Is good to get "errors" when you're using outdated stuff.
That's it, sorry for "ranting" about this stuff, great post as always 💖
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
That's it, sorry for "ranting" about this stuff, great post as always 💖
I am the angry rants person, you are always welcome to rant on my posts, I enjoy it and it is useful! 😁
I agree with what you are saying here and in my own personal style sheet I would not include as much flexibility or use old stuff like <a name> or <input type="button" (although <input type="reset" I may occasionally reach for if I need a no JS form backup...can't remember the last time I did use it though 🤣).
But I want to show people options as the post is more about concepts and showing people how to "roll their own" solution, rather than a copy paste solution for everyone.
It is not my place (even if I like to pretend it is sometimes 😉) to tell people not to do something which is valid HTML even if I think it is outdated unless I am the one writing the cheques for the code!
As always we are pretty much on the same page about these things and perhaps my article was a little too "soft" this time! 😁❤
I'm going to play devil's advocate here... how about a link to an external login site? A redirection to another site with a token and information, that will go back to our site eventually once it is validated. Should it be an <a> or a <button>? It is a redirection, so it seems like <a> would be a better option, but should it look like a button or like a link? After all, if it was an actual login form, it would be a <button>, no?
I guess could be a button inside a form with the action set to the target URL, and a bunch of hidden fields with the data you want to pass to the target URL. If you want to use JS, you could just do the redirect from the click event of said button.
I have a question as I'm still learning this stuff and my design skills are limited.
I agree that putting role=button on a link is just bad practice. If it's a link, it's a link.
My question concerns this bit:
If the reason is: "I want it to look like a button, but I want it to redirect me to a new place" I have two possible answers:
Drop the "I want it to look like a button" and think better your design.
Use a button and the "click" event.
I have an app where I did something like this on the homepage. Basically there's a link styled like a button to make it stand out more, with the idea of adding more as new functionalities are added.
It's definitely a link, screen-readers will treat it accordingly, and desktop users can see the url on hover.
Using a button would be bad for progressive enhancement, as it wouldn't work without JavaScript. And honestly it should be a link, I see no reason to use something else in this particular case.
Are you saying I should just choose a different styling to make my link stand out without looking like a button? My first question is why? Does it hurt users if a link is styled like a button? And assuming you're right, what would you suggest would be a better alternative?
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
You have almost certainly used the correct element so don't worry there.
The point they were trying to make is that it can be confusing for keyboard users when they encounter a link that looks like a button as they may press Space to try and activate it thinking it is a button (and that would just result in a page scroll normally!).
However it has become accepted practice to style "call to actions" etc. like buttons.
It will be fine as it is do not worry!
One suggestion would be to style your "links styled like buttons" slightly differently to "actual buttons" just so there is a visual difference / consistency across the site, but it is just a suggestion and certainly not something to worry about.
This is exactly what I wanted to know. I had no idea about Space, I always use Enter on both links and buttons when testing on keyboard. I can see how that would be annoying.
Now I'm thinking about which styling would make it more obvious that it's a link. A different shape, colour or font wouldn't help, it would still suggest that it's functionally a button. My guess is that underlining on focus (like I already do on hover) would be the most obvious. Are there other widely used signals I should know about?
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
Underline on focus vs no underline on focus is one way. 👍
Iconography in conjunction with text is a great way to differentiate, an arrow pointing to the right for example would work for links to differentiate them from buttons.
The key here is something that is unique to buttons vs something that is unique to links styled like buttons just so a user can learn "square looking buttons are links, rounded looking buttons are actually buttons" for example.
The problem I have with two styles that users learn to recognise is that it might not work so great on a landing page, which would mainly be visited by new users rather than returning ones. But it's still good to know it's an option for a different use case.
The problem with using <button>, especially the <input> button types, is that it comes with a LOT of baggage. Safari on iOS, for example, will override styles regardless of what they are with iOS button styles resulting in a less than attractive UI/UX. One could even argue that iOS buttons are downright ugly. a tags, on the other hand, can be styled however the designer wants. But even a tags also have baggage in that preventDefault() has to be called in Javascript (or return false; for the lazy) when handling the click action directly. Failing to do so causes the browser to add # to the URL and push the current page to the browser history back stack.
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
I have nothing against the actual article, I guess I have some thoughts against some "practices" that should be "deprecated" from my point of view, and I'm fine with them being "errors" instead of "warnings".
First: I know folks style anchors to look like buttons, but I would argue that you shouldn't do that at all. Why would you do something like this...
Instead of just:
If the reason is: "I want it to look like a button, but I want it to redirect me to a new place" I have two possible answers:
I think this issue generally comes from designers that just think about "a e s t h e t i c s" and they don't even consider a11y/UX. Generally the same kind of folks that don't consider i18n, responsiveness and other "variables" that directly affect the designs.
The other issue I have is with stuff like
<a name="sectionName">. As you said it, that's a really outdated way of doing things, so marking it as an error is perfectly fine from my point of view. Yeah, I know is "valid", butevalis also a valid JS function and you should still avoid it. Is good to get "errors" when you're using outdated stuff.That's it, sorry for "ranting" about this stuff, great post as always 💖
Cheers!
I am the angry rants person, you are always welcome to rant on my posts, I enjoy it and it is useful! 😁
I agree with what you are saying here and in my own personal style sheet I would not include as much flexibility or use old stuff like
<a name>or<input type="button"(although<input type="reset"I may occasionally reach for if I need a no JS form backup...can't remember the last time I did use it though 🤣).But I want to show people options as the post is more about concepts and showing people how to "roll their own" solution, rather than a copy paste solution for everyone.
It is not my place (even if I like to pretend it is sometimes 😉) to tell people not to do something which is valid HTML even if I think it is outdated unless I am the one writing the cheques for the code!
As always we are pretty much on the same page about these things and perhaps my article was a little too "soft" this time! 😁❤
I'm going to play devil's advocate here... how about a link to an external login site? A redirection to another site with a token and information, that will go back to our site eventually once it is validated. Should it be an
<a>or a<button>? It is a redirection, so it seems like<a>would be a better option, but should it look like a button or like a link? After all, if it was an actual login form, it would be a<button>, no?I guess could be a
buttoninside aformwith theactionset to the target URL, and a bunch ofhiddenfields with the data you want to pass to the target URL. If you want to use JS, you could just do the redirect from theclickevent of said button.I have a question as I'm still learning this stuff and my design skills are limited.
I agree that putting
role=buttonon a link is just bad practice. If it's a link, it's a link.My question concerns this bit:
I have an app where I did something like this on the homepage. Basically there's a link styled like a button to make it stand out more, with the idea of adding more as new functionalities are added.
It's definitely a link, screen-readers will treat it accordingly, and desktop users can see the url on hover.
Using a button would be bad for progressive enhancement, as it wouldn't work without JavaScript. And honestly it should be a link, I see no reason to use something else in this particular case.
Are you saying I should just choose a different styling to make my link stand out without looking like a button? My first question is why? Does it hurt users if a link is styled like a button? And assuming you're right, what would you suggest would be a better alternative?
You have almost certainly used the correct element so don't worry there.
The point they were trying to make is that it can be confusing for keyboard users when they encounter a link that looks like a button as they may press Space to try and activate it thinking it is a button (and that would just result in a page scroll normally!).
However it has become accepted practice to style "call to actions" etc. like buttons.
It will be fine as it is do not worry!
One suggestion would be to style your "links styled like buttons" slightly differently to "actual buttons" just so there is a visual difference / consistency across the site, but it is just a suggestion and certainly not something to worry about.
This is exactly what I wanted to know. I had no idea about Space, I always use Enter on both links and buttons when testing on keyboard. I can see how that would be annoying.
Now I'm thinking about which styling would make it more obvious that it's a link. A different shape, colour or font wouldn't help, it would still suggest that it's functionally a button. My guess is that underlining on focus (like I already do on hover) would be the most obvious. Are there other widely used signals I should know about?
Underline on focus vs no underline on focus is one way. 👍
Iconography in conjunction with text is a great way to differentiate, an arrow pointing to the right for example would work for links to differentiate them from buttons.
The key here is something that is unique to buttons vs something that is unique to links styled like buttons just so a user can learn "square looking buttons are links, rounded looking buttons are actually buttons" for example.
I like the arrow idea, it's a good hint.
The problem I have with two styles that users learn to recognise is that it might not work so great on a landing page, which would mainly be visited by new users rather than returning ones. But it's still good to know it's an option for a different use case.
Thanks for the tips!
The problem with using
<button>, especially the<input>button types, is that it comes with a LOT of baggage. Safari on iOS, for example, will override styles regardless of what they are with iOS button styles resulting in a less than attractive UI/UX. One could even argue that iOS buttons are downright ugly.atags, on the other hand, can be styled however the designer wants. But evenatags also have baggage in thatpreventDefault()has to be called in Javascript (orreturn false;for the lazy) when handling the click action directly. Failing to do so causes the browser to add#to the URL and push the current page to the browser history back stack.And problem solved there and it has good support.
If this has been stopping you from using a
<button>when you should then please start using them now.Please read this article on why you must use a button as I would hope it will stop you using a pattern we haven't needed for a long time!
😂 I like this guy!
You solved it like "There's your answer, no more excuses"
Take no prisoners! 🤣