Category: links

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
links usability writing

Links: Don’t “Click Here”

So it’s the end of 2013, and sadly, the phrase “click here” continues to be used in text links all around the web. This is poor usability, accessibility, and sure makes the author look silly!

Reasoning

  • “Click” places focus on mouse mechanics (and many people don’t use a mouse).
  • “Click here” hides the target of the link; it’s not a good call-to-action.
  • Poor for visually scanning the page.
  • Users must make the extra effort to read before or after “Click here” to determine to where the link goes. (Don’t make me think!)
  • “Click here” has no context for when a list of links is provided to the user by the user agent.

Examples

To correct the problem, don’t use phrases like “click here” but use meaningful phrases which make sense out of context.

Before: I like the beaches here, here, and here.
After: I like the beaches in Maui, Sarasota, and Saugatuck.

Before: Click here to see if your bill is ready yet.
After: To see if your bill is ready, check the foo app.

Do you have any other examples?

Supporting articles

  1. Why Your Links Should Never Say “Click Here” (Smashing Magazine)
  2. I Don’t Want to Read More or Click Here (Karen Mardahl)
  3. Don’t say ‘click here’ on link text (goodusability.co.uk)
  4. Links and Hypertext (WebAIM)
  5. Click Here and Other Link Text (Jim Thatcher)

Notes

  • In addition to “click here”, the same can be said for “read more” and other similar link phrases.
  • Except for tool tips available to mouse users, the title attribute adds no value (touch devices, keyboard users, most screen reader users).
Categories
color design links

Keep the Underline

Being a web accessibility advocate and practitioner is certainly frustrating at times. Especially when important, foundational best practices get ignored because “the cool kids are doing it”. This was the muse for writing this tweet (for which I was happily surprised to see numerous retweets!):

Just because some big, popular companies make poor design decisions regarding accessibility, doesn’t mean you/your company has to.

You want an accessible, usable website? Then please don’t remove the underline on text links, particularly in the main content (in blocks of text). Unfortunately this design trend continues on the web (and the same could be said about those awful form input labels that act like placeholders, ugh).

Why? For accessibility, users with color blindness or low vision may have trouble distinguishing links from regular text when the underline is missing. Also remember situational disability; links with no underline are usually more difficult to determine when using a poor monitor or when using a computer in a brightly lit environment (since they usually use color alone).

And for usability, it’s just easier to see the links and easier to scan them when they have underlines. It’s also an issue for new users, and people with cognitive or literacy issues (such as dyslexia).

Personally, I’m getting a little older now and my sight’s color recognition is fading a bit. I really don’t like squinting and fighting to find the dark blue links within black text. Don’t make me think!

Some designs have bolded text links instead of underlining in order to differentiate the links from regular text. Bold text can get confused with headings and text that’s bolded for emphasis. And in my opinion, this give a less professional appearance, and still ignores the core convention of underlined text links.

It’s acceptable to remove underlines on text links when other visual cues replaces the underline, such as:

  • Text links in visually explicit navigation bars, dropdown menus, etc.
  • Text links designed to look like buttons (with button functionality and role=button of course!)

Resources

Here are several resources about this issue:

Examples

The following websites have underlined text links in the main content:

Summary

Please don’t remove underlines on text links in main content. Leaving them as intended is better for accessibility, usability, and maintains the core conventions of the web.

Addendum

Check out this follow-up news article on dot net which adds an important point:

the motivation for retaining underlines is “just as much for people with cognitive or literacy issues”

This article was last modified Dec. 2017.

Categories
articles heading html5 links review table

Response to MSDN Article “Designing Accessibility with HTML5”

This blog is a review/response to the recent MSDN article Designing Accessibility with HTML5 by Rajesh Lal (@irajlal). The article is quite extensive and covers an intro to accessibility and disability, progressive enhancement, ARIA, forms, tables, and more.

I had actually reviewed an early version of this article, but it seems some of my feedback was not incorporated, and there is also some new content in the article. So let’s discuss some of those items and more.

The introduction does an adequate job of covering the four main types of disabilities: hearing, mobility, cognitive, and visual. For reference, here’s the link to the WCAG 2.0 POUR model (perceivable, operable, understandable, robust) as mentioned.

Progressive Enhancement

I was happy that Progressive Enhancement (PE) was mentioned next, early in the article. I firmly believe that semantic markup and PE are essential to a robust and accessible webpage. PE was described fairly well, but then I was disappointed to see example code further down the page which does not use PE. In Figure 9, the form example is missing a URL in the action attribute and contains the following line to submit:

<div><a href="#" onclick="submit()">Send Your Message!</a></div>

This line does not represent proper semantic markup, progressive enhancement, nor the non-JavaScript use case. A better example would be to add a dummy URL in the action attribute, and for the submit button, do this:

<input type="submit" value="Send Your Message!" />

Headings

In Figures 6 and 7, home page sample code, the document outline is broken. The heading order jumps from H2 to H4 so is missing the H3. It also appears that the H4 elements in the aside element are correlated to the last H2, which in incorrect; they are separate topics. To solve, I would insert an H2 heading in the aside element and change the H4 elements to H3. In addition, there is no H1 element.

Figure 11, Markup for a FAQ Page, does indeed provide an ideal heading structure.

A perfect heading structure is not essential, but certainly helps. Especially when the code is an example for other developers.

And for the record, in Figures 6 and 7, the image element for the logo is missing alt text.

JavaScript Insertion

It’s good that the author recommends placing the external JavaScript files at the end of the body (at end of home page section), but remember that you may need to put certain JavaScript at the top, mostly scripts for feature detection such as Modernizr. (This isn’t really accessibility but thought I’d include anyway.)

Fieldset/Legend

In the Contact Form section, I really like that the sample code is using the placeholder attribute correctly. But there’s one issue; the fieldset element is being used but the legend is missing. The spec oddly says legend is optional, but it’s definitely best practice to use it. Otherwise, there’s no reason to use fieldset in the first place as far as I know.

Data Table

In the data table, use of a caption element is great, but I’m perplexed as to why there is a details and summary element within the caption. And I wouldn’t recommend using a strong element with the caption text; use CSS instead. Also, the TH elements should have a scope attribute; it may not be necessary with newer assistive technologies, but makes the code more robust and semantic.

Links, titles, and abbreviations

Towards the end of the article, there’s a section on links and images. I really advocate this advice: Use a CSS background image if your design requires an icon such as “>”.

Just before that, I have issues with the sample text link. Avoid “click here” is good, but then the title attribute contains “click for”. This somewhat of a moot point as the title isn’t needed at all. Traditionally, the title attribute is only needed for additional supplementary information (not required for user). The mighty Steve Faulker, in his article Using HTML title attribute, suggests that title only be used in a couple rare cases.

For images, I would not recommend the title attribute here either (due to lack of support). For even more on that, check out this recent article about title attributes on the RNIB site.

About the link underline, of course I agree that text links (in main content especially) should be underlined. The sample CSS adds the underline, but it’s much better to do this by not removing it in the first place. The underline does not have to be added; it should already be there by default.

The abbreviation example is simple and solid, but there’s more to it than that. Because of poor support, the title attribute doesn’t work typically with the keyboard and some assistive technologies (see links above). Therefore, I strongly suggest that the full text of the acronym or abbreviation is written out when it first appears on each page.

Final Thoughts

I don’t have much to say about the audio/video section; I’m just wondering where the keyboard shortcuts listed for the HTML5 media controls comes from.

It’s great to see that Visual Studio 2012 has ARIA support. I know it’s still a popular application, but I don’t have much experience with it myself.

The MSDN article Designing Accessibility with HTML5 has a lot of good information and tips. But many times, especially with accessibility, the devil is in the details. It is quite a tricky topic and there are many nuances and gray areas. I hope this response has cleared up some of those.

Categories
links roundup

Link Roundup – August 2010