Link accessibility is one of the most important aspects of usability. However, designers often don't understand what it takes to make links accessible. Most frequently, they only distinguish links by color, which makes it hard for users with visual disabilities to spot them in text blocks — even if high color contrast is used.

As a rule of thumb, accessible links shouldn't rely solely on colors. Partly because users with low vision, color deficiency, and other visual impairments can't always recognize this kind of link, but also because it's easier for regular users to skim through the content if links are better emphasized.

However, it's not always easy to find out how to create accessible links that match your website design. It's also possible to overdo it by using too many visual signifiers that might confuse the user.

Link types

When we speak about links, we usually think of the classic blue links with an underline, however there are actually different kinds of links, such as:

• body text links,
• headline and subtitle links,
• menu links,
• buttons,
• image links,
• video links,
• audio links,
• and more.

In this article, I'll only speak about the first group: body text links. Don't read it as a guideline but rather an experiment for understanding what can be done for more accessible links.

Accessible links according to WCAG 2.0

According to WebAIM's guidelines about links and hypertext, WCAG 2.0 has two additional requirements for body text links:

1. The link text must have a 3:1 contrast ratio from the surrounding non-link text.
2. The link must present a "non-color designator" (typically the introduction of the underline) on both mouse hover and keyboard focus.

Web browsers come with a default link styling that meets these requirements. You can check it out by disabling all additional CSS styles using the Web Developer browser add-on or another dev tool. For example, this is how the homepage of the Mozilla Developer Network looks like in Chrome:

It's a very basic styling for sure, but it's still styling: the underlined blue links are well-known and internet users can easily recognize them. It's not a coincidence that the Nielsen-Norman Group also names blue the safest link color choice in its Beyond Blue Links: Making Clickable Elements Recognizable article.

Examples of accessible links

WebAIM doesn't recommend removing the underline using CSS, as "users are accustomed to see links underlined". Still, many of the biggest websites don't follow this principle of link accessibility. Many times, they don't only remove the underline from the default link state but also the :hover styles.

But, why do they do that? Mainly for aesthetical reasons, however underlined links don't necessarily have to be plain-looking and boring.

1. Border-bottom

For instance, Bloomberg uses the border-bottom property to mimic an underline in a different color. As you can see below, the link texts are black while the underlines are blue, which gives a stylish design to the links.

Perhaps Bloomberg's links could further benefit from bold letters, but it's a good example that underlines can be used for links creatively, not just in the usual way.

2. Reverse underline

The Verge uses a different approach to create underlines for body text links. Here, underlines are present by default, however they are removed when the user hovers over the link. When the underline disappears, the color also changes subtlely, from pink to magenta (however this color change is barely recognizable).

The presence of underlines in the default state helps readers easily notice the links, even within large text blocks. And, when they hover over the link, the state change is instantly visualized by the disappearing underline. An unusual choice, for sure, but it still follows the principle of using non-color designators for accessible links.

3. Icons

You can also help users recognize links by adding tiny icons next to them. For example, some news sites add a video icon next to the links that point to videos (however, embedding videos is a more widely used practice these days).

WebAIM chose an all-inclusive solution for link accessibility. Besides the underline, they also add a small icon after each external link. In this way, the icon doesn't only serve as an extra visual signifier but also clearly distinguishes external and internal links.

You don't necessarily need to create a link icon by yourself. For instance, Font Awesome has an external link icon that you can quickly add to your links.

4. Link text

As screen readers notify users when they come across a link, it's not recommended to use phrases such as "link to" or "follow this link" for the link text. Instead, you should provide link texts that describe the main content of the link. It makes it easier for users to decide if they want to click the link, which is especially important for users with cognitive disabilities.

WCAG 2.0 even has a recommendation on how to provide proper link texts, with a handful of useful examples (mainly for image links, though).

If you want to see an example of proper link text I would mention the Gov.uk website that publishes governmental information in the UK. For example, check out their Set up a business page.

Have a look at, for instance, the Find out more about being a sole trader and how to register line on the screenshot above. Note that they put the anchor tag on the part that describes the purpose of the link ("being a sole trader and how to register") instead of the action verb ("find out more").

The controversial role of the title attribute

The role of the title global attribute in link accessibility is an interesting question. If you add it to a link, the extra information appears somewhere around the link when users hover it.

For instance, take the following line of HTML:

<a href="#" title="Extra information">Hover this link but don't click it.</a>

It's displayed like this in the browser: Hover this link but don't click it.

I've long thought that adding the title attribute to links is a good practice for accessibility, as the extra information helps users understand the purpose of the link. However, WCAG 2.0 has a slightly different view on the question.

On their "Supplementing link text with the title attribute" page, they mention several accessibility problems. For example, the title attribute isn't available to assistive technology and keyboard-only users. Besides, it disappears after about five seconds in some user agents, which usually doesn't leave enough time to read it.

On the whole, WCAG 2.0 doesn't advise against the title attribute but recommends careful usage. One thing is sure, never use title for important information that is not available in another form, such as warnings. On another note, if title can be used only for unimportant information, is it worth using at all?

Link states

There are five different link states, represented by CSS pseudo-classes: :hover, :focus, :active, :visited, and :link.

It's an open question whether it's better for accessibility to style all link states differently or not. If you use different style rules for each state, users are notified about every change indeed, however is that always a good thing? Too many state changes can cause information overload and confusion to the user.

Personally, I tend to create one style for the default link state, a second one for the :hover, :active, and :focus states, and sometimes a third one for :visited links. However, I still can't tell if this is the best solution for accessibility. If you are interested in the topic here's an interesting StackOverflow UX discussion on whether the styling of the :focus and :hover states should be the same or distinct.

However, there's an important thing you should keep in mind by all means. Don't remove the dotted outline that browsers use for the :focus state. Keyboard (tab) navigation will be useless if the focused element is not visible on the screen. If you remove the dotted outline, keyboard users will literally lose focus. If you're annoyed by the default outline style make it less obtrusive with extra styling, but don't remove it.

Read more

In my blog, I cover accessibility-related topics that are less widely discussed. If you want to read more, check out my article about why software documentation is part of accessibility, too.

Whether you only have a prototype or a full-fledged product, it’s a really good idea to run monthly usability tests. These make sure that whatever you’re working on is usable and the user experience is excellent.

_Source: [Unsplash](https://unsplash.com/@bramnaus?utm_source=medium&utm_medium=referral" rel="noopener" target="_blank" title="">Bram Naus on <a href="https://unsplash.com?utm_source=medium&utm_medium=referral" rel="noopener" target="blank" title=")

If you’re wondering what you can do to make your usability tests more structured and organized, this guide is for you. Let’s get started!

First off, always keep the two Golden Rules of Usability Testing in mind:

1. Any testing is better than no testing (with no one!)
2. A little testing earlier is better than a lot of testing later.

In this post, I will introduce you to the kind of lightweight usability testing described in Steve Krug’s books, “Don’t Make Me Think” and “Rocket Surgery Made Easy.” Steve calls this kind of testing “Do-It-Yourself Usability Testing” since it’s supposed to be cheap, easy-to-do and takes just a morning a month.

A quick intro to usability testing

The idea behind this is to:

• Find a few participants
• Ask them to come in and go through a list of user flows you want to test
• Observe the problems they run into
• Finally, make a list of issues to fix

Sounds simple enough, but very few of us actually do it. The goal of this post is to make you confident enough to run at least one usability test session this month. I ran my first usability test only a year ago, and I must say it’s actually a lot of fun!

Before we get to the test itself, here are a few things to note:

1. Reserve one morning a month (say the third Thursday every month) for a round of testing, debriefing, and deciding what to fix.
2. Test with three participants each round. Recruit loosely, and grade on a curve. You don’t need to find someone who fits the exact mould of your ideal user, since most usability problems can be uncovered by testing with just about anyone.
3. If you are part of a big company and have the budget, you can recruit via Craigslist and offer a $50 gift card for an hour of the participant’s time. If you don’t have those kind of resources, don’t worry — you can ask your friends, your existing users, or even go to a café and ask strangers for 15 minutes of their time in exchange for buying them a coffee.
4. If you’re doing this as part of a bigger team, get as many observers as possible to observe the tests in a separate observation room. These will be the designers, engineers, project managers, executives, etc. Or, in case of side projects, it’ll be just be you later in your room!

What happens during the test?

During a usability test, you will record the participant’s voice and their computer screen, and share both these streams live with observers in another room. A typical one-hour test can be broken down into:

1. Welcome (4 mins): Explain how the test will work so that the participant will know what to expect.
2. The questions (2 mins): Ask the participant a few questions about themselves. This helps put them at ease and gives you an idea of how computer-savvy they are.
3. The Homepage tour (3 mins): Open the Home page of your site, and ask the participant to look around and tell you what they think. This will give you an idea of how easy it is to understand your home page, as well as how familiar the participant is with your domain.
4. The tasks (35 minutes): Watch the participant perform a series of tasks you have prepared for them beforehand. If you’re building a SaaS product and you’re testing out your subscription flow, a typical task could be to find the Pricing page, compare various plans, and Subscribe to one of the plans with a provided test credit card number. Encourage the participant to think out loud as they perform the task (see the video at the end of the post for a sample test.) It’s crucial that you let them work on their own and not ask them any leading questions, or give out any clues or assistance.
5. Probing (5 mins): Ask the participant any questions you may have about anything that happened during the test and about any issues that people in the observation room may have. Also, answer any questions that the participant may have at this point (don’t answer them during the actual tasks since you’re testing how they’ll perform with no one around.)
6. Wrapping Up (5 mins): Thank them for their help, and give them their gift card if you promised one while recruiting them.

The debrief

During the breaks between successive tests, ask the observers to write down the top 3 usability problems that they saw. During the debriefing, focus ruthlessly on deciding to fix the most severe problems first. Here are a few other recommendations:

• Keep a separate list of low-hanging fruit. These are the problems you can typically fix with one-line code changes, but have a huge impact on task completion rates. Joel Califa calls them “tiny wins”. Here’s an example:

• Resist the impulse to add things — instead, try to tweak your existing design to fix the problem.

• Take “new feature” requests with a grain of salt. Participants will often suggest new features, but when you probe them further, they will admit that they will likely not use the features they are proposing. Instead, try to get to the root of the problem that the participant faced and was trying to fix on their own by suggesting that new feature.
• Ignore the problems where the user goes astray for a bit but comes back on track by themselves. These are usually not worth investing much time unless you see a pattern across multiple participants.
• Good design is a delicate balance, so when fixing a problem, ensure that you aren’t introducing new ones.

Remote testing and unmoderated user testing

Remote testing is very similar to an in-person usability test, except that the participant is at their home/office and you conduct the testing via screen sharing and voice call.

Unmoderated user testing is another way to test, where you specify your website, the tasks you want the users to do, and get back video recordings of people trying to accomplish those tasks. Usertesting.com is the leader in this space, but note that a single 30-minute test costs about $50.

Resources

• You can download checklists, interview script, consent form, and a demo video at Steve Krug’s site here: Downloads for Rocket Surgery Made Easy.
• Here’s a Usability Test demo video from Google Ventures:

I want to thank you for reading this quick guide. This was originally published as part of the UX Design course on Commonlounge, a platform that has courses with small bite-sized lessons like these on topics ranging from Project Management to Machine Learning that deliver the most value for the time you put in.

You learn by working on real-world projects and getting feedback from industry mentors. You should check it out here!

You know those obscure menu buttons on apps and websites that reveal even more menu options? They usually have an ellipsis “…” or an arrow ▼ icon on them and sometimes they’ll even have a More label. Or, better yet, a More with a ▼! These are called overflow menus. Overflow menus are a scourge that should be rooted out, crushed underfoot, and drowned in a sea of toxic sludge.

Gmail has no fewer than 4 overflow menus when viewing an email!!!! You’re damned right I used a bunch of exclamation marks!!!!!!

Overflow menus are really enticing to user interface designers. It’s been drilled into designers’ heads for years that the pinnacle of achievement is a “clean” user interface. Designers blindly stumble over each other to heed the old adage:

…perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away. — Antoine de Saint-Exupery

Overflow menus seem like the perfect solution. Designers can “take away” complexity and leave just the really important bits. You can quickly and easily create a clean looking user interface. The trouble with overflow menus is that you didn’t actually take anything away, you just obnoxiously obfuscated it.

The crux of the issue is that overflow menus let designers, engineers, and product people off the hook from making tough choices. Instead of prioritizing, we just sweep complexity under the rug and pretend that it doesn’t exist. Software with overflow menus is often still hard to use, even if the complexity is now beneath the surface. In fact, because users can’t discern all of the available options, overflow menus frequently make interfaces even more difficult to use.

Google Image search is crushing it with side-by-side overflow menus. The poor puppy on the right wants off this train wreck.

Just look at Google Image search. Instead of choosing whether to have a very simple interface or to have a set of powerful tools, the team split the difference. You can just imagine someone making the compelling argument:

Hey guys, I’ve got the ultimate solution. By hiding the advanced options using an overflow menu called Search tools, Google Image search will be both powerful and easy-to-use! Also, people feel overwhelmed by all of our search options, so we’ll intelligently hide the Books, Flights, and Apps ones under a More▼ menu. A perfect compromise.

Sounds great. In reality, after years of daily use, I still can’t reliably choose the correct option. I just want to filter my images for big file sizes, and I know that there is a menu hidden away here somewhere, but I constantly click More when I guess I should click Search tools. Argghhh!

Android embraced overflow menus so deeply that it’s a default user interface element in the action bar. On any given screen of an app, you’re likely to get a different grab bag of menu options. Some things like Settings or About might appear in the overflow menu on every screen of an app. And, others like Delete post will be context specific to the screen that you’re looking at. They are all mixed together in a noxious potpourri: it’s a total mess.

I’m mostly snarking on Google’s implementation of overflow menus because I work at an arm of the company. I know many of Google’s designers are excellent and it’s safer to pick on your friends than to trash strangers. Of course, overflow menus are spread like a plague in apps designed by all kinds of teams, not just at Google. And, it’s not like I have never made compromise decisions that I later regretted, but sometimes it’s good idea to throw stones in glass houses. And, tellingly, some of the default apps on Android have recently moved away from using overflow menus. The Play Store, for instance, used to have zillions of them and I recently opened the app only to notice that the overflows have been nixed in favor of a more intuitive and streamlined interface. Nice.

So, if Google has some talented designers why have overflow menus often still run amok even here? Let’s look at how bad things happen to good teams and how to avoid it happening to your team:

Obfuscation ≠ Simplification
Designers frequently confuse obfuscation with simplification. Simply hiding features seems like you’re creating a “cleaner” and more easy-to-use interface. Sure, your new UI may pass the squint test of simplicity but you’re not dealing with the core complexity of your app.

Instead using obfuscation or sleight of hand, our job as designers is to structure complexity so it’s easily understood. The problem with overflow menus is that there is no information scent — anything from a juicy steak to a gross licorice could be hiding under that menu. Instead of adding an overflow, consider these options:

1. Remove the feature. If 0.001% of people will find it in an overflow, did you really need it?
2. Add the feature for real. Don’t dither. Put it on the page. Scrolling is the easiest mode of navigation.
3. Structure the complexity, don’t just hide it. Use a meaningful icon or clear label to indicate a group of features is available. Seriously though, “More” or “Menu” or “…” are not clear labels.

Acknowledge that you’re using a crutch
Admitting you have a problem is the first step to solving it. Many teams don’t acknowledge that using an overflow is a crutch, a way to avoid making a tough choice. I’m sure sometimes you will consciously choose to use an overflow menu (I’ll even grudgingly admit to having used one before) but don’t let the choice become an easy out.

Force yourself and your team to make tough choices
This is really the point. Instead of pretending to make your product simpler, actually make the tough call to include or not include menu options. If something is important enough to include, show it to customers. One of the best parts of designing mobile-first is that you’re constantly forced to make tough choices about what to include and what to leave out (this is particularly true on iOS, which doesn’t have a built-in overflow menu in its toolkit). Take this as a challenge instead of a hampering constraint.

Be contextual
Overflow menus are most egregious when they lack context. In Gmail, for instance, the Print function could live under either of two overflow menus. In Android, the persistent overflow menu in the top right of the action bar can contain global or local menu options. In Google Images, two side-by-side, unrelated overflow menus conflict with each other. Overflow menus can work when used really contextually. Consider the example from the Android alarm clock app, left. The overflow menu in the top right lacks context (it could be about anything) but the overflow menus on each individual row gives some indication about what you might find under the surface because it’s contextual to a specific alarm.

Research keeps you honest
One excellent way to stem the tide of overflow menus is to do user research. In the confines of our design studios, solutions like overflow menus seem perfect. Putting your product in the hands of regular human beings and watching them struggle through the interface you designed is the ultimate sobering gut check. Your “clean” user interface likely confuses the hell out of your users. Unless you and your team are a bunch of cold-hearted SOBs, empathizing with your users’ struggles should convince you to find better solutions.

Consider information foraging
If my bombast above is obnoxious to you, consider a more academic perspective on why overflow menus are, uh, suboptimal. There is a popular theory called Information Foraging that is often used to describe why some interfaces are better than others. You can read a thorough and useful explanation of Information Foraging at the Information Design Organization here, but the basic gist is:

Information foraging theory is based on the analogy of an animal deciding what to eat, where it can be found, the best way to obtain it and how much “energy” (how filling) the meal will (be) provide… Imagine a predator, such as a bird of prey, that faces the recurrent problem of deciding what to eat, and we assume that its fitness, in terms of reproductive success, is dependent on energy intake. Energy flows into the environment and comes to be stored in different forms. For the bird of prey, different types of habitat and prey will yield different amounts of net energy (energetic profitability) if included in the diet. http://bit.ly/InformationForaging

In a gross over-simplification, according to this Information Foraging theory, something either has to be damn worth the effort of seeking it out (high value) if it’s going to be hard to find. Or, if the thing has lower value it has to be presented in a context that makes it easier to locate.

In a concrete example, consider the hidden options in Google Image Search. I have been using this interface for years to filter for “large” images in search results and yet I have neither learned the interface nor have I given up and used a different image search. Both the frustration and my continued use of Google Image Search can be explained by the Information Foraging theory. On the one hand, the Search tools link is not presented with any real context, so I find it hard to locate and confusing — heck it’s right next to a More link that serves a completely different purpose! On the other hand, I am not so frustrated with the complexity that I give up. I come back and stub my toe at the door time and time again. That’s because the food is so damn tasty. It’s a good search tool and the filter for “large” images is super useful for my work. I wish it didn’t taste so good or, better yet, I wish the tasty food was right at the surface.

You said never use overflow menus? Like never ever?
Like just about anything, overflow menus have a time and a place where they don’t totally suck. But, the appropriate place for an overflow menu is probably not your project and probably not the spot you’re thinking about. So, think long and hard before you resort to using one.

Over 100 links to the best books, courses, newsletters, and tools out there…

This is a continually updated list of the best UX resources.

Last updated 3/17/2016

Over the years I’ve collected a ton of different resources to help me with my product & UX work. I’ve signed up for dozens of newsletters and blog emailers, purchased a bunch of books, checked out some online courses, and have used a wide range of tools to help me bring my ideas to life. Finally, I decided to go through all of my bookmarks, emails, and text files and put of all these resources into a comprehensive list.

Enjoy!

UX Newsletters

The Mailchimp UX Team’s Newsletter

• Mailchimp UX Newsletter
• UX Mastery Newsletter
• UX Weekly Newsletter
• UX Booth Newsletter
• UX Design Weekly Newsletter
• Smashing Magazine Newsletter
• Userfocus Newsletter
• UX Notebook Newsletter
• My Daily Newsletter ?

UX Blogs & Magazines:

Boxes and Arrows — A Terrific UX Blog

• InfoDesign
• WebCredible
• Adaptive Path Ideas
• Nielsen Norman Group — Articles
• UX Magazine
• Boxes and Arrows
• A List Apart
• UX Matters
• Intercom Blog — Design
• HeyDesigner
• UIE Brainsparks
• Form and Function
• Bokardo
• UXHandy
• UXSwitch

Books:

• Don’t make me think — by Steve Krug
• Rocket Surgery made easy — by Steve Krug
• Observing the user experience — by Mike Kuniavsky
• Design of everyday things — by Don Norman
• Hacking Human Nature for Good — by Dan Ariely, Jason Hreha, and Kristen Berman
• Persuasive Technology — by BJ Fogg
• UX for Beginners: A Crash Course in 100 Short Lessons — by Joel Marsh

Online Courses

52 Weeks of UX — A Great (Free) Intro UX Course

Free:

• 52 Weeks of UX — by Joshua Porter and Joshua Brewer
• User Experience Design — by Springboard
• UX Crash Course — by The Hipper Element
• ProductPsychology — a course by Nir Eyal & others (and me!)
• Human Computer Interaction — by Scott Klemmer (Stanford Coursera)
• How to run a cheap, fast, and incredibly useful user test— by Jason Hreha (Short intro)

David Travis’ Udemy Course — One of the best online UX courses

Paid

• The Ultimate Guide to Usability and UX — by David Travis (I’ve heard this, perhaps, the best online UX course)
• Usability Testing Boot Camp — by David Travis
• UX: The Practical Essentials of Real World UX — by Brendan Bolton-Klinger
• User Experience Design Fundamentals — by Joe Natoli
• UX and Web Design Master Course: Strategy, Design, Development — by Joe Natoli
• Interaction Design Specialization — on Coursera
• UX & UI Fundamentals — by Bloc
• Become a UX Designer — by Thinkful
• UXTraining — by Colman Walsh
• Become a UX Designer — by CareerFoundry
• Conducting Smart User Research — by Janelle Estes
• Creating Great Omnichannel Experiences — by Stef Miller
• Fundamentals of Usability — by Marieke McCloskey
• User Experience Design: Complete UX Fundamentals Course — by Adam Treister & Pablo Stanley
• Mobile App Design From Scratch: Design Principles, and UX — by Maxime Cormier
• How to Build Habit Forming Products — by Nir Eyal
• Winning User Experience Design — by Oxford Learning Lab
• Design Your User Experience in 7 Simple Steps — by Amir Khella
• Information Architecture with Card Sorting — by U1 Group/Joji Mori
• Interaction Design — by DesignLab
• UX Basics — by Lis Hubert @ Treehouse
• Courses by the Interaction Design Foundation

Discussion Groups

UX Q&A on StackExchange

• Stack Exchange — User Experience
• Reddit — User Experience

Software

Invision — One of the best prototyping products

Prototyping

Need to quickly create a robust prototype of your product with your mockups? These are the tools for you.

• InVision
• Marvel
• Silver
• Pixate
• Proto.io
• POP
• Fluid
• Prott
• CanvasFlip
• Flinto
• Notable (Zurb)
• Axure
• Indigo Studio
• Principle

Zurb’s Testing Product — Notable

Testing Services

If you need to get your designs (or prototypes) in front of users, and gather their feedback, these are the tools for you.

• Notable (Zurb)
• FiveSecondTest
• Sprint (by dscout)
• Usertesting
• Usersthink
• UsabilityProvider
• UsabilityHub
• Userbrain
• Userbob
• Userzoom
• 99Tests
• UXeria
• Validately
• Userfeel
• TrymyUI
• Userlytics
• Whatusersdo

Delighted — An elegant way to gather NPS

Feedback Collection

Want to get a rough sense of how you’re doing? Feedback collection tools like Delighted and Usabilla can give you a sense of how you’re doing on a scale of 0–10 or “sad face” to “ecstatic face”.

• Usabilla
• Delighted — NPS
• Wootric
• Intercom
• AskNicely
• Qeryz
• Promoter.io
• CustomerGauge
• SatisMeter
• Satmetrix
• Hellocustomer
• NetPromotive

Record & review user sessions

The first time I saw FullStory, I thought: “My god — I don’t need a user research coordinator anymore.” While that’s not true (I love research coordinators), these tools should be a part of every product team’s arsenal.

• Fullstory
• UXCam
• UsabilityTools

Card Sorting

Bad information architecture? Start here.

• OptimalSort
• TreeJack

Surveying

Get qualitative feedback from your users with a surveying tool.

• Qualtrics
• Wufoo
• SurveyMonkey
• SurveyGizmo
• Typeform
• Pickfu

User Research Recruiting

Ethnio owns this category. If you want visitors to your site or app to be screened and added to pre-defined user-research groups, this is the tool for you.

• Ethnio

If you like this piece, please sign up for my daily newsletter. ?