I know why you set that link to open in a new tab.

The link goes to another website, and you want people to be able to get back to yours. Opening it in a new tab seems helpful. Your website stays open, they get what they eed, everybody wins. Right?

Nope. The person who clicks the “Back” button and can’t figure out why it won’t take them back. That person now has a problem you created while trying to help. And that’s only the beginning of the potential obstacles you just created for your site’s users.

“But…I like opening links in new tabs!” you say. Well, open them in new tabs! I do it, too. Your browser gives you ways to make that choice. The trouble starts when we decide that everyone else should browse the way we do.

Someone who follows a regular link can choose to open it in another tab. Someone who follows a link that forces a new tab has already had that decision made for them. And they may not realize it happened.

You’re creating multiple usability issues

Nielsen Norman Group identifies disorientation, extra clutter, and the effort of managing multiple tabs as reasons to avoid forcing them on people. Its research found that mobile users were particularly frustrated when they couldn’t use “Back” to return to the previous page. In short, forcing links to open in new tabs is a hot mess usability-wise.

Think about following a library link to a museum’s website to check its hours. You find the answer and want to return to the library page. But “Back” doesn’t take you there, because you’re now in a totally different tab.

If you noticed the new tab, fine. If you didn’t, you get to figure that out before continuing with whatever you were actually trying to do. Checking museum hours should not require browser troubleshooting.

You’re creating multiple accessibility issues

Unexpected changes can make a website harder to use, particularly when someone can’t easily see what changed. People with disabilities use tabs. The issue is whether they get to control what happens, or have to deal with a surprise your website arranged for them.

W3C’s accessibility guidance on new windows and tabs explains that opening them without warning can disorient people who have difficulty perceiving visual content and some people with cognitive disabilities. The person may not understand that they need to switch tabs to return to where they were.

Someone using screen magnification may miss a new window opening outside the area they can see. Nielsen Norman Group specifically calls out this problem.

And a screen reader announcing a new window after someone activates the link isn’t the same as telling them beforehand. WebAIM recommends giving people advance notice so they know what to expect.

An external link doesn’t need special treatment just because it’s external

“It goes to another website” is probably the explanation I hear most often for opening a new tab. But why should the ownership of the destination determine how someone’s browser behaves?

A person might want to check something quickly and come back. They might want to spend the next hour using the resource you linked to. They might want to compare it with three other resources. You don’t know.

Nielsen Norman Group advises against making this decision solely on whether a link is external or leads to a particular file type. What matters is the person’s task and what they need to do next.

And if the concern is that people will leave your website? Sometimes leaving your website is the successful outcome. You linked them to the database, organization, or service they needed. They went there. Good job. You don’t need to keep a tab open as a souvenir.

TL;DR: Let people manage their own tabs. They already have enough things to keep track of.

You know the one. Sometimes the books have a pair of glasses sitting on top. Sometimes there’s a coffee cup nearby (because it’s generic and is probably better suited to a coffee shop). It’s a perfectly okay picture. But what is it doing there?

You might think that question isn’t worth asking. It’s “making the page look better!” you might answer. But it’s worth considering, especially if visitors have to scroll past it to get to something actually useful.

It’s time to ask that picture a hard question

A picture of books looks appropriate on a library website. So does a person holding a tablet, a child reading, or a person using a computer. But “this relates to libraries” is a pretty low bar. Your website already has the library’s name on it. Users probably don’t need additional pictorial evidence to prove the site belongs to a library.

What they likely need to know are things like whether the library is open, when story time is, or where to park during construction. A generic picture can occupy a lot of space without helping answer any questions.

Imagine a page about your library’s meeting rooms. At the top is a large stock photo of smiling people gathered around a conference table. Below it, eventually, are the room details.

Now imagine replacing that image with a photograph of your actual meeting room.

Visitors can see the tables, seating, windows, and general arrangement. They have a better idea of whether the space will work for their group. Same kind of page, but with a much more useful picture. That picture is now doing a very useful job.

Is your image doing useful work, or wasting people’s time?

Pictures need to earn their keep

An image can show someone what to expect, help them recognize a place, or explain something that would be more difficult to describe.

A picture of a book locker could help someone recognize it when they arrive. A close-up of a craft project could help a parent and child decide whether they want to attend. Those pictures answer questions. “Here is a stack of books” usually doesn’t. Stock photos and AI-generated art don’t tell anyone anything useful and can even turn people away.

And yes, ambiance can count for something. A photograph of people enjoying your library can make it feel welcoming. Your website doesn’t have to remove all the pictures. That’s not the point.

But, be honest about what a particular image truly contributes. “It makes this page feel welcoming” is a reasonable answer (again, as long as it’s a real picture and not something generic). “The template had a spot for a picture” or “I wanted to jazz up the page, it looked boring” are not convincing reasons for anything.

Try this

Choose one page on your website. Look at its main image and ask: “If this picture disappeared, what would visitors lose?”

Would they lose information? A useful view of a space? An example that helps them understand the page? Or would they reach the information they came for sooner?

If removing the image would cost visitors nothing useful, you have the answer. Get rid of it. Just looking relevant isn’t the same as being useful.

1. It’s subjective. There is absolutely no consistency in what one library likes compared to another. When I talk to a client library about our current design portfolio, I ask them which sites they like and which they don’t, and why. It helps me to get a feel for the style they’re after and which elements they find attractive. I can’t count the number of times one library has told me they love Library X’s site, only to have another library tell me, even the very next day, that they don’t like Library X’s site and can’t imagine why Library X would have done it that way. This is true in libraries, even internally. There have been times when the library’s staff liaison likes a design draft a lot, only to have that design shot down by the library’s director. Or, there’s a committee and the members can’t agree on what they like. It’s the nature of the beast: design is subjective (although functionality, accessibility and usability is not). Chances are, no design is ever going to make everyone entirely happy. And, that’s in addition to the fact that some patrons will hate the new site design, no matter how carefully planned, simply because it’s not the old one.

2. Nobody uses most of it. As librarians, sometimes we can get mighty attached to those pathfinders, booklists and lists of links. After all, we put a lot of work into those, right? So lots of people must be using them, of course...not. Take a look at the metrics. Chances are, you’re going to be unpleasantly surprised. You know what people come to the library’s website for, in general?

   • Access to their account

   • Search the catalog

   • Phone number and address

   • Program information

   Anything else is pure frosting. There are always exceptions; sometimes, genealogy resources on a library’s site, for instance, can be heavily used. Maybe your library is one of the lucky ones that has a niche audience for a specialized content section. But, there aren’t many. Don’t believe me? Go look at your website analytics. See how many page views there are for that list of homework help links, especially from outside of the library. Figure out how much it cost, in staff time, to put that list together. (You may need a stiff drink at this point.) Does that mean it’s not worth doing these? Maybe. But that’s what the math is for. Everything that happens in a library has a cost.

3. You’ll hate it later. I’m old enough to remember when orange shag carpeting was all the rage, and avocado green appliances were in kitchens everywhere. Now, hardly anyone would probably choose these to decorate their home. Design trends change and, on the web, they change fast. Remember textured, tiled backgrounds? Animated, cartoony GIFs? Flash animations? 3D buttons? Glass reflections? Rotating carousels? None of these trends were all that long ago, but are all outdated now. I regularly tell clients that, in anywhere from 2-5 years, they’ll likely come to hate whatever they love now. Even if the site design wasn’t all that “trendy” to begin with, there’s nothing like the “Little Black Dress” of the web, that always looks good and is a classic, regardless of era. At least, not yet. A hard lesson that I have learned over the years is to not to get emotionally attached to much of anything that I do. Even *I* will despise it at some point down the road. Just like that orange shag carpeting.

What are your thoughts on these? Agree? Disagree? Everyone’s experiences are different...post yours.

Before I get too far into the weeds, I want to express my gratitude that rotating banners/carousels have finally become a dated element stylistically. I’ve been standing and yelling on this particular soapbox for almost two decades. Unfortunately, library websites have often been hangers-on to many poor web practices, and carousels can still be seen on a good number of library websites even now. Please remove them so I can stop shouting about them already.

It’s not hard to understand why libraries still cling to rotating banner elements. They seem to solve a difficult problem: five departments have something important to promote, but there’s only one prominent spot on the homepage. Put everything in a rotating carousel, and everyone gets a turn.

It’s hard to navigate these mini turf wars, so tools like carousels are used as appeasers to keep everyone from beating the shit out of each other.—Brad Frost, UX expert

Unfortunately, visitors don’t experience a carousel as a fair distribution of homepage space. They see the first slide…maybe. They likely never see the others. And if the slides move automatically, the one they were reading can disappear before they’re finished.

The Problems

Automatic rotation creates problems beyond missed promotions. Motion can be distracting. A visitor reading a slide may lose their place when it changes. On a phone, a large carousel can occupy most of the screen while making its other slides even less apparent. The Nielsen Norman Group’s research on automatic carousels describes how advancing content reduces its visibility and can frustrate people trying to use it.

There’s an accessibility obligation, too. Under WCAG 2.1 success criterion 2.2.2, Pause, Stop, Hide, automatically moving content that lasts more than five seconds and appears alongside other content generally needs a way to pause, stop, or hide it. The W3C carousel tutorial also explains how to make carousel controls usable by keyboard and understandable to assistive technology. Meeting those requirements takes expertise and testing. It still doesn’t make a carousel the best way to organize a library homepage.

And then there are the graphics. Unless someone has the time and skills to do them well, a carousel can quickly become a parade of stretched photos, tiny text, competing fonts, and flyers squeezed into the wrong shape. The most useful information often ends up embedded in an image, where it’s harder to read on a phone and likely unavailable to assistive technology. Large images in a carousel can make it very clear, very quickly, that the library doesn’t have any available graphic design talent. And users key into that information the minute they hit the page that carousel resides on.

If five announcements all need the “top spot,” that’s a conversation that needs to be had about priorities. A carousel doesn’t automatically settle it. It just hides the disagreement behind a widget.

Could a carefully designed, manually controlled carousel work? A guarded “maybe.” But before adding one, ask a more powerful question: Wouldn’t these links and announcements be easier to find if we just showed them on the page? For most library homepages, I think the answer is yes.

OPLIN Webkits are designed to keep library websites consistent, accessible and professional. Allowing editors to freely change font sizes and colors works against all of those goals.

Font size has to mean something

On a well-structured website, larger text isn’t just decoration: It usually communicates hierarchy, which is especially critical for accessibility.

A page title is an <h1>. A section heading might be an <h2>. A subsection might use an <h3>. Regular content is a paragraph. That kind of structure helps people scan a page and understand how the information is organized. It also gives screen reader users meaningful navigation for the content.

If editors can simply make a paragraph 24 pixels tall because they want it to “stand out,” it may look like a heading without actually being one. That creates a visual hierarchy that doesn’t match the underlying page structure. It also tends to lead to the digital equivalent of a ransom note: 18-point text here, 22-point text there, something enormous and bold in the middle because it was deemed really important. In other words, an unprofessional-looking mess.

Color causes yet more trouble

Giving editors unrestricted text-color controls makes it amazingly easy to create inaccessible content.

Text needs sufficient contrast against its background. Under WCAG 2.1 Success Criterion 1.4.3: Contrast (Minimum), normal text generally needs a contrast ratio of at least 4.5:1, while large text needs at least 3:1. A color that looks perfectly readable to one person may be difficult or even totally impossible for someone with low vision or a color-vision deficiency to read.

And, once arbitrary colors are available, they tend to multiply like rabbits. Red for this announcement. Blue for that program. Purple because someone likes purple. Soon, the website no longer has a coherent look or feel, adding to an unprofessional aesthetic. And, probably nobody is checking whether every combination actually meets accessibility requirements.

We’re not trying to be mean

The goal here isn’t to prevent creativity. It’s to prevent every new page from requiring new design decisions. Without problematic font controls, site content editors can concentrate on the thing that actually matters: the content.

Say I’m looking at your library’s website on my phone because I need to call and ask about something. I find the number. Awesome!

Except I tap it and…nothing.

It’s just text.

So now I’m supposed to remember the number while I switch over to the phone app? Or carefully select it, copy it, open the phone app and paste it there? Maybe. Depending on how cooperative my phone is feeling at that particular moment.

Why? The phone number is already on a phone.

This is such a small thing. Which is probably why it annoys me so much when websites get it wrong.

If you put a phone number on your website, make it clickable.

Make the number do something

A clickable phone number lets me tap it and call. Done.

That’s what a tel: link is for:

<a href="tel:+12165551234">(216) 555-1234</a>

And this is not some new bit of HTML that nobody has gotten around to implementing yet. The standard for telephone links, RFC 3966, dates back to 2004.

The standard also recommends using the actual telephone number as the linked text, which makes sense. If I see (216) 555-1234, I already know what I’m about to do when I activate it.

Is this an accessibility requirement?

There is no WCAG success criterion that says every phone number on a website must be clickable. But accessibility and usability don’t suddenly stop mattering just because you can’t point to a specific WCAG failure.

Think about what the unlinked version asks someone to do: remember a string of numbers, switch applications, re-enter those numbers accurately or manage the fiddly business of selecting and copying text on a small screen.

Some people are going to have more difficulty with those tasks than others. And there’s no reason to make any of them do it.

You probably don’t need to know HTML

Most content management systems let you make a phone number clickable exactly the same way you make other text into a link.

Select the phone number. Click the link button. Instead of entering something beginning with https://, enter:

tel:+12165551234

That’s it. Seriously. That’s the fix.

Go look at your website

Find the phone numbers. Try tapping them.

Do they actually do anything?

If not, you have a very small usability problem that is also very easy to fix. Those are my favorite kind (and maybe yours!).

That’s a real problem when you’re trying to evaluate a library website.

Staff may look at a navigation menu and think, “Of course someone looking for downloadable audiobooks would click Digital Resources.”

But… would they?

Maybe they’d click “Books & More.” Maybe they’d look for “Audiobooks.” Maybe they’d type “download books” into the search box. Or maybe they’d just give up.

The problem is, if you work at the library, you can’t really answer that question. You already know what the labels mean. You know where things live. Your users don’t.

Let someone else try it

Actual usability testing doesn’t have to mean hiring a research firm or building a lab with one-way glass. You really can learn a tremendous amount by putting a website in front of just a few people who don’t work in the library and giving them realistic tasks.

In a public library, those tasks might look something like this:

• “Find out whether the library has Consumer Reports.”

• “See if you can reserve a meeting room.”

• “Figure out what time the library closes Saturday.”

• “Find an eBook version of To Kill a Mockingbird.”

Then stop talking and watch. Don’t cue them. Don’t explain anything. Don’t rescue them if they seem stuck. Nothing.

This can be seriously eye-opening.

Where did they click first? Did they even use the menu, or did they go straight to the site search? What did they completely miss? What made them stop? Where did they backtrack?

Those behaviors can tell you a lot more about how people actually use your website than a room full of staff saying, “I think that makes sense.”

Your expertise is useful, but it’s also a blind spot

Knowing your library inside and out is part of being good at your job. It is also exactly what makes it hard to experience the website the way a patron does.

So when you want to know whether people can actually use the site, bring in people who don’t already know how. It’s probably the simplest kind of usability testing a library can do, and it is absolutely worth it.

All caps is one of those design choices that seems harmless. It might make a navigation menu look uniform. Maybe it makes a heading seem more important. Unfortunately, it can also make both of them significantly harder to read.

Here’s why

When we read, we tend to recognize familiar patterns very quickly. Lowercase letters have different shapes, with ascenders and descenders that make words visually distinctive. ALL CAPS REMOVES MOST OF THAT VARIATION. (See what I did there?) The words become more uniform, which can often make them more difficult to recognize.

Harvard’s Digital Accessibility Services specifically recommends avoiding all caps because it reduces readability, and notes that all-caps typography can be more challenging to read. For some people with cognitive, learning, or visual disabilities, you’ve made reading unnecessarily harder. Why would we do that?

All caps navigation is especially terrible

Navigation labels are supposed to be scanned rapidly. A user looking for Events, Research, or Contact Us shouldn’t have to spend time decoding EVENTS, RESEARCH, or CONTACT US.

One ALL CAPS word? Maybe not a huge deal. But your navigation doesn’t have one word in it, right? It has five, six, eight or more labels, all competing for quick recognition. Now you’ve made the entire menu harder to scan.

The same idea applies to headings. Headings exist partly to help people scan a page fast and understand its structure. Making them possibly harder to recognize works against the reason they’re there in the first place. (There are better ways to do headers; a post for another time, perhaps.)

Is all caps a WCAG violation?

Technically, no. There is no WCAG 2.1 success criterion that says you can’t use all caps. And this is where I think people sometimes get accessibility wrong. “It passes WCAG” does not automatically mean “this is a good, accessible design choice.”

WCAG is a baseline, not a catalog of every possible way to make something harder for people to use. All caps can make text more difficult to scan and recognize even though an automated accessibility checker will just ignore it.

So, yes, your ALL CAPS navigation may technically pass WCAG. I still want you to stop doing it.

A really easy fix

Simplest fix ever. Don’t use all caps. Ever. With only one exception: acronyms. Those should be all caps. But not your site’s headers, navigation or other text. This is a really easy win for not only users with some types of disabilities, but for literally everyone that uses the site.

Remember: Libraries are about providing information. If people can’t access our information, what are we even doing?

Libraries love putting their buildings in their logos. I understand why. The building may be historic, beloved, or one of the most recognizable places in town. But being meaningful does not automatically make it a useful logo.

In fact, the more architectural detail a library tries to preserve, the less useful the result usually becomes.

A picture shows what something looks like. A logo identifies an organization. Those two jobs are not the same.

A Logo Has to Work Much Harder

A photograph of your building may look perfectly fine at the top of your website. It may also work well in scenarios like a brochure, annual report or social media post. But a logo has to work with much less forgiving conditions, such as:

• On a library card

• On a mobile screen

• In an email signature

• On a printed envelope

• In black and white

• On a sign viewed from across a parking lot

• On a pen, tote bag, button, or name badge

A detailed photograph or architectural illustration usually falls apart when it is reduced to the size of a postage stamp. I have seen library logos that include every window, column, tree, stair, and lamppost in front of the building. At website-header size, most of that detail disappears. Many details turn into visual clutter and the image may become little more than an indistinct blob. A logo should become simpler and clearer when viewed at a small size, not harder to understand.

Recognition Is Not the Same as Identification

Library staff sometimes defend a building image by saying, “Everyone recognizes our building.”

Maybe they do. But which everyone?

Longtime residents may recognize it. New residents may not. People who use digital library services but rarely enter the building probably won’t. Visitors from a neighboring community almost certainly won’t.

A person shouldn’t have to recognize the building before the logo makes sense. The logo is supposed to create recognition.

Your Library Is More Than Its Building

There is also a larger problem with using the building as the logo: it defines the library by its real estate.

A public library is not just a physical place. It provides crucial services, many of which can be accessed online. When the building becomes the library’s primary symbol, it quietly suggests that the physical place and what it provides are the same thing.

They are not. The building houses the library. It does not define the full scope what the library actually does.

Your Building Still Has a Job

None of this means you should stop using photographs of your library building. Good building photography can still help people to recognize the location and feel more comfortable before visiting.

Use the building on your website’s location page. Feature it in community stories. Include it in historical materials, reports, or social media posts. Just don’t ask it to be your library’s logo.

A photograph documents a place. A logo identifies an organization. And, your library needs both! It just should not confuse one for the other. Remember: Loving the building is not a design strategy.

In libraries, we love the word “resources.” We have electronic resources, community resources, research resources, local history resources, homework resources, genealogy resources, business resources, legal resources, and probably at least a dozen other flavors of resources hiding somewhere on our websites. And, that, folks, is the problem.

“Resources” has no true specific meaning. To us, “Resources” may feel like a useful umbrella term. But, to users, it often translates to: “Here’s a mystery option. Good luck!”

What the data says

Users rely on navigation labels to decide whether a click is worth the effort. In user experience (UX) terms, those labels provide “information scent.” A strong label gives users a reasonable clue about what they will find if they follow it. A weak label makes users guess.

NN/g’s research on how people read and scan online notes that users are usually trying to finish tasks quickly and with minimal effort. They scan for meaningful links, headings, and other cues that help them decide where to go next. When the words on the page offer weak information scent, users are less likely to keep reading or follow the path in front of them.

“Resources” is a very weak scent. It doesn’t tell the user what they will find. Worse, it can mean different things on different library websites, so even experienced library users cannot reliably predict what is behind it.

Our meaning is not the user meaning

Inside libraries, “resources” is a comfortable word. It sounds broad, helpful, and professional.

But users usually come to a website with a task in mind:

• “I need to renew my books.”

• “I need homework help.”

• “I need ebooks.”

• “I need the library’s hours.”

• “I need a study room.”

• “I need legal forms.”

• “I need to print something.”

Pretty much nobody comes with “I wonder where the resources are.” That mismatch matters. Good navigation is not about what staff call things internally. It is about what users recognize when they are trying to get something done.

Poor navigation labels like “Resources” can significantly increase the cognitive load. Now the user has to spend time trying to interpret something, which is an obstacle to completing the task they came to do. Interpretation takes takes time the user doesn’t want to spend.

When a navigation label requires that much interpretation, it’s not helping anyone. Instead, it’s offloading the website’s organizational problems onto the user. And users are not on your website because they want to admire your organizational structure. They are there because they need something.

What to use instead

I think we’ve established that simply using “Resources” is terrible. That might lead you to ask: “Well, can’t we just use “Genealogy Resources?” That’s certainly a step up, but doesn’t really solve the problem. Let me ask you this: what’s wrong with simply “Genealogy?” Or, “Homework Help?” What is truly being added by tacking on the word “resources,” when studies are pretty clear in that it’s a poor navigational aid?

“Resources” is one of those words that feels clear only because library staff have been using it forever. But familiar is not the same as useful.

A good navigation label should help users make a confident choice. It should point toward a real destination, not gesture vaguely at a pile of possibly useful things.

So yes, your library has resources.

That does not mean your website needs a link called Resources.

Hick’s Law is a simple idea with big consequences: the more choices people have, the longer it takes them to make a decision. I often explain this by asking the person to imagine they need to buy ketchup, and now they’re standing in the ketchup aisle at the grocery store. If they’re not already committed to a specific brand or type, how many options do they have to choose from? The answer is almost always “too many.” It can take them more time to determine what might be the best choice for their needs.

Library websites are especially vulnerable to this problem because libraries do a lot. Catalogs, databases, events, meeting rooms, research help, library cards, ebooks, museum passes, genealogy tools, printing, outreach services, and on and on. Every one of these things matters to someone. But when everything is treated as equally important on the homepage or in the main navigation, the result isn’t helpfulness; more likely, it’s outright chaos.

That does not mean every website needs to be stripped down to three giant buttons. It does mean that when we throw too many options at people at once, we make them work harder than they should. This is what UX (User Experience) pros call “too much cognitive load.” Think of every additional option as an overload tax on your site users’ brains you probably didn’t mean to collect.

This is where Hick’s Law becomes useful. A homepage with twenty competing calls to action does not give users “more access.” It gives them more decisions to make before they can even get started. Which button is for ebooks? Is “research” the same as “databases”? Is “services” where printing lives? Each unclear choice adds more friction. Enough friction, and users typically give up and assume the site does not have what they need.

For library websites, the answer is not to hide everything. The answer is to organize choices around what users are most likely trying to do. Put the highest-demand tasks in predictable places. Group related items. Avoid turning the homepage into a bulletin board for every department. Navigation is not dumping ground: it is entirely a decision-making tool for the user.

Hick’s Law reminds us that “more” is not automatically better. More buttons, more homepage panels, and more menu items can create the illusion of usefulness while actually making the site harder to use. A good library website doesn’t make users admire how much the library offers. It helps them find the thing they came for, quickly and without needing to decode the interface first.

Maybe you or your PR person spent a lot of time on that flyer. Perhaps it required several rounds of proofing and approvals. It might look absolutely stunning. But, no matter how good it looks, it doesn’t belong on your library’s website.

Posting a flyer as a PDF may feel like the fastest way to get event information onto a website, but it creates significantly more problems than it solves. A flyer is designed to be glanced at on a wall, bulletin board, table, or on a social media feed.

A website is different.

People come to a website looking for specific event information: what the event is, when it happens, where it is, who it is for, whether registration is required, and what they need to do next. When all of that information is locked inside a flyer, especially one designed as a visual poster, the website isn’t being helpful: it’s acting like a filing cabinet. One that almost no one is going to bother to go through. And the problems for users begin to pile up.

• PDFs are inherently inaccessible, especially when they are mostly images of text. If the flyer was designed in Canva, Photoshop, or another design tool and then exported as a PDF, there is a good chance the actual event information is not real, selectable, properly structured text. That creates barriers for people using screen readers, people who need to enlarge text, people using high contrast settings, and more.

• PDFs are a mess on mobile. If you’ve ever had to deal with a PDF on your phone, then I probably don’t need to elaborate here. It’s an awful user experience. A poster that looks decent when printed often becomes a tiny, pinch-and-zoom nightmare on a small screen. Users may have to scroll sideways, zoom in, zoom out, and drag the page around just to find the date or registration link. That is not a minor inconvenience. Personally, I’ve gotten to the point where I almost refuse to open PDFs on my phone at all.

• Mobile users are not special edge cases anymore; they are often the majority of your site’s audience. That means that users with disabilities not only have all the usability challenges inherent to PDFs, but it all becomes exacerbated on mobile. WCAG 2.1 partially addresses this through Success Criterion 1.4.10: Reflow, which is about making sure content can be presented at small viewport widths without forcing users to scroll in two different directions. That means PDFs are almost always going to violate 1.4.10 on a mobile device.

• PDFs are terrible for search and SEO. Search engines, site search tools, and users all do better when important event information exists as HTML directly on the page. A page with a real title, headings, date, time, location, description, registration link, and contact information is far easier to find and for search engines to scan. If all of that information is locked up in “preschool-storytime-at-the-library.pdf,” it’s not exposed to outside search tools. At all.

Your website should not make people decode a poster. It should give them the information they came for, in a way they can access it. I know you really liked the flyer’s design but, remember: Libraries are about providing information. If people can’t access our information, what are we even doing?

There are some websites that are useful. There are some websites that are pretty. And then there are websites that stare directly into your soul and say, “Congratulations, you are now approximately one million years old.”

Welcome to You’re Getting Old!, a funny yet slightly grim website that turns your date of birth into a personalized report on how much time you probably don’t have left.

TIME wrote about it back in 2014, describing it as a site that calculates detailed age-related statistics from your birthdate and shows world events from your childhood/lifetime.

The site is very much still around, providing birthday-based data visualizations with a hefty dose of nostalgia (with no AI, btw).

When I first found this site, I thought, “This should be fun!” And it is, mostly. But then I got to the part about the total number of candles that have appeared on my birthday cakes over the years, and that silly number made time feel a little more real. That’s what makes You’re Getting Old! work so well: it starts out as a goofy little diversion, then quietly hits you with the fact that, yes, the years really are piling up.

Maybe we should be eating more cake?

Hopefully, by now, everyone understands how important search is on a website. For many users, it is the last resort when they can’t find what they need in the main navigation. (And, in my experience, library navigation labels are often not especially helpful.)

For other users, search is the starting point. They skip the navigation entirely and expect the search feature to act as an answer engine.

Either way, a website’s search function is a mission-critical feature. But simply having a search box on your library’s website is not enough. There is a lot of research about what makes site search effective, and in this post I want to focus on one issue I see libraries overlook all the time: search placeholder text.

If you’re not sure what I’m referring to, take a look at this image:

The text in the red oval is called “placeholder text.” It’s any text that appears in a search field before the user has typed anything. For years, I included this in my own designs. I assumed, probably like most others, that this text was helpful to users. Turns out, it’s definitely not.

In 2014, The Nielsen Norman Group studied how users interacted with placeholder text. Across the board, it found that placeholder text caused more harm than good, with at least seven (7) negative consequences for users, both with and without disabilities. In addition, for users with disabilities, three more problems are often present:

1. The color contrast of placeholder text against the field background is often not strong enough to meet WCAG requirements;

2. Many problems in the original seven are magnified for people with cognitive or motor disabilities, and

3. Some screen readers don’t read placeholder text at all.

With all of these problems, why would any library keep using placeholder text?

As far as I can tell, there are only two reasons:

• They don’t know better.

• They don’t care.

That’s it.

If you are reading this, the first reason is no longer an excuse. The second is up to you.

It’s doesn’t take much effort to find out where a famous person was born. Or even to get a list of famous people born in a specific location. But what about if you want the most famous person from that place?

There is data to answer that question, but who likes plain, old, non-visualized data? Notable People turns it into an interactive visual experience, helping you explore the answer and much more.

Supported by Wikidata and Wikipedia, this interactive site lets you explore notable people around the world by location. Spin, zoom, and scroll through the globe to see results at every level, from countries down to individual cities and towns.

If you click a person’s name, you’ll get a link to their Wikipedia article, their “notability rank,” gender and whether or not that person is still alive (this last one is not always a certainty. Take a look at Charlize Theron in South Africa).

Even without a particular question you need answered, this is the kind of site that rewards aimless exploration. Enjoy!

“Click here.”

For years, I have been telling people that that phrase makes me want to drink. Here’s why.

First, some backstory. In the early days of the web, everyone was learning how to use it. Nobody knew what a hyperlink looked like. The blue link text with underlining was just beginning to be acknowledged as the normal indicator and we were all figuring it out together. Often, web page creators helpfully included the text “Click here,” just in case someone hadn’t gotten the memo about what a hyperlink was.

But, here’s the thing: we’re about thirty-odd years out from the advent of the graphic internet. People who don’t know what a hyperlink is are now the outliers, not the norm.

When people write link text using that phrase, they’re not helping anyone. In fact, using it negatively affects both usability and accessibility:

• Think about how most people read a webpage; they don’t! They scan the page for things that stand out, like hyperlinks. When a link only says “click here,” it tells the user nothing about where the link goes or what it will do. To understand it, they have to stop scanning and go back to read the surrounding text for context.

  This is an even bigger barrier for people using assistive technology, which may present links out of context. That is why WCAG 2.1 Success Criterion 2.4.4: Link Purpose (In Context) requires link text to identify its purpose. Think “click here” versus a link that says “More bestsellers.” The second one tells you very clearly what the end result will be if you click it.

• We no longer need to teach people how to use a hyperlink. Your library may still offer “Learn the Internet” classes, and those can be valuable. But using “click here” in everyday web content does not support that goal. The rest of the web has largely moved beyond that phrasing. People who are still learning to use the internet benefit from links that clearly describe where they lead or what they will do. Making library links less descriptive only creates another obstacle.

• At a minimum, “click here” can be considered ableist. It assumes that everyone is using a mouse, which is not the case. Many people navigate with a keyboard, voice controls, switches, or other assistive technology rather than clicking.

  It is also not especially accurate. On a touchscreen, such as a phone or tablet, people tap a link rather than click it.

So the next time you are tempted to write “click here,” stop and ask yourself: what is someone actually going to find when they activate this link? Put that in the link text instead. Your users will have a clearer, faster, and more accessible experience. And I may be able to put down the drink.