Bad User Experience as Accessibility Challenge
Established UX patterns are a crucial, often overlooked lever for digital accessibility. Accessibility tends to place a one-sided focus on compliance—such as error-free code for screen readers. However, reality shows a tight cross-connection between poor UX and digital exclusion. Older people or people with cognitive challenges in particular, who do not use specialized assistive technologies, regularly fail in everyday life due to unnecessarily complex user interfaces. The solution would be a radical focus on the user—everyone would benefit from this. Accessibility therefore already begins with the mental and visual structuring of an application.
The problem is that UX improvements in their current form primarily benefit those who can cope with poor applications anyway. And despite UX expertise, most applications are poor, which is not due to the UX experts themselves. Rather, it is due to flawed requirements, legacy systems, and legal departments. It is a truism that nevertheless leads to no change: We have an implementation problem, not a lack of insight. That is why I am also certain that future systems will get worse rather than better. Radical focus on the most vulnerable users is a pipe dream. By the way, even many accessibility experts have not understood this, as the discussion around Jakob Nielsen shows. The WCAG and the demand for full compliance was fine for static websites, even if I personally do not find it convincing. For multi-step forms and applications, focusing on full compliance instead of UX is a dead end. It shows that many decision-makers have not developed a genuine understanding of users with challenges or assistive technologies. For screen readers, voice control, screen magnification, switch control, or cognitive challenges, headings, contrasts, or animations are not the core problem. The problem is completely overloaded and inconsistent user interfaces. Anyone who seriously wants public-sector apps, such as the German electronic patient file, to be used would have to radically simplify the applications. Security, data privacy, and protecting the provider are legitimate and correct goals. But the pendulum is stuck on the provider's side instead of finding a reasonable compromise between provider and user.
Lost in UI
A major problem for people who use assistive technologies is overloaded applications that do not conform to expectations. Anyone navigating within an application like online banking still encounters a clutter consisting of the main navigation of the regular portal, the footer, references to other products, and much more. Users experienced with the application can navigate through it or at least complete the specific task. Other users are completely overwhelmed by it. It does not really matter whether the portal is accessible or not, because the sheer volume of content is overwhelming either way.
For the same group, low consistency in portal behavior is also an issue. Is everything clickable reachable via Tab, or rather via the arrow keys, for instance in the case of tabs? If it is a select box, why can it not be expanded? Is an action triggered when I select an option?
A central problem is the lack of a mental model on the part of the users. When the boundaries between terms like account, cloud, synchronization, app, and service blur, those affected no longer understand how the system works at its core. This lack of clarity leads to uncertainty, false expectations, and ultimately to the abandonment of use. This can be countered by using explicit everyday models instead of technical jargon—for example, by speaking of a "mailbox" instead of a "mailbox backend". Furthermore, a step-by-step introduction of new features, a consistent system metaphor within the product, easily understandable status indicators, and a functionally integrated, guided first-time usage experience would help.
Equally critical are invisible system states. When processes such as logins, synchronizations, permission assignments, or version states run correctly from a technical standpoint but remain visually unperceivable, the system's behavior feels arbitrary. Users get the impression that they brought about the state purely by chance. This is resolved through unmistakably visible system states (e.g., “Saved to device ✔ / in the cloud ✔”) and a central, easily comprehended status area that functions like a traffic-light system. Every action requires distinct feedback, while system decisions running unnoticed in the background should be consistently avoided.
Furthermore, a general sensory overload from options quickly leads to decision paralysis or user errors when too many choices are presented simultaneously. The interface must therefore confine itself to the essentials. The principle of progressive disclosure ensures that information and options are only displayed when they are actually needed. Ideally, each screen focuses on exactly one primary action, supported by high-quality default values. Expert options belong in the background, though they remain discoverable for power users. In addition, interfaces should think in terms of concrete tasks rather than abstract functions—for example, a button should be labeled “Pay Invoice” and not require a sequence of “Upload”, “Export”, and “Settings”.
Ultimately, many people fail due to unclear error messages and a lack of action steps. When error messages are purely technical in nature, they create fear of further use or lead to immediate abandonment of the application. Good UX patterns translate errors into concrete calls to action rather than mere diagnoses: A note such as “Please check Wi-Fi” is more accessible than a cryptic “Error 504”. Every error message must offer one or two concrete next steps or feature an “Undo” principle that makes errors forgivable instead of creating a culture of warnings. Optimized default values can minimize errors beforehand; should something still go wrong, a direct escalation path helps by making support contact reachable straight from the error message without detours.
Another critical factor is the deep-seated fear of irreversible consequences. Many affected individuals hesitate during operation because it is unclear whether they might accidentally “break” something—be it in relation to money, their own health, or sensitive data. This concern leads to digital avoidance or extreme distrust toward the system. To dismantle this barrier, reversible actions must become the standard: Functions like an uncomplicated Undo, automatic versioning, and a recycle bin remove the risk from the click. In addition, a safe preview prior to final execution, clearly visible safety guarantees (“Can be undone at any time”), and risk communication in understandable, everyday language help strengthen confidence in one's own operation.
Closely linked to this is the terminology barrier. When an application communicates in system language instead of everyday language, it creates a feeling of foreignness and cognitive distance. Accessible UX therefore places an understandable, human level of language over technical terms. Instead of outsourcing explanations to external help pages, contextual explanations should be placed directly in the interface where they are needed. In critical processes, abbreviations and jargon are consistently avoided, while the terms used must remain strictly consistent across the entire system.
If a problem does arise, unclear responsibility or a lack of support quickly leads to helplessness. Users often do not know who is responsible when errors occur. An accessible system therefore defines a clear point of contact and actively signals a willingness to help (“We are here to help you”). Direct, human support should be reachable from any situation—rigid chatbot dead-ends without the option of human escalation present an enormous barrier here. Especially in complex multi-party systems, as frequently found in public administration, a transparent division of responsibilities is indispensable.
One of the biggest hurdles when entering or returning to an application is identity and login complexity. Fragmented and difficult-to-understand authentication processes lead to frequent drop-outs. Modern UX patterns counter this by relying on passwordless login methods like Passkeys and making an existing device bond (“This device is trusted”) clearly visible to the user. The logical complexity of session durations (session logic) should be minimized as much as possible in the user experience, ideally through a unified identity across various services. Furthermore, anxiety-free processes during re-login eliminate the feeling of being immediately and permanently locked out in the event of an error.
In addition, inconsistency and unpredictable behavior prevent users from learning stable operating patterns. If a system behaves differently depending on the context, this leads to persistent uncertainty. The foundation of accessible UX is therefore the principle: Consistently identical actions must lead to identical results. Hidden changes to the user interface after updates must be avoided. Major version leaps must be communicated transparently and carefully (“This is new, but here is how it works”). In development, the credo “stability first” should always take precedence over the urge for constantly new features.
Ultimately, digital services often fail due to a lack of social embedding, which leaves users alone with a complex system. As a result, even minor operating issues quickly escalate. The solution lies in hybrid models that link the digital with the human. This includes integrated systems for trusted individuals, allowing family members or assistants to help safely, as well as digital guides, which have proven highly effective in the public administration and healthcare sectors. The ability to easily and securely share the current context of an error message (“Please help me with this step”) also breaks through digital isolation.
Meta-Insight
Conclusion
When considering all these points, a fundamental problem in current software development becomes visible: Most UX approaches today primarily optimize efficiency for users who are already competent and tech-savvy. What they neglect is the reduction of cognitive load for insecure individuals.
This results in a decisive difference in approach: While traditional UX asks, “How quickly can one get through the process?”, a truly inclusive and accessible UX asks, “How secure does every single step feel?”