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
design forms html5 label

Placeholder Attribute Is Not A Label!

Just so we’re all clear on this, the HTML5 placeholder attribute in a text input is not a replacement for the label element. Period. The placeholder should only be used as a brief example of the text to be entered.

Besides inconsistent support for screen readers, using a placeholder as an input label can create usability problems and issues for those with cognitive impairments. For example, how does one review the information entered if the placeholder is now gone?

The placeholder should be used like a title attribute (tooltip); it provides only supplementary information. If the information is required for the user (such as a strict text format) then this should be conveyed in the main content of the page, not in an attribute.

The W3C HTML5 placeholder specification specifically states it should be a “short hint…intended to aid the user with data entry” and also states:

The placeholder attribute should not be used as a replacement for a label.

Supporting articles:

Bonus!
On @a11yMemes, check out this humorous take on placeholder.

Addendum (more references):

Also see Web Axe follow-up post: Floated Labels Still Suck.

Related Tweet Jan 2016:

https://twitter.com/shoobe01/status/689221623774220288

Categories
forms screenreader

Fieldsets, Legends and Screen Readers

In the article Fieldsets, Legends and Screen Readers from The Paciello Group Blog, the author Roberto Castaldo provides some excellent insight into how the screen readers JAWS and Windows Eyes work with the Fieldset and Legend tags. (Fieldset and Legend tags are used to group elements within a form.)

He concludes that support in JAWS is better overall than Windows Eyes, and that even there are issues in both screen readers, developers must continue to implement these standards tags and other accessibility practices.

Some tips from the article include:

  • Fieldset and Legend tags must be used together, never independently of each other.
  • Keep the content of the Legend tag brief (the Legend may be read when each of the controls contained in a Fieldset receive focus.)
  • In Windows Eyes, the option to read the Legend tag is off by default.
  • Fieldsets may be nested.
Categories
forms lists option podcast

Podcast #51: Option Groups (OptGroup)

Option lists with many items may cause problems for users with assistive technology, such as screen readers. The solution is to use the Optgroup element to split options in the Select list into manageable groups. This also better practice for usability.

Download Web Axe Episode 51 (Option Groups [OptGroup])

WCAG 1.0 says: Guideline 2.3 Divide large blocks of information into more manageable groups where natural and appropriate. [Priority 2]

Links

Sample Code:

News

Categories
captcha forms web

Podcast #40: About CAPTCHA and Accessibility

Dennis and Ross discuss different methods of implementing CAPTCHA on the web and how to make it accessible.

Download Web Axe Episode 40 (About CAPTCHA and Accessibility)

CAPTCHA Services

References

News