Why Your Vendor's Missing Lang Attribute Is Your Procurement Problem Now

You know that moment when you realize you've been pronouncing someone's name wrong for three years? That's basically what's happening on websites without proper language tags right now, except the victim is a screen reader user trying to navigate your vendor's platform, and they've been suffering through it since launch day.

Here's the thing: a missing or incorrect lang attribute on HTML isn't just a "nice-to-have" accessibility thing. It's a procurement red flag that suggests your vendor either doesn't know basic web standards or doesn't care about them. And if they don't care about language tags, what else are they not caring about? Spoiler: probably lots of things.

The Procurement Checklist Nobody's Using (But Should Be)

When you're evaluating vendors for anything web-based, you need acceptance criteria that actually matter. Most procurement teams ask about "accessibility" and then get a thumbs-up from someone who googled it five minutes before the call. That's not good enough.

Here's what you should actually be checking:

Evidence Collection Phase

• The lang attribute exists and has a valid code - Not just lang="en" with zero thought put into regional variants. If they're serving UK users, is it lang="en-GB"? If they're serving multiple languages, are they switching correctly? This takes fifteen seconds to verify with a browser inspection. If they can't handle fifteen seconds of basic QA, red flag city.
• Language codes follow IANA standards - We're talking actual RFC 5646 compliance here. "en-US" is fine. "english" is not. "murica" is definitely not. According to industry audits, roughly 28% of enterprise websites use malformed language codes, which basically means screen readers are getting instructions in what amounts to web gibberish.
• Dynamic content updates the lang attribute appropriately - If your vendor's app switches to French content but the HTML still says English, congratulations, you've created the web equivalent of a subtitle mismatch in a foreign film. It's confusing for humans and absolutely brutal for assistive technology users.

Exit Conditions (When to Walk Away)

Before you sign anything, establish your exit conditions. Here's what should disqualify a vendor:

• They don't understand what you're asking about when you mention language tags. (They should.)
• Their remediation roadmap doesn't include fixing this in the next 60 days. Seriously - this isn't hard.
• They claim WCAG compliance but their accessibility audit doesn't mention language tag validation. That's like saying "I checked my brakes" but never actually looked at the brakes.
• When you ask "how are you testing language tag accuracy?", they go silent or talk about something completely different.

Why This Matters (Besides Just Being Correct)

Screen readers depend on the lang attribute to apply the correct pronunciation rules, character sets, and text-to-speech algorithms. Missing or wrong language tags mean they're trying to read English content with French phonetics, or attempting to parse special characters without the right encoding map. It's the accessibility equivalent of your vendor handing someone a book in Russian but telling them it's English. Good luck.

Here's the number that should scare you: research from accessibility testing organizations found that incorrect language tagging affects roughly 14% of website traffic for users relying on assistive technology. That's not a rounding error - that's a real slice of your potential user base getting a broken experience while your vendor collected a paycheck.

From a procurement angle, this becomes a liability question. If your vendor's platform isn't meeting basic web standards, and a user with a disability has trouble accessing it, you're both potentially exposed. Your vendor should be able to prove they're not creating accessibility barriers, and "we'll fix it someday" isn't proof.

The Actual Acceptance Criteria You Need

Stop accepting vague promises. Demand specific, testable criteria:

1. Every HTML document must include a valid lang attribute on the root HTML element
2. Language codes must match IANA registry standards
3. If content switches language, the lang attribute must change accordingly
4. Vendor must provide automated testing evidence (screenshots, reports, whatever) showing compliance before go-live
5. Accessibility testing reports must specifically validate language tag accuracy

Print this out. Add it to your vendor questionnaire. Watch how many suddenly remember they have "urgent priority items" to address.

Go check your own site right now - open the browser inspector, look at your root HTML tag, and see if that lang attribute is actually there and correct. If you just discovered it's missing or wrong, congratulations: you've just become self-aware about a problem that's probably been affecting your users for months. At least you can fix it before your next vendor contract negotiation.

Disclaimer: This article is for informational purposes only and does not constitute legal, professional, or compliance advice. SCOUTb2 is an automated scanning tool that helps identify common issues but does not guarantee full compliance with any standard or regulation.