Categories
articles title

My Comment on “Tackling Accessibility on The Web”

Here is my comment on the blog Tackling Accessibility on The Web by @Treehouse.

An OK article, but a few of the techniques are incorrect/outdated. The data table caption is for a *title*, not a description. Never use tabindex (except 0 and -1 for keyboard focus with JavaScript interaction). Title attributes on links (and in general) is no longer recommended; screen readers usually don’t read them, browsers don’t support them for keyboard users, and it’s not supported (hardly) on mobile. Most implementations just have redundant information anyway. Also note that ARIA landmark roles are a good place to start learning ARIA, but there is much, much more to learn.

Another comment also states that the title attribute on links is not a great practice and provides a couple great links. Also note that the title attribute is still a must for an iFrame to describe its content.

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
socialmedia twitter

Make a Pledge for Easy Chirp 2

As you may know, Easy Chirp is a web-based Twitter client which makes the social media service accessible to all. This includes users with a disability (such as visual impairments and motor impairments), Twitter newbies, older users, low bandwidth, and non-JavaScript browsers.

Like all 3rd party Twitter apps, Easy Chirp gets its data from the Twitter API. Easy Chirp uses API version 1.0 which is being shut down in one month. It must be re-built with version 1.1.

The author of Easy Chirp (who is also the author of Web Axe) created a Kickstarter campaign to acquire minimal funds to rebuild the app with the help of a couple of other developers. At the time of writing, the goal is a little over half-way. Please consider making a pledge on the Easy Chirp 2 Kickstarter and help maintain “an inclusive Twittersphere”. If you’re unable to pledge, please forward this message to those who may be interested.

If the goal of the campaign is not met, there’s a good chance that Easy Chirp will not be updated and Twitter will not be available to those who need it.

Easy Chirp Kickstarter

Categories
aria roundup toolbar tools

Tools & Code Examples for ARIA Development

Here are some good tools, code examples, and other resources for developing with WAI-ARIA. Know any other good recent ones?

Tools

Code Examples

More