Isn’t this a lovely little HTML web component? All it does is hook up a button element with an audio or video element: exactly the kind of discrete drudge work that’s good to automate away.
I concur:
Just because a user interface uses 3D-buttons and some shading doesn’t mean that it has to look tacky. In fact, if you have to make the choice between tacky-but-usable and minimalistic-but-hard-to-use, tacky is the way to go. You don’t have to make that choice though: It’s perfectly possible to create something that is both good-looking and easy to use.
This is a really interesting proposal, and I have thoughts.
This is a handy guideline to remember, even if there exceptions:
When a keyboard user follows a link, their focus should be taken to the new place; when a keyboard user presses a button, focus should remain on that button.
A demonstration of how even reinventing a relatively simple wheel takes way more effort than it’s worth when you could just use what the brower gives you for free.
Prompted by my recent post about using native button elements, Trys puts forward a simple explanation for why someone would choose to use a div instead.
The one common feature between every codebase I’ve encountered on that doesn’t use
buttons well, is a bad CSS reset. Developers try to use abutton, and find that it still looks like a native browser button, so they grab a plain old, blank canvasdiv, and build from there.
Occam’s Razor makes Trys’s explanation the most likely one.
Do you need a button for your next project but you’re not sure about the right markup? Don’t worry, The Button Cheat Sheet™️ has got you covered.
Spoiler alert: it’s the button element.
A good tutorial on making password fields accessible when you’ve got the option to show and hide the input.
If you’ve been following my recent blog posts about a declarative option for the Web Share API, you might be interested in this explainer document I’ve put together. It outlines the use case for button type="share".
Some interesting research in here around user expecations with the back button:
Generally, we’ve observed that if a new view is sufficiently different visually, or if a new view conceptually feels like a new page, it will be perceived as one — regardless of whether it technically is a new page or not. This has consequences for how a site should handle common product-finding and -exploration elements like overlays, filtering, and sorting. For example, if users click a link and 70% of the view changes to something new, most will perceive this to be a new page, even if it’s technically still the same page, just with a new view loaded in.
Notes on the old internet, its design and frontend.
Have fun with this little machine, tweaking the parameters for generating a Joy Division/Jocelyn Bell-Burnell data visualisation.
The interface is quite delightful!
Chris takes two side-by-side deep dives; one into the a element, the other into the button element.
Even if you think you already know those elements well, I bet there’ll be something new here for you. Like, did you know that the button element can have form over-riding attributes like formaction, formenctype, formmethod, formnovalidate, and formtarget?
Sara runs through the many ways of providing an accessible name to an icon button, backed up with Scott’s testing.
Bringing gradients back, baby!
This is going to be a handy reference to keep on hand whenever you want a button to actually look like a button.
A history of buttons …and the moral panic and outrage that accompanies them.
By looking at the subtexts behind complaints about buttons, whether historically or in the present moment, it becomes clear that manufacturers, designers and users alike must pay attention to why buttons persistently engender critiques. Such negativity tends to involve one of three primary themes: fears over deskilling; frustration about lack of user agency/control; or anger due to perceptions of unequal power relations.
It’ll never catch on.
Analogue switches, dials, and buttons, buttons, buttons (just like that Flickr group I linked to).
In defence of the cascade (especially now that we’ve got CSS custom properties).
I think embracing CSS’s cascade can be a great way to encourage consistency and simplicity in UIs. Rather than every new component being a free for all, it trains both designers and developers to think in terms of aligning with and re-using what they already have.
Remember, every time you set a property in CSS you are in fact overriding something (even if it’s just the default user agent styles). In other words, CSS code is mostly expressing exceptions to a default design.
Sara shows a few different approaches to building accessible toggle switches:
Always, always start thinking about the markup and accessibility when building components, regardless of how small or simple they seem.