Re: “Does the Control Change Something on the Current Page? Use a Button”
By “change” do you mean content, or presentation as well?
Presumably anchors for ‘tab’ panels is still legitimate? As per https://24ways.org/2015/how-tabs-should-work/
I probably should have been clearer. I think application of progressive enhancement can help answer that.
I consider a tab or disclosure widget, when done with progressive enhancement like the one you linked, to be a great example of using anchors. My own effort at an ARIA-enabled tab panel also uses anchors.
If I revisit that to work sans JS, then likely I’ll find those buttons are better served as anchor links.
@jonathan this is an alternative to anchors for “tab panels”: http://cssmojo.com/pure-css-tab-panel/ </shameless plug>
Thanks for clarifying, Adrian.
And thanks, Thierry, I’ve used the :checked approach before. It’s no JS capability is great, but it bugs me that it is JS dependent on IE7-8 and Android 2.x, and so utterly broken under no JS where :checked is not supported.
After reading @rem’s article last month I’m returning to the anchor pattern.
For disclosures, what we could all do with is something like https://discourse.wicg.io/t/panels-and-panelsets/1184/8.
Agreed, I’d love to see
<panelset>become a thing.
Well put Adrian!
The example you used is an older version of Foundation and I’m seeing that the guidelines you put out here have been implemented in the new version: http://foundation.zurb.com/sites/docs/button.html
I think it will help a lot of people design more accessible sites but knowing the best practices and aving the code to do so.
You are correct, I linked to (and captured) an old version. I pulled it out of my own archives and didn’t check the current release, so that’s on me (and I’ve updated the links and reference above). I see things are far better in the current (6.1.2) release.
Thanks for pointing that out to me.
[…] Roselli explains when we should use an a, a button, or an input type="submit" element for a clickable action item and why using a div is never a valid option for such […]
I’m curious: why would your first choice be an
<input type="submit" />instead of simply a
buttonelement’s default type is submit, so to me it seems like it would be better to just use that element for both cases. Other than the IE bug you mentioned, is there a major advantage to using
<input type="submit">instead of
Nate, there are two reasons I use the
<input type="submit">in that scenario:
- The pre-IE8 bug (along with general really-old browser support);
- In my experience working with teams, leaning on
<input type="submit">for a
<button>for a non-form use helps reinforce the purpose of the control with developers. This has had the effect of getting them used to making decisions about client-side scripting, error handling, styles, and so on as their brains are primed for a specific type of interaction belied by the element chosen. Of course, YMMV.
Ken, as I mentioned in a comment above, I think I could have been cleared on that point.
Linking to just a “#” suggests there is client-side script involved (else it’s a lazy link-to-top effort).
Linking to a named anchor is totally valid and is a key principle of progressive enhancement.
Really helpful, thanks!