The Procurement Nightmare: Why Your Vendor's CSS Removed Focus Styles and How to Catch It
By The bee2.io Engineering Team at bee2.io LLC

So you're about to sign a six-figure contract with a digital agency, and their portfolio looks absolutely gorgeous. The animations are smooth. The colors pop. The stakeholders are impressed. Then someone actually tries to use a keyboard to navigate the site, and it's like watching someone play a video game with the controller unplugged. Nobody can see where they are. Nobody knows what they're clicking. Everyone suffers.
This scenario happens approximately 47 times per business day in the procurement world, and it's almost always because some developer thought outline: none; was a personality trait.
The PRO Million Accessibility Audit Nobody Asked For
Here's what happens in most organizations: procurement approves the vendor. Design and development happens. Launch day arrives. Then legal gets a letter. Not fun.
According to WebAIM's 2024 accessibility analysis, roughly 96% of websites have detectable accessibility failures. But here's the funny part - the most easily preventable failure shows up in almost every single audit. It's not some obscure technical debt. It's focus styles being deliberately removed by CSS that basically says "we don't want you to see where you are."
When you're evaluating vendors for web work, keyboard accessibility isn't some nice-to-have feature you can defer to phase two. It's the difference between a product that works and a product that creates legal liability while simultaneously excluding people who rely on keyboards. That's not edgy design. That's just broken.
Your New Procurement Checklist: The Focus Styles Edition
Before you sign anything, add this to your vendor evaluation matrix. Your legal team will thank you. Your actual users will thank you. Mostly because they'll be able to navigate your site.
Acceptance Criteria - What You Actually Need
- Visible focus indicators on all interactive elements: Tab through the entire site. Every button, link, form field, and focusable element must show a visible outline, highlight, or other indicator. If you can't see the focus, the vendor fails. This is not subjective.
- Focus order follows visual/logical flow: Hit Tab repeatedly. The focus should move through the page in a sensible sequence, not jumping randomly or disappearing into hidden sections. If it feels chaotic, it is chaotic.
- No outline: none without replacement: This is the gotcha clause. If a vendor's CSS removes focus styles but hasn't added a custom focus indicator, that's an automatic rejection. Non-negotiable.
- Minimum contrast ratio of 3:1 for focus indicators: The focus style itself needs to be visible against its background. A gray outline on gray background is the web equivalent of writing your password in pencil.
Evidence: What to Actually Test
Don't just look at screenshots. Make the vendor demonstrate the product during keyboard-only navigation - no mouse, no trackpad. This immediately reveals whether focus management was an afterthought or actually built into the design system.
- Request a browser inspector report showing the CSS rules applied to :focus and :focus-visible pseudo-classes
- Ask for keyboard navigation test results for your specific use cases
- Require screen reader testing as a bonus track - vendors who handle focus styles properly usually handle screen readers decently too
- Check their design system documentation. If they're serious about accessibility, they've already documented how focus states work
If a vendor can't or won't demonstrate this before you sign, that's your signal that they've outsourced keyboard accessibility to the same department that handles "we'll fix it later."
Exit Conditions - When to Walk Away
- Vendor claims focus styles "clutter the design" or "aren't part of the current project phase." They're wrong on both counts.
- Custom focus indicators exist but are virtually invisible or lower contrast than the adjacent content. Still a failure.
- Focus jumps inconsistently or disappears entirely on certain page components. This isn't a minor bug - it's a showstopper.
- Vendor says they'll "handle accessibility in QA." Accessibility built in afterward is accessibility that's held together with duct tape and prayers.
Make This Your Baseline, Not Your Ceiling
Focus styles are literally the minimum viable product for keyboard accessibility. They cost nothing to implement correctly. They break nothing. They make your site work for people using assistive technology, people on slow connections jumping between fields, and honestly, just keyboard nerds who find mice philosophically suspicious.
When you're evaluating your next vendor or contractor, before you ask about SEO performance or mobile responsiveness, ask them to Tab through their work. If they can't show you a focus indicator on every interactive element, they're not ready to ship code that represents your company.
Want to know if your current vendor is already a disaster? Grab a keyboard. Go to your site. Don't touch the mouse. See what happens. If you can't see where you're clicking, you've got work to do - and now you've got a procurement excuse to demand it.
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.
Stop finding issues manually
SCOUTb2 scans your entire site for accessibility, performance, and SEO problems automatically.