Buttons

Brutalist Web Design

The term brutalism is often associated with Brutalist Architecture, however it can apply to other forms of construction, such as web design.

[…]

The term brutalism is derived from the French béton brut, meaning “raw concrete”. Although most brutalist buildings are made from concrete, we’re more interested in the term raw. Concrete brutalist buildings often reflect back the forms used to make them, and their overall design tends to adhere to the concept of truth to materials.

A website’s materials aren’t HTML tags, CSS, or JavaScript code. Rather, they are its content and the context in which it’s consumed. A website is for a visitor, using a browser, running on a computer [or mobile device] to read, watch, listen, or perhaps to interact. A website that embraces Brutalist Web Design is raw in its focus on content, and prioritization of the website visitor.

Brutalist Web Design is honest about what a website is and what it isn’t. A website is not a magazine, though it might have magazine-like articles. A website is not an application, although you might use it to purchase products or interact with other people. A website is not a database, although it might be driven by one.

They list the following principles:

But sometimes links look like buttons (and buttons look like links)

In Resilient Web Design Jeremy Keith discusses the idea of material honesty. He says that “one material should not be used as a substitute for another, otherwise the end result is deceptive”.

Making a link look like a button is materially dishonest. It tells users that links and buttons are the same when they’re not.

In Buttons In Design Systems Nathan Curtis says that we should distinguish links from buttons because “button behaviours bring a whole host of distinct considerations from your simple anchor tag”.

For example, we can open a link in a new tab, copy the address or bookmark it for later. All of which we can’t do with buttons.

Inclusive Tooltips & Toggletips

Most of the time, tooltips shouldn’t be needed if you provide clear textual labeling and familiar iconography. Most of the time toggletips are a complex way of providing information that could just be part of the document’s prose content. But I see each of these components all the time in auditing websites, so I wanted to provide some guidance on how to make the most of them.

Checklist

  • If you have space, don’t use tooltips or toggletips. Just provide clear labels and sufficient body text.
  • If it’s a tooltip you are looking to use, decide whether the tip’s content should be provided as the label or description and choose ARIA properties accordingly.
  • Don’t rely on title attributes. They are not keyboard accessible and are not supported in many screen reader setups.
  • Don’t describe toggletips with aria-describedby. It makes the subject button non-functional to screen reader users.
  • Don’t put interactive content such as close and confirm buttons or links in tooltips or toggletips. This is the job of more complex menu and dialog components.

Inclusive Toggle Buttons

How you design and implement your toggle buttons is quite up to you, but I hope you’ll remember this post when it comes to adding this particular component to your pattern library. There’s no reason why toggle buttons — or any interface component for that matter — should marginalize the number of people they often do.

You can take the basics explored here and add all sorts of design nuances, including animation. It’s just important to lay a solid foundation first.

Checklist

  • Use form elements such as checkboxes for on/off toggles if you are certain the user won’t believe they are for submitting data.
  • Use <button> elements, not links, with aria-pressed or role="switch" plus aria-checked.
  • Don’t change label and state together.
  • When using visual “on” and “off” text labels (or similar) you can override these with a unique label via aria-labelledby.
  • Be careful to make sure the contrast level between the button’s text and background color meets WCAG 2.0 requirements.

See the source link for very detailed descriptions of all of these points.