Category: design

Categories
design forms links

Proper Use of Buttons and Links

After years of arguing for proper use of form elements and link elements, others are finally doing the same. More recently, this includes the articles The Anchor Button: Bad for Accessibility, Bad for Usability by Matt Long and Reinventing the hyperlink (with much humor!) by Heydon Pickering.

The main point is, please do the basics. When designing a website, ensure controls with button-type behavior (submitting form and opening a modal dialog) are designed as buttons and regular text links (go to an external page, anchor on page, or external document) are designed like text links (such as blue underlined text).

When developing a website, ensure buttons are coded as buttons (the button or input element) and links are coded as links (the anchor element). You could also use ARIA roles to denote button and link, but it’s always better to use the semantic HTML elements.

Here are some reasons why it’s so important:

  • accessibility and usability
    • provides user with expectation of the control’s behavior
    • avoid conflicts with voice-control user agents (speech recognition software) such as Dragon NaturallySpeaking
  • a more robust website (support older user agents, non-JS, etc.)
  • lighter and less complex code
  • more consistent implementation so easier to maintain

Remember that for accessibility, no matter how much ARIA and trickery is done, there will mostly likely still be problems. When blurring the distinction between a button and a link, assistive technology (and/or the user) can be confused as to what’s what. View the beginning of this presentation by Derek Featherstone for a good example of this.

This is a button; this is a text link; don't mix them up.
Button versus text link.

This advice sounds simple, but this elementary guideline is broken quite often; once you start to look, you’ll find it everywhere on the web, especially web apps. There’s no need to create confusion (the design) and to re-invent the wheel (the development). Sticking to the basics will make it easier for everyone, most importantly the user.

For an example of proper implementation, check out Easy Chirp.

Further reading:

Addendum:

Last updated April 2023.

Categories
book design twitter usability

Tweets quoting “Don’t Make Me Think, Revisited”

A short while ago, my author @DennisL read the excellent book Don’t Make Me Think, Revisited by acclaimed usability professional Steve Krug. Dennis was so impressed with the book, he tweeted a series with quotes, mostly relating to accessibility (as well as design and usability). So in case you missed it, here they are:

Categories
design fun youtube

Fun Web Accessibility Videos

Follow Harold in his quest to make an accessible website for his company Jiffy Brothers! This is an entertaining two-part video series about a fictional company and its website. It’s produced by The Human Resources Professionals Association (HRPA) of Ontario, Canada. Watch out for Boris!

Part 1 “Auditing Your Website for Accessibility”

Part 2 “Developing an Accessible Website”

You can find more information and videos from HRPA on the HRPA YouTube channel.

Categories
aria design menu roundup

A11Y Roundup, Summer 2013

Here are some great links from this past summer. Enjoy!

Categories
design tab usability webaim

About Carousels and ARIA Tabs

Jared Smith (@jared_w_smith) of WebAIM recently launched a clever web page on why carousels are not good practice called Should I Use A Carousel? (which totally went viral on its launch day!) There is a slide deck Keyboard and Interaction Accessibility Techniques (on Slideshare) for which this website was made. I was fortunate enough to see Jared present this at Open Web Camp 5 July 13 at PayPal.

Jared presenting at OWC5

I don’t think that a carousel itself is super terrible. But in my experience, carousels are hardly ever coded with accessibility in mind and hardly ever designed with decent usability. In addition, supporting smaller devices is an issue and coupled with the poor usability data, carousels are overall a bad idea. If you absolutely must implement a carousel, here are some design/interaction tips:

  • Let the user start the carousel animation.
  • Give the user the ability to pause the carousel.
  • Ensure the controls have textual labels.
  • Ensure the control of the currently displayed panel is indicated visually and programmatically.
  • Ensure the controls have ample hit areas (for mobile, fine motor disability).

On the development side, a carousel can be challenging to make screen reader accessible. It seems that the most straight forward approach is to use the ARIA tab model which is pretty straight forward and fun to do! Here’s a summary of what to do in the markup:

  • Each carousel content container has a role of tabpanel.
  • Each control, typical designed as dots, has a role of tab.
  • The container of the controls/tabs has a role of  tablist.
  • Add aria-labelledby to the tabpanels which point to the id of the associated control/tab.
  • To each control/tab, add aria-controls (which points to the id of the associated tabpanel) and aria-selected (boolean) attributes.

Here are some code resources to help make sense of this. This first by Marco may be most relevant:

More:

Updated August 2017