Digital Divide Is a Library Problem, Not a Patron Problem

I've worked with libraries that are actually solving the digital divide. Not perfectly. But they've built systems that work on 3 Mbps satellite. That work on phones from 2015. That work for people in cars without addresses and immigrants who speak five languages. That don't require a $1,000 laptop to access public information.

They didn't do this because they had better budgets. They did it because they asked a different question upfront: "Who can't use this? And why not?"

Here's what I watched happen at libraries that didn't ask that question: They built beautiful digital services. Shiny discovery portals with autocomplete and faceted search. Ebook platforms with slick interfaces. Everything optimized for a specific person - someone with a modern phone, high-speed broadband, and the ability to download 500MB apps.

That person doesn't look like most of their community.

The digital divide isn't something happening to poor communities. It's something we're building. We're designing systems that exclude them, then acting surprised when they can't use those systems.

Who We're Actually Locking Out (And Why It's Our Fault)

Let me show you specific patrons and the library choices that exclude them:

The Immigrant Who Needs to Renew in Spanish

Maria wants to renew her books online. Your discovery portal requires JavaScript. Her phone is a budget Android from 2017 - it can't handle modern JavaScript frameworks. Even if it could, the site assumes English. There's a Spanish option, but it's machine-translated and says nonsense like "Return your books to the magic library place."

What happened: Your library chose a $50K/year discovery system. The vendor promised features. You didn't ask about low-device support. You didn't ask about language access. The vendor didn't offer it because they target libraries with wealthy patrons. Maria can't renew online. She'd visit in person, but she works 12 hours. Your library closes at 6.

This is on you.

The Rural Parent Who Needs Ebooks, Not Streams

Tom lives 40 miles from town on satellite internet - 3 Mbps on a good day. Your library just bought an ebook platform. Beautiful interface. Streaming only. The vendor says streaming is "the future." Tom tries to read to his kids. The book loads for 30 seconds. His data cap gets hit. He stops trying.

What happened: Your library director toured the vendor's demo. Loved the slick interface. Never asked if it worked on real rural internet. Never tested on 3 Mbps. The vendor charges the same price whether the platform works for rural patrons or not. No incentive to support them. Your library paid $10K for access Tom can't use.

You could've asked the vendor to support offline mode. You could've asked for a demo on throttled internet. You didn't.

The Older Adult with a 2015 Phone

Joan wants to place a hold online. Your mobile-optimized website requires iOS 12 or Android 8. Her iPhone 6 runs iOS 9. The website barely loads. The buttons are tiny. The site assumes you have perfect vision. Joan gives up and calls. Your reference desk is backed up. She waits on hold for 10 minutes.

What happened: Your IT person said "We optimize for modern devices." Translation: "Devices from the last 3 years." Joan's phone is 9 years old. In rural areas and low-income neighborhoods, older devices are the norm, not the exception. You optimized for who you wanted your patrons to be, not who they actually are.

The Unhoused Patron Who Needs a Computer, Not a Login Form

David wants to look up job postings. Your library computers are open. But your digital job-search portal requires creating an account with an address. David doesn't have one. He's living in his car. The portal won't let him in. He asks staff if he can just use a library computer to access the website directly. Yes, but those computers run Windows 7 from 2010. The website requires JavaScript features that Windows 7 can't handle well.

What happened: Library policy said "We need addresses for accounts to prevent fraud." But you're excluding people who are already the most vulnerable. Your IT person said "We can't update those computers, we don't have budget." You could've at least required addresses only when necessary. You could've at least made sure public computers could run modern browsers. You did neither.

The BIPOC Branch That Got Half the IT Budget

Your main library branch: fiber internet, 2024 computers, macOS and Windows 11, $50K/year tech budget. The branch serving a neighborhood that's 60% BIPOC: cable internet (when it works), computers from 2013, Windows 10 and 7, $25K/year budget. Cloud services don't load well on old Windows. Mobile apps that require newer Android/iOS don't install. Tech support is provided by the main branch's one IT person, who visits monthly.

What happened: Budget decisions. All of them made at the top. The system tells you that your main library deserves better technology. That the neighborhood with higher needs deserves less support. You knew this. You approved it.

What I Watched Libraries Do Wrong (And What Actually Happened)

The JavaScript Discovery Portal Mess

A library signed a $50K/year contract with a major discovery vendor (won't name them, but you'd recognize it). Beautiful interface. Slick search with autocomplete. Faceted navigation. Mobile-first design.

I watched the director demo it on her MacBook Pro. Fast. Responsive. Amazing.

Then I tested it on a library public computer running Windows 10 on a 2012 machine. Search autocomplete took 5 seconds. Filters didn't load. Pagination broke. On 3 Mbps rural internet, the page took 45 seconds to load - and patrons had already given up by second 15.

I asked the director: "Did you test on low-bandwidth connections?"

She said: "The vendor said it works on 4G."

Nobody tested on 3 Mbps. Nobody tested on public library computers. The vendor optimizes for people like the director - MacBook Pro, home fiber, modern browser. Everyone else gets a broken system. The library still pays $50K/year.

This is a choice. The vendor could optimize for low-bandwidth. They don't because they don't have to.

The App That Only Works on New Phones

A library licensed an ebook platform. Required iOS 13+. Required Android 8+. Beautiful app. Instant sync across devices.

A patron with an iPhone 6s (iOS 12) couldn't install it. A patron with a Samsung Galaxy J2 (Android 5) couldn't install it. These aren't exotic phones. iPhone 6s was top-of-the-line in 2015. Galaxy J2 is still common in low-income households because it's cheap.

There was a website version, but it required streaming (didn't work on unreliable connections). The patron used an unpaid ebook site instead.

The library paid $10K for access 40% of its patrons couldn't use. I asked the tech director why they didn't require the vendor to support older devices. He said: "The vendor said that's their minimum requirement."

He didn't push back. The vendor knew there's no penalty for excluding poor people.

The Digital Literacy Class That Wasted Patron Data

A rural library ran "Computer Basics" classes. One lesson: "Download a file from the internet." The teacher used a 50MB PDF as an example.

Half the attendees were on metered satellite internet with 20GB/month limits. A few of them burned 2-3GB that month just on classes. One attendee had to skip class the rest of the month because she'd hit her cap.

The instructor never asked if anyone was on metered connections. The library never trained instructors on this. The program taught digital skills while punishing people for not having unlimited broadband.

This is a library choice. You can teach digital literacy without assuming unlimited data.

Voting Information: Democracy, But Only for Some

A county library system hosted voter information. Website only. Mobile-optimized.

The website loaded Google Fonts from a CDN (extra bandwidth). Search required JavaScript (older browsers broke). There was no plain HTML fallback. A voter with a 10-year-old Android phone and 2 Mbps connection couldn't find their polling location the night before the election.

The library told me: "We focused on mobile because that's what most people use."

Translation: "We focused on people with new phones and good internet."

Democracy shouldn't be limited to people with modern devices. This was fixable in 2 hours by removing the CDN-loaded fonts and adding a no-JavaScript search fallback. The library didn't do it.

How to Audit Your Systems (What Actually Works)

I know this sounds like a lot of work. I know you're short-staffed. I know your board will ask why you're spending time on "edge cases" instead of new features. But here's what I've seen: Libraries that do this find that 15-25% of their community benefits immediately. Not edge cases. Real people.

Before you buy the next discovery system or ebook platform, audit for accessibility. Here's how:

Questions to Ask Vendors Before You Sign

Most vendor demos are running on Macbook Pros at 100 Mbps. Here's what you need to actually know:

1. What's your minimum device/browser requirement? (And actually test it.)

Don't ask what they *claim* they support. Ask them to show you it working on a 7-year-old Android phone. Ask them to show it on Windows 7. If they won't demo it, they know it won't work well.

If they say "We optimize for modern devices," they're saying: "Old devices won't work." Most of your patrons have old devices.

2. Test it on 3 Mbps. Seriously. Right now, in this meeting.

Open the vendor's demo in your browser. Open DevTools. Go to Network tab. Throttle to "Slow 3G." Now try to use the system. Can you search? How long does autocomplete take? Can you load results?

If the vendor says they don't have time to test, that's fine. They're admitting they don't support rural patrons. You'll know what you're paying for.

3. Does it work without JavaScript?

Open their demo. Press F12 (DevTools). Go to Settings. Disable JavaScript. Try to use the system. Can you search? Can you browse?

If it breaks completely, the vendor hasn't built for accessibility. Core functions - search, browse, basic info - should work without JavaScript. Advanced features like autocomplete can use JavaScript. But searching shouldn't break if JS doesn't load.

4. What about screen readers?

If anyone on your staff uses a screen reader (NVDA on Windows, VoiceOver on Mac), test the vendor's demo. If you don't have someone, ask the vendor for a screen reader test. If they haven't done one, that's your answer.

If they say "We're working on accessibility," that means they haven't done it yet. You'll be their beta tester.

5. What if I need to stop using this platform in 2 years?

Can you export all your data? What format? Who owns it? If the vendor says "You can't," you're locked in. They know it. They're counting on it. That's how they'll raise your renewal price 40% in year 3.

You should be able to own your data. If the vendor won't commit to that in writing, don't sign.

What to Actually Do (By Library Size)

Small Library ($2K-$5K budget)

I know this sounds impossible on a small budget. I get it. You're one person doing everything. But here's what actually works:

• Accessibility audit (free): Use WebAIM and WAVE. Takes 2 hours. Tests your website.
• Bandwidth test (free): Throttle your browser to 3 Mbps. See what breaks. Fix the worst.
• Staff training (1 hour): "If someone's phone is old, they might not see colors the same way. Don't use color alone to show errors."
• Public computers (what you have): Update Windows Update. Install Chrome/Firefox. Keep browsers current.
• Phone access (free): Put your catalog's phone number on the website. Train staff to help patrons by phone.

Medium Library ($5K-$15K budget)

You have more resources and more patrons who'll benefit:

• Professional audit ($1K-$2K): A contractor tests your website + main platforms. Worth it.
• Real testing: Borrow a library computer from a patron with a slow connection. Test your systems on it.
• Staff training (4 hours): Teach IT and reference staff about accessibility. It changes how you think about problems.
• Computer lab (upgrade 3-4 machines/year): Prioritize older labs first. They serve people with fewer options.
• Multiple access methods: Web (works on any device), phone (for patrons without data), email (text-only), in-person (always).
• Language access: Translate your most-used pages into the top 3 languages of your service area. Start with patron registration and holds.

Large Library ($15K-$30K budget)

You serve a bigger community with diverse needs. You can't ignore this:

• Comprehensive audit ($3K-$5K): Test everything - website, all platforms, all access methods.
• User testing with real people: Bring in low-income patrons, disabled patrons, immigrants, rural patrons. Watch them use your systems. It's humbling.
• Accessibility standards in vendor contracts: Every new platform must meet WCAG 2.1 Level AA. Non-negotiable. Or you don't buy.
• Computer labs with accessibility: Screen readers (NVDA, free). Ergonomic chairs (for people with mobility issues). Multiple browser options. Keep them updated.
• Multiple languages: Full translations for top 5 languages. Or hire bilingual staff. Or both.
• Dedicated accessibility person (or budget for consulting): You need someone whose job is making sure systems work for everyone. Not "by the way" accessibility. Real accountability.

What to Tell Your Board (And Mean It)

"15-25% of our community can't use our digital services with their current devices and connections. That's not acceptable."

Get the data. FCC broadband report. Census Bureau device data. Local internet speed surveys. Show the board actual numbers for your service area. "20% of our community has less than 10 Mbps broadband." Not "some people." Actual percentages.

"We're paying for systems that exclude the people we're supposed to serve."

You paid $50K for a discovery system that doesn't work on 3 Mbps. That's $50K spent on excluding rural patrons. You could've paid $30K for a system that works everywhere. Instead you chose features over access.

"Adding accessibility costs less than replacing computers for new vendor requirements."

Every time a vendor "upgrades" and requires newer devices, you have to replace public computers. Building for older devices and slow networks from day one saves money long-term. It's not extra cost. It's smart spending.

What to Do This Week

Don't wait for a strategic plan or a budget conversation. Do this now:

Monday: Test your main website on 3 Mbps. Open DevTools. Throttle to "Slow 3G." Can you search? How long does it take? Note what breaks.

Tuesday: Pick your worst-performing vendor platform. Call them. Ask: "What's your minimum device requirement?" Get it in writing. Then ask: "Can you demo this on a 7-year-old Android phone at 3 Mbps?"

Wednesday: Check your public computers. What OS are they running? When did you last update the browser? Schedule browser updates for all of them this month.

Thursday: Look at your patron data. What percentage speak a non-English language at home? What percentage are over 65? What percentage live in rural areas? Show this data to your director. Say: "These people can't use our systems. Here's why. Here's what it costs to fix."

Friday: Add phone-based access if you don't have it. Update your website: "Can't use the website? Call [number] to renew books by phone." Train someone to handle those calls.

That's it. One week. You've identified your biggest problems and started fixing them.

The Bottom Line

You didn't wake up planning to exclude immigrants, rural patrons, older adults, unhoused people, and BIPOC communities. It happened through a series of small choices. Better features in vendor software. Optimization for mobile. Budgets that favored main branches.

Each choice felt reasonable at the time. Together they built a system that locks out the people who need your services most.

Here's the good news: You can unmake those choices. The patron on a 2015 Android phone? They can use your website. The rural family with 3 Mbps? They can use your ebooks. The unhoused person without an address? They can still access your computers.

Not because you need a bigger budget. Because you ask different questions.

Not "What vendor has the shiniest features?" but "Does this work on the devices my patrons actually have?"

Not "How do we meet everyone's needs?" but "Who did we leave out? How do we fix that?"

That's the work.