A website can look modern, feature polished animations, and appear flawless in a design presentation. Its real quality, however, is tested when someone tries to complete a task: filling out a form, reading information, selecting a product, making a payment, or accessing an account.
That is when attractive design may prove less usable than expected.
Small buttons, difficult-to-read text, mouse-only navigation, or login processes that require users to memorise and repeatedly enter information can create meaningful barriers. These difficulties affect not only people with disabilities but also older adults, people with temporary limitations, and users operating devices in less-than-ideal conditions.
In July 2026, Indonesia's Ministry of Communication and Digital Affairs reaffirmed the importance of making government digital services accessible to all citizens, including people with disabilities. The statement reinforces a broader principle: digital transformation should be evaluated not only by how many services exist, but also by who can actually use them.
The Ideal User Does Not Represent Every User
Many design decisions rely on assumptions that teams may not consciously recognise: users have good vision, steady hands, strong reading skills, recent devices, and reliable internet connections.
Real users are considerably more diverse.
One person may rely on a screen reader because of a visual impairment. Another may need keyboard navigation because using a mouse is difficult. An older user may prefer larger text, while someone recovering from a hand injury may need easier-to-reach touch controls.
Even people without permanent disabilities experience situational limitations. Reading a screen in bright sunlight, operating an application with one hand, or following instructions under time pressure can reveal design weaknesses that are otherwise easy to overlook.
Accessibility is therefore not about building a separate product for a particular group. It is about recognising the range of human abilities and circumstances that already exist in everyday product use.
From Standards to Product Quality
The Web Content Accessibility Guidelines, or WCAG 2.2, provide testable criteria for improving web accessibility. The guidelines have also been published as ISO/IEC 40500:2025.
WCAG is organised around four principles: Perceivable, Operable, Understandable, and Robust. Information should be perceivable, interfaces operable, interactions understandable, and content compatible with different technologies, including assistive technologies.
These principles translate into practical design decisions. Interactive controls need appropriate dimensions and spacing. Keyboard focus should remain visible. Previously entered information should not be unnecessarily requested again. Authentication should minimise avoidable memory and cognitive demands.
For example, WCAG 2.2 includes a Level AA minimum target-size criterion of 24 × 24 CSS pixels, subject to defined exceptions. This does not mean every button must measure exactly 24 × 24 pixels or that this dimension guarantees comfortable use for everyone.
Standards establish a baseline. User research and testing remain essential to a genuinely effective experience.
Small Barriers Can Become Business Problems
Consider a business with an attractive checkout page where address fields are difficult to select, error messages rely on colour alone, and the confirmation button cannot be reached using a keyboard.
Some customers may still complete the transaction. Others may repeatedly struggle, request assistance, or abandon the process.
From a business perspective, these problems can contribute to support workloads, abandoned transactions, incorrect data entry, and lower task-completion rates.
It would nevertheless be misleading to claim that every accessibility improvement automatically increases conversion by a specific percentage. Outcomes depend on the product, existing barriers, user population, and implementation quality.
The more fundamental relationship is that interaction barriers reduce people's ability to complete their intended tasks. Removing those barriers improves product quality, even when the financial impact requires separate measurement.
Accessibility Cannot Be Reduced to a Checklist
Automated accessibility tools can identify problems such as missing labels, inappropriate heading structures, or colour combinations that fail particular contrast criteria.
They cannot fully determine whether instructions are understandable, whether a transaction flow is confusing, or whether someone using assistive technology can complete a task efficiently.
Effective testing therefore combines technical evaluation with real usage.
Teams can begin with essential customer journeys: registration, login, search, ordering, payment, insurance claims, or form submission. They can test keyboard navigation, screen readers, text enlargement, and different screen sizes while involving users with relevant accessibility needs.
Findings should be prioritised by their effect on task completion, not merely by the number of technical warnings.
Inclusive Design Starts Earlier
In Indonesia, Law No. 8 of 2016 and Government Regulation No. 42 of 2020 provide legal context for disability rights and accessibility in public services. However, obligations for individual commercial websites or applications must be assessed according to the relevant service and applicable rules. Public-service requirements should not automatically be treated as identical obligations for every private digital product.
Beyond compliance, there is a more fundamental product decision.
Is accessibility considered when developing the design system, defining components, structuring forms, and designing authentication? Or is it checked only after the application is complete?
The later barriers are discovered, the more design and development decisions may need revision.
When considered early, accessibility can become a natural part of product requirements, component libraries, quality assurance, and release processes.
A good digital product does not necessarily provide an identical experience to every user. It should provide reasonable ways for different users to achieve the same essential goals.
Design is not successful simply because the interface is finished. It succeeds when more people can use it.
- Indonesia's Ministry of Communication and Digital Affairs, 16 July 2026 — Deputy Minister Nezar Patria: Government Digital Services Must Be Accessible to All Citizens. Used as the current Indonesian policy context.
- W3C — Web Content Accessibility Guidelines 2.2. Primary reference for WCAG's four principles and testable accessibility criteria.
- W3C — What's New in WCAG 2.2. Used for target size, redundant entry, consistent help, focus visibility, and accessible authentication.
- ISO — ISO/IEC 40500:2025. Confirms the international standardisation of WCAG 2.2 and its relevance to people with different disabilities and older users.
- Government of Indonesia — Government Regulation No. 42 of 2020, concerning accessibility in housing, public services, and disaster protection for people with disabilities.
- Editorial notes: This article does not claim that Government Regulation 42/2020 imposes a universal WCAG conformance requirement on all private websites. The 24 × 24 CSS pixel target-size criterion includes exceptions defined by WCAG 2.2. Potential conversion benefits are operational implications requiring measurement, not a specific quantified research finding.
Published: October 15, 2026
