Published: 16 June 2026
The Same Issues Block Procurement Again and Again
Are accessibility issues in your product preventing procurement teams from even considering your solution? You’re not alone. Chances are your product has the same common accessibility failures that appear across hundreds of SaaS products. The good news? Most of these issues are easy to fix once you know where to look.
The Top Accessibility Failures in SaaS Products
1. Missing or incorrect labels
Screen readers rely on accessible names. But if your buttons, icons, and form fields lack proper labels, they become invisible to assistive technologies.
Fast fix: Use semantic HTML and ensure every interactive element has an accessible name.
2. Poor focus management
Keyboard users get lost when focus jumps unpredictably or is not managed at all. A client wanted users to provide demographic information in a dialog box before starting a survey. But focus wasn’t managed to (or from) the dialog, effectively blocking access for keyboard users. Another common issue is invisible focus indicators, where sighted keyboard users cannot see what has focus as they tab around the page. And sometimes visually hidden links, like those in collapsed accordion panes and hidden responsive menus, can remain keyboard-focussable. Where did focus go?
Fast fix: Use native elements where possible, manage focus explicitly in custom components and remove focus entirely from hidden elements.
Note: Focus management is a common issue in modals, dialogs, dropdowns, and custom widgets, and pay particular attention to single page applications.
3. Low colour contrast and colour reliance
Have you ever struggled to read some text because it contrasts badly with its background or surrounding content? My eyesight isn’t as sharp as it was and I’m colour-blind, which is scarily common (8% of men). If so, you’re not alone. Instances like light grey text or thin fonts might look fine to many, but they can be illegible to people with low vision or colour blindness. Another one that shocks me? Just changing colour without any other visual indication. For example, a red error message that only changes the text colour to indicate an error state. If you can’t see the red, you won’t know there’s an error.
Fast fix: Update your design tokens and regenerate components, and always use more than colour to indicate state changes. Like an asterisk for required fields, or an icon to indicate an error.
4. Non-semantic components
Ooh this is a good one, and sadly very common. Divs pretending to be buttons, links, tabs, or menus. They may look the same… but they’re not. <div class="button">Click me</div> IS NOT a button. It is not keyboard focusable and won’t explain its purpose to assistive technologies.
Fast fix: Use real HTML elements, or go to the probably unnecessary extra effort of adding ARIA roles, states, and keyboard behaviour.
5. Keyboard traps
Thankfully I don’t see this that these days, yet it’s too important to ignore. Don’t trap focus without giving people a way to escape - forward and backward. Would you be happy to restart your computer or even web browser because you became trapped in a modal, menu, or some custom widget?
Fast fix: Test every component with a keyboard and fix focus loops.
6. Inaccessible error messages
One of my faves are error messages that are not shown, not announced, not linked to fields or are unclear or ambiguous. For example, a form field that fails validation but doesn’t show an error message, or shows a message that says “Error” without any context. Or an error message that is visually present but not announced by screen readers because it’s not programmatically associated with the relevant form field.
Fast fix: Use aria-describedby and ensure errors are programmatically associated.
Why These Failures Happen
Good news… they’re usually unintended. But they often happen because of custom components built under pressure, inconsistent design system usage, lack of awareness or semantic understanding, no accessibility acceptance criteria or insufficient testing. These are process issues, not just code issues.
Fast Fixes That Deliver Immediate Impact
1. Fix components, not pages
A single accessible component can eliminate dozens of failures.
2. Add automated linting
Catch missing labels, contrast issues, and ARIA misuse early.
3. Run a focused 2–3 day remediation sprint
Target the top 10 issues — they unlock most procurement barriers.
4. Update your design system
Prevent issues from reappearing.
Long-Term Prevention
1. Maintain a design system with accessibility baked in
Document keyboard behaviour, ARIA patterns, and focus management for every component.
2. Train designers and developers
Semantic HTML is the foundation. Use ARIA to enhance, not replace it.
3. Conduct regular audits
Quarterly or biannual audits prevent regression.
Conclusion
Most accessibility failures in SaaS products are predictable — and preventable. Fixing them quickly unlocks procurement opportunities and reduces long-term risk.
Free Tools to Try
ICT Supplier Self-Assessment Checklist: Use this checklist to self-assess your ICT products and services for accessibility. Based on the European standard EN 301 549 and the Web Content Accessibility Guidelines (WCAG), the bases for accessibility requirements in Australia. Try it now.
Services
ICT Supply: Learn how AccessUX helps ICT suppliers and vendors win more tenders by improving their product accessibility, and evidencing it to government and enterprise buyers.