Category: color

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. 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.

And for usability, it’s just easier to see the links and easier to scan them when they have underlines.

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. 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.

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”

Colorblind, Law, and Lightboxes

Color Sensitive

I usually shy away from About.com, but I recently came across a piece worth mentioning. In the article Are Your Web Pages Color Sensitive? from the HTML/Web Design section, Jennifer Kyrnin provides some good information and techniques for web development with color blindness in mind. Here are some good tips from Jennifer:

  • Don’t use only color to indicate something specific on your page.
  • Desaturate your images to see if they still have impact.
  • Avoid placing red and green together.
  • If you can, find a color blind friend or relative to look at your site.

Did you know that color blindness is an issue with 8 to 12% of males of European origin?

Law Needed

In his blog Yes, we need accessibility laws, Eric Eggert gives an argument for why we need better laws for web accessibility. He states that a good accessibility law should do:

  • Create awareness.
  • Do not create a climate of fear.
  • Create mediations.
  • Reference international standard.
  • Be inclusive.

Lightboxes

In the article Lightboxes and keyboard accessibility from 456 Berea Street, Roger Johansson describes how a lightbox should function with a keyboard. He states:

  • Let me use the left and right arrow keys to step through images in a slideshow.
  • When I press Esc, close the lightbox.
  • Do one of the following:
    • Either add focusable elements (links or buttons) for close/next/previous, put keyboard focus on the first focusable object in the lightbox, make sure I can’t tab to something behind the lightbox, and make it visually obvious which object has keyboard focus.
    • or close the lightbox when I press Tab.
  • When the lightbox closes, return keyboard focus to where it was when I opened it.

In addition, Roger cites the following two articles:

Podcast #73: Bandwidth & Download Time

Dennis and Ross provide nearly an hour of news, knowledge, and fun!

Download Web Axe Episode 73 (Bandwidth & Download Time)

Michigan and Web Dudes, Lab, and Accessible Twitter

Web Accessibility News

Main Segment

The Issue & Statistics
  • Web accessibility is about providing content for everyone; even if the user is unable to have access to a broadband internet connection.
  • Economic issue; many people simply can’t afford broadband.
  • Mobile–light and fast web sites can be more easily viewed on you phone!
  • Average Web Page Size Triples Since 2003 (study from 2003-2008 data)
  • In the U.S. in March 2008, users connecting at 56Kbps or less now make up 11.18% of active Internet users.
  • CWA Communications reported that the “median real-time download speed in the U.S. is a mere 2.3 megabits per second (mbps). The best available estimates show average download speeds in Japan of 63 mbps, in South Korea of 49 mbps and in France of 17 mbps.

Growth of Average Web Page Size and Number of Objects

Chart shows that from January 1995 to January 2008, there was a tremendous growth of average page size and average number of objects. The average page file size went from 14.1k in 1995, to 93.7k in 2003, to over 312k in 2008. The average number of page objects went from 2.3k in 1995, to 25.7 in 2003, to nearly 50 in 2008.

Related WCAG Guidelines

WCAG 2.0 Principle 4: Robust

Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

WCAG 1.0 Intro states:

user may have a text-only screen, a small screen, or a slow Internet connection and users may have turned off support for images (e.g. due to a slow Internet connection)

Greatly outdated web portion of Section 508 doesn’t mention internet connection speed.

What You Can Do
  • Use progressive enhancement.
  • Optimize images; use sprites.
  • Write clean code.
  • Use external CSS and JavaScript files. For CSS, use not @import.
  • Combine multiple CSS files into one. Same for JavaScript.
  • Use media domains.
  • Minify CSS and JS files.
  • Setup your server to send pages and files compressed.
  • Cache dynamic data and Ajax when appropriate.
More from the Big Boys

Podcast #34: Design Considerations for Accessibility

Considerations for designing an accessible web site, including discussion on web site conventions, navigation, color, text, and layout.

Download Web Axe Episode 34 (Design Considerations for Accessibility)

[Transcript for Web Axe 34]

Stick to Conventions

  • Search upper right
  • Global navigation across top
  • Sub navigation on sides
  • Icons

Navigation Considerations

  • Skip navigation
  • Indicate visited pages, current page
  • Use breadcrumbs where possible

Color Considerations

  • Ensure enough color contrast
  • Light on dark, or dark on light?
  • If you change the color of an anchor state, change them all
  • Never use color to convey information

Layout Considerations

  • If you have a low vision/large text style sheet, convert layout to one column
  • Pay attention to if it is obvious you can scroll downward or not
  • If Article is broken up between several pages, provide a link to a single page with the whole article for easy printing
  • Try and design for 760px minimum width

Text Considerations

  • Sans-serif fonts are generally easier to read on a screen
    • Print serif fonts are, but light reflects off of paper where screen illuminates light
  • Text Sizing
    • Ensure font can be enlarged with out breaking the design
    • Headers should be larger than regular text (to indicate more importance)
    • Fonts should be decent size, not everyone knows how to resize text

Other Considerations

  • Limit the use of Flash
  • Print Style Sheets
  • Graphical buttons should be text with graphical backgrounds (for sizing without pixelation)
  • Include an access guide, or site help
  • No flickering
  • Audio–plan for text-only version and links
  • Video–plan for real-time captioning