The main point is, please do the basics. When designing a website, ensure controls with button-type behavior (interaction, affects the current page) 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).
Here are some reasons why it’s so important:
accessibility and usability
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 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.
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. 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.
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.
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.