Eximee Team
Digital accessibility is a critical topic – not only due to WCAG requirements, but above all as a reflection of a customer-centric approach. Despite this, implementing accessibility standards in a bank can be a significant challenge. So how can it be done effectively? Let’s take a closer look at how the Eximee Low-Code Development Platform helps banks build applications that comply with WCAG.
WCAG (Web Content Accessibility Guidelines) are guidelines developed by the W3C organization to ensure people with disabilities have full access to online content.
According to the European Accessibility Act (EAA), starting from June 28, 2025, the implementation of these guidelines becomes mandatory for the financial sector, including many private enterprises. In other words, banks must ensure the accessibility of their websites and applications — otherwise, they risk customer complaints and financial penalties, which can amount to up to 10% of the bank’s annual turnover.
However, it’s important to emphasize that accessibility is more than just a legal requirement. It also offers significant business and reputational advantages. By providing accessible digital services, banks can build trust as customer-friendly institutions and open the door to millions of potential users with disabilities.
The ultimate goal is to ensure that every client, regardless of limitations, can access banking services independently and without barriers. Although assistive tools exist, such as screen readers and screen magnifiers, they can only be effective if the application is adapted to support them. Otherwise, these tools won’t function correctly, and some users will be digitally excluded.
One of the basic WCAG criteria is perceivability. A banking application should be designed so that all interface elements are readable and visible to users with partial or complete visual impairments.
What does this mean in practice? Among other things, it means ensuring adequate contrast between text and background. According to WCAG, the minimum contrast ratio is 4.5:1 for standard-size text. It also means enabling users to enlarge content to very large sizes without losing readability. WCAG guidelines require that users be able to scale page content to at least 200%, and the latest recommendations mention scaling up to 400%.
In Eximee, we take it a step further. We test our forms at up to 500% zoom without any loss of functionality or layout breakage. At such high magnification, nothing can extend beyond the screen. Even buttons like “Next" or “Back" must remain visible and accessible to the user.
From the perspective of this requirement, elements such as the website’s color scheme and contrast are also crucial. We also used the WCAG Color Contrast Checker tool during this work, which allowed us to quickly verify that color contrast meets the required standards. It’s a simple solution that greatly facilitates daily accessibility quality control.
How does Eximee support these requirements?
The Eximee Platform provides a set of shared UI components – such as text fields, buttons, dropdown lists – that by default meet WCAG requirements regarding color contrast and font size. When designing a screen in the Eximee Designer tool, a bank employee can use predefined WCAG-compliant styles.
In practice, we also pay attention to technical details, such as using relative units – for example, rem instead of fixed pixels. Why is this important? rem (root em) units refer to the font size of the main element, which by default is 16px. This allows users to scale text according to their preferences, while the interface remains consistent and readable. It’s a small thing, but crucial from the WCAG perspective, as it affects the adaptability of content to individual needs.
Highlighting focus in Eximee forms
We also added a seemingly minor but important detail: focus highlighting on form fields. When a keyboard-navigating user tabs through form elements, the currently selected field is clearly outlined (visible for visually impaired users). Importantly, this also applies to temporarily disabled fields – even if they cannot be clicked with a mouse, they receive focus during keyboard navigation and are visually highlighted as well.
In banking, a certain level of formality is unavoidable, as the language is filled with legal terms and official phrasing. While some of this language cannot be simplified (for example, a credit agreement must sound like a credit agreement), we aim to use simple, understandable language wherever possible. WCAG’s understandability criterion requires that content presented to users be clear and precise.
Clear and simple messages in Eximee
This is especially true for error messages and form hints. Users should understand what is happening and what action is needed without having to guess what a message means.
Take validation messages as an example. Instead of a generic message like “Invalid value”, it’s better to specify the issue, e.g., “Invalid PESEL number”.
PESEL number validator
Such feedback is much more helpful – both for the user (who knows what to correct) and for screen readers, which will read it out loud.
Another aspect is the language declaration in the code – each page should have a proper language attribute in HTML (e.g., lang="pl" for Polish), and if a fragment of text is in a different language (e.g., a quote in English), it should also be marked with the appropriate lang attribute.
This allows assistive technologies (e.g., speech synthesizers) to automatically switch to the correct reading language. Additionally, the content read by screen readers should avoid unnecessary repetition and be clearly phrased – so that the listener understands without doubt what the message means
Our form components feature centrally managed labels and messages, though the impact of changes depends on the configuration level. When a modification is made at the component level, it automatically applies to all forms using that component within a given bank. Moreover, if multiple components use the same translation key, the bank can modify it in the global application configuration, making the update effective across all relevant components.
At the same time, the bank can override a specific translation locally within Eximee Designer for a selected form or application. In this case, the change applies only locally and does not affect other forms. This two-level mechanism combines organizational consistency with flexibility for specific use cases.
As a result, we maintain language consistency across the entire application – users see the same clear and understandable messages everywhere. In practice, during projects for banks, we have frequently simplified hint and error message content. We also regularly adjust messages based on accessibility audit recommendations.
PESEL number validator with detailed validation criteria
Importantly, in Eximee we can also add screen reader descriptions (ARIA attributes) if a particular message needs more detailed explanation.
We also follow the principle that error messages appear in context (e.g., below a specific field) and are properly marked so the screen reader automatically reads them out when an error occurs.
All of this ensures that the user – whether reading the message visually or listening to it via a screen reader – clearly understands what went wrong and what needs to be corrected.
And that’s exactly the goal of clear and simple communication.
Another pillar of accessibility is ensuring that applications are usable by blind or visually impaired individuals who rely on screen readers. Popular screen readers include NVDA on Windows, VoiceOver on Apple devices, and TalkBack on Android. These tools read the screen content aloud, but to do so effectively, the application must be properly prepared.
All interface elements should have text equivalents and appropriate labels, allowing the screen reader to clearly identify and read them. Our goal (and the requirement set by WCAG) is for the user to be able to complete the entire process independently, using only a screen reader – without the need for third-party assistance.
In the article “WCAG Accessibility Testing”, we describe in detail how to test accessibility using various screen readers (NVDA, VoiceOver, TalkBack) – we encourage interested readers to consult that article.
In this post, we’ll focus on how Eximee Low-Code Development Platform makes it easier to create screen-reader-friendly forms. Eximee Designer has been built from the ground up to provide components that are inherently understandable to screen readers, without requiring additional work.
Each standard form element has:
Additionally, we have refined how each component is linked to its context: we associate the field with its prefixes/suffixes, label, description/hint, and validation messages. As a result, when a screen reader focuses on a field, it reads all the relevant information in a logical order – first the label and state, then the hint, and, if necessary, the error message. This allows the user to immediately understand what the control is for, how to use it, and whether it requires correction.
For example, a save button has information in the code specifying that it is a button, while a date picker field has a label clearly stating what kind of input is expected. Thanks to this, when a bank employee creates a new form in Eximee, most of the accessibility work is already done – the form is, by default, compliant with screen reader accessibility standards.
Of course, simply having good components is one thing – but we went further by testing how our forms actually work with screen readers. Eximee testers and developers validated created forms using the “black curtain” effect built into NVDA, navigating exclusively with the screen reader.
We tested whether a blind user could go through the entire process independently – from reading the instructions, through filling out all fields, to submitting the form. During these tests, we identified and fixed subtle issues that could have frustrated a visually impaired user.
For example:
This thorough testing ensures our forms are not only technically compliant but also usable in practice by people relying entirely on assistive technologies.
We paid special attention to dropdown lists and selection fields because, without proper labeling, they can be difficult for screen readers to handle. In Eximee, we made sure that the screen reader accurately communicates the status of the control, the number and position of the options, and the selected and highlighted values.
For example, when the focus lands on a field before it is expanded, the user hears helpful guidance, such as:
“Place of birth selection field," along with a description of the current state:
“Dropdown list, collapsed, with autocomplete, editable."
After expanding the list, the screen reader announces: “List, Choose…, 1 of 230”, which tells the user how many options are available and that they can navigate using arrow keys.
When focus reaches a specific item, the message may be: “Andorra, unselected, 6 of 230”, clearly indicating the name, selection status, and position of that item.
Dropdown lists in forms
Once a selection is made, the control returns to the collapsed state with autocomplete, and the screen reader reads out the updated status: “Dropdown list, collapsed, with autocomplete, editable, Andorra”, confirming the selected value. As a result, the entire interaction process is clear, and navigation is predictable and accessible.
On our end, we had to add the appropriate ARIA attributes and refine the HTML structure of the lists, including proper keyboard handling, such as arrow key logic, Enter/Escape behavior, and correct focus transitions. The result? Users relying on VoiceOver or NVDA can now navigate and operate all selection fields in the form with confidence, knowing exactly what is selected and how to choose a different value without losing focus of the application.
These efforts, from component design to detailed testing with NVDA, TalkBack, and VoiceOver, mean that Eximee forms are accessible by default to assistive technologies. A blind user can listen to the entire credit agreement, fill out the form, select the necessary consents, and submit the application independently.
Accessibility isn’t just about what is visible or audible — it’s also about how users interact with an application. Not every user can use a mouse or tap precisely on a touchscreen. That’s why a banking application must be fully operable via keyboard and should avoid requiring complex gestures.
WCAG explicitly requires that all features be accessible from the keyboard (operability principle). The user should be able to navigate through the entire form using Tab / Shift+Tab, Enter, Spacebar, arrow keys, and screen reader keyboard shortcuts. This applies even to elements we typically associate with mouse or touch interaction — such as sliders, calendars, or dropdown lists.
Additionally, if an application action is available via a multi-point gesture (e.g., pinching with two fingers to zoom in) or device motion (e.g., shaking the phone to refresh a list), alternative ways to perform the same task must be provided. In other words, not every user can perform a gesture or shake a phone, so a simpler equivalent must be provided, such as a zoom-in button or an option to disable motion-based actions.
Eximee provides this by default. Our ready-made components are designed so that forms built with Eximee are immediately navigable via keyboard. When creating a new application, a bank employee does not need to implement individual key handlers — the platform provides full keyboard operability out of the box.
Focus moves through form elements in a logical order, and complex controls (like dropdowns) respond to standard keyboard input. If a component requires an unusual interaction (e.g., a two-finger gesture or phone shake), Eximee allows you to design an alternative method, like an extra button or an action that can be triggered with a single click.
Importantly, Eximee Designer also avoids the common issues associated with single-key shortcuts, which are not used in standard templates.
It’s also important to mention the need to give users adequate time to respond. Even the simplest action, such as entering a confirmation code from a text message, can be difficult if the user is under time pressure. Elderly individuals and users with disabilities may need additional time to read and enter the code.
According to the Web Content Accessibility Guidelines (WCAG), users must be given sufficient time or the option to extend time limits. In Eximee, we take this into account. Our standard authorization components (e.g., the SMS code entry module) are set with a default limit of five minutes for entering the code. We determined, in agreement with the bank, that this time frame is secure and comfortable for users.
Additionally, Eximee displays a clear countdown timer showing the remaining time to enter the code or complete authorization, helping users stay informed and avoid uncertainty.
Imagine a situation in which the email address field looks and behaves differently in one bank form than in another form from the same institution. Another example would be when a user enters a page and an action is triggered (e.g., the screen reader starts reading the agreement) without any user input. We simply can’t allow such chaos.
Although interface consistency may not be listed as a standalone WCAG requirement, it strongly affects the predictability and usability of an application, which is addressed in WCAG. Users — especially those with disabilities — rely on familiar patterns. If they’ve learned how to use one form on our website, the next one should work the same way. That’s why we strive for complete standardization of components and experiences across all Eximee-built applications.
In practice, this means all requests and forms use the same “palette” of components. Eximee Designer provides common, reusable elements, such as text fields, dropdown lists, buttons, information sections, and data validators.
Each of these components is designed once and adapted to meet accessibility requirements, then used consistently across multiple locations. If we implement a fix or enhancement to such a component, the change is automatically applied to all forms that use it. This ensures that accessibility remains consistent throughout different parts of the system — we maintain a unified standard. This applies to both appearance (e.g., error color schemes, font sizes, label placement) and behavior (e.g., consistent keyboard shortcuts, uniform data format requirements in input fields).
What’s more, standardization also covers content. The previously mentioned validation messages are a good example — once a phrase is defined, it is used everywhere. The same goes for field labels: if a field is labeled “Mobile phone number" instead of just “Phone" in one form, that same convention is followed across the entire application.
Such consistency makes life much easier for users because everything is predictable — and WCAG explicitly recommends that interfaces behave in a predictable manner and not surprise users. We strictly follow this principle in Eximee.
It’s worth noting that we work closely with banks to maintain this consistency. Accessibility audits often reveal areas for improvement — for example, in one project for a client, we received a detailed list of WCAG-related recommendations from an external auditing firm.
In another project, we collaborated using mockups provided by the bank — we helped them implement features like dark mode and made adjustments to visual styles to ensure everything remained both visually coherent and WCAG-compliant.
Our team not only implemented these changes in shared components but also served as advisors. Sometimes, different departments within the bank had slightly different views or priorities regarding accessibility — we helped coordinate these discussions to ensure the final outcome was unified and compliant with WCAG. Thanks to the low-code platform, we could implement changes quickly and at scale. That meant a major time saving for the bank and a guarantee that no module was left behind.
To sum up this section: consistency and standardization are key to maintaining high accessibility over time. Eximee’s architecture, built on shared components, allows banks to scale accessibility — adding new processes and features without the risk of “forgetting” accessibility in any part of the system.
Every new application or form built on the platform automatically inherits all previously implemented accessibility improvements. It’s as if accessibility is baked into the platform’s DNA — banks get it by default, instead of having to reinvent it every time.
Digital accessibility in banking is a complex and multifaceted topic. As shown, it’s not just about setting the right contrast level — it encompasses the visual layer, language used in communication, support for assistive technologies, navigation design, and even the way teams collaborate during development. The key is empathy toward the user — designing solutions so that everyone can use them independently and comfortably. This requires a shift in mindset and some extra effort — but that effort truly pays off.
As a solution provider, our goal is to relieve banks of as much of that burden as possible. The Eximee Low-Code Development Platform offers many WCAG-compliant features, so products built with it meet most accessibility standards from the start. We support bank teams at every stage, from design and implementation to post-audit improvements. This helps speed up the delivery of accessible services and ensures the satisfaction of the end user — the bank’s customer.
Accessibility doesn’t have to be a burden or a box-ticking exercise — with the right tools and approach, it can become a natural part of the development process, just like security or quality.
Want to learn more? Contact us and schedule a meeting!
