How Digital Accessibility Fails | WCAG and Usable Websites

Did you know? A website can look polished on a large laptop screen and still be impossible for someone to use with a keyboard. The page loads, the animations work and the designer is pleased—yet the visitor cannot reach the button needed to finish the service.

That is how digital accessibility fails. A website has not succeeded simply because its pages can be viewed by the people who built it. The information, controls, instructions and essential tasks need to be usable by people with different abilities, technologies and circumstances.

Quick answer: digital accessibility breaks when content cannot be perceived, controls cannot be operated, instructions are difficult to understand or the interface does not work reliably with relevant assistive technology. Repair means testing the whole user task against established accessibility requirements, not merely adding an accessibility badge or checking that the page looks attractive.

The four principles behind accessible web content

The World Wide Web Consortium organises the Web Content Accessibility Guidelines, or WCAG, around four principles.

Perceivable: information must be presented in ways users can perceive, including appropriate alternatives for relevant non-text content.
Operable: navigation and controls must work through supported interaction methods, including keyboard use where applicable.
Understandable: users must be able to comprehend information, instructions and interface behaviour.
Robust: content needs to remain interpretable by appropriate user agents and assistive technologies.

These principles appear in the W3C’s Understanding WCAG 2.2 introduction. They describe different kinds of access problem rather than simply four ways of making a page more beautiful.

A website may satisfy one principle while failing another. High-contrast text does not help a person complete an application if the Submit button is unreachable by keyboard. A correctly labelled button does not solve a confusing verification process.

Seven ways an attractive website can exclude users

Image-only information: crucial text appears inside an image without a suitable accessible alternative.
Keyboard traps: someone navigating without a mouse cannot reach, activate or leave a particular control.
Unclear forms: inputs have no understandable programmatic labels or error messages explain too little.
Poor focus visibility: a keyboard user cannot tell which link or button will activate next.
Unusable contrast or scaling: important content becomes difficult to read or disappears when text is enlarged.
Inaccessible documents: an essential PDF or download has missing structure, unreadable reading order or no suitable alternative.
Broken end-to-end journey: an accessible front page leads to an inaccessible payment, login, appointment or confirmation process.

These problems can reinforce one another. A user reads a helpful public-service page, begins an application and reaches a form with missing labels. After guessing which field is which, they encounter a visual-only verification step. The service seems available online, but the person cannot complete it independently.

A fictional appointment form that fails at the final button

Imagine a clinic’s online booking service. It offers a readable list of appointment types. The visitor enters a name, selects a date and reaches a final confirmation button.

The visual design places that button at the bottom of a pop-up. A mouse user can click it. A keyboard user tabs through the page but the keyboard focus never moves into the pop-up correctly.

The user has completed almost all the task yet cannot submit it. That is not merely a cosmetic inconvenience. It prevents the person from accessing a service.

The repair begins with the actual interaction path: open the dialog with a keyboard, navigate its contents in a suitable order, activate relevant controls and return focus appropriately when the dialog closes. The developer then checks the behaviour with suitable assistive technology and user testing.

A simple automatic scan might detect some accessibility defects, but it cannot reliably establish that the entire journey works for the people who need it.

Keyboard access is not a specialist luxury

Some people cannot use a mouse because of mobility limitations or other circumstances. Others depend on keyboard navigation, switch devices or assistive technology that relies on correct interface semantics.

A website should not require a mouse-only gesture for an essential action unless the applicable criterion specifically allows that type of interaction.

Singapore GovTech’s Digital Service Standards overview includes keyboard operation as an example of the WCAG-aligned Operable principle.

A practical manual check is to try navigating an ordinary task through the keyboard alone and notice whether the focus order, controls and completion path make sense. Professional conformance testing requires appropriate evaluation methods and relevant criteria, not simply this one test.

What an alternative text description is actually for

An image can communicate information, serve as decoration or form part of an interactive control. The appropriate accessibility treatment depends on its role.

For example, a photograph decorating a school’s hero section might not need a long explanation if the same meaning appears elsewhere. A diagram showing an essential science process needs a meaningful textual alternative or another accessible way to convey the necessary information.

A button represented only by an icon needs an accessible name explaining its function. ‘Button’ is not enough when the user needs to know whether pressing it will save, cancel or submit.

The GovTech Digital Service Standards explain the value of accurate, concise alternative text and relevant descriptions for non-text media.

The objective is not to fill every image’s description field with keywords. It is to help someone understand or operate the content that would otherwise be inaccessible.

The visual label and the accessible name may be different things

Imagine a form field displaying only a faint placeholder reading ‘Email address’. As soon as someone types, the placeholder disappears. A screen reader may not receive a stable, meaningful label depending on how the form was implemented.

A robust form associates an appropriate label with its control and communicates required formats and any relevant help.

The label should describe the requested information, while errors should identify what needs correction. ‘Invalid input’ is less helpful than a specific, accurate explanation about the missing or wrongly formatted information.

Where sensitive data is involved, error messages should remain appropriate for privacy and security rather than reveal confidential records.

A screen reader needs more than text on a screen

A screen reader interprets accessible structure and control information, not merely the appearance of an interface.

A website may visually show a headline, navigation, a list and a button. If the underlying structure is unclear or interactive elements are implemented in ways assistive technology cannot interpret, the logical sequence may be confusing.

Good semantic structure, meaningful headings, properly named form elements, accessible state changes and appropriate use of native controls help a screen reader user understand and operate the service.

This is part of the Robust principle in WCAG. It is also good engineering practice for content that must work reliably across different devices and user agents.

The relevant fix is often to implement standards-based controls correctly rather than add an unusual custom accessibility workaround.

Keyboard focus must remain visible and predictable

When a user presses Tab, which element is next? Can they tell where they are? Does the focus unexpectedly jump to an unrelated part of the page?

A focus indicator helps users track their position. Its contrast, size and visibility matter, particularly when the page includes cards, popovers, floating menus and custom buttons.

WCAG 2.2 includes success criteria addressing keyboard focus, including focus visibility and situations where a focused element is hidden by other content.

A polished design can fail these criteria if a sticky header or floating banner covers the active field, or if the design removes the visible focus indicator merely to achieve a minimal appearance.

The cure is not to remove keyboard interaction. It is to design the visual and technical systems together.

Mobile zoom should not destroy the page

A visitor may enlarge text because of low vision, ageing or a temporary difficulty reading small print. Others use a mobile phone with a narrow screen.

If the main content disappears, overlays block the buttons or the user must scroll in multiple directions just to read a sentence, the interface may become impractical.

Responsive design should preserve content and functionality within the relevant accessibility requirements. A page that looks correct at one designer-selected width is not necessarily usable across expected devices and text sizes.

The test should include realistic content, including long labels, validation errors and translations, rather than only an empty demonstration page.

Captions and transcripts protect different kinds of access

A recorded lesson may include spoken explanation, diagrams and actions shown on screen. Captions can convey spoken content and important audio information. A transcript may help someone revisit the lesson or access the words differently.

However, a transcript of only the speech may not explain a crucial diagram when the presenter says ‘move this over here’ without describing what moved.

Accessible media should communicate the educational information necessary for understanding, using appropriate formats and descriptions. The right solution may involve captions, transcripts, visual descriptions or a text explanation of the essential process.

A student cannot benefit from a video concept that they cannot perceive in the form available to them.

A PDF is still part of the digital service

An organisation may make its website accessible but publish its essential form as an image-only PDF that does not expose text or fields meaningfully to a screen reader.

The webpage is only the doorway. The actual service depends on the form, document or third-party platform required to complete the task.

A good accessibility review maps the full journey: arrival, instructions, login, document, form, payment if relevant, submission and confirmation.

The question is not ‘Does our homepage pass a scan?’ It is ‘Can people using relevant assistive technologies complete the essential task on the current service?’

This distinction is especially important for education, public services, healthcare and banking, where digital barriers can have consequences far beyond inconvenience.

Singapore: digital accessibility is already a public service design issue

Singapore’s Digital Service Standards establish baseline usability and accessibility expectations for government digital services. The standards incorporate WCAG Levels A and AA and apply to the relevant government agencies and industry partners delivering those services.

This is a particular public-sector framework; it should not be misrepresented as automatically imposing identical duties on every private website.

The GovTech overview describes the four WCAG principles and practical examples such as keyboard functionality, alternative text, accessible status messages and explanations of unfamiliar abbreviations.

The broader lesson applies well beyond government: people need real access to what a digital service promises, not just attractive presentation.

The 2026 Singapore accessibility update

In a parliamentary reply dated 5 August 2026, the Ministry of Digital Development and Information explained that GovTech had introduced tools and resources to help organisations improve digital accessibility.

The MDDI reply on essential consumer services and visual impairments described Oobee, formerly Purple A11y, as a practical open-source accessibility testing tool. It also described the A11y Playground as a source of developer and design resources.

MDDI noted that fixing issues such as unlabelled buttons and links can enable screen-reader users to complete services more independently.

This is concrete evidence of the distinction between an online service existing and an online service actually being accessible to the people expected to use it.

Automated checks are helpful but incomplete

An accessibility scanner can identify many technical issues efficiently: missing labels, some colour contrast defects, certain heading or structure problems and other machine-detectable failures.

But it cannot fully determine whether an explanation is understandable, whether an alternative text description conveys the right meaning, or whether a real person can complete a complicated task under the necessary conditions.

An automated pass is not a universal certificate of WCAG conformance or full usability. A sound programme uses tools alongside manual evaluation, suitable assistive-technology checks and participation from people with relevant lived experience.

The point is not to reject automation. It is to understand what its measurement actually covers.

Accessibility is not the same as general usability

A site can be technically compatible with a screen reader yet use confusing content that makes the task difficult for everyone. Another site can be easy for many mouse users but inaccessible through the keyboard.

Usability asks whether the service helps people achieve tasks effectively and understandably. Accessibility examines barriers faced by users with disabilities and related needs under relevant standards.

These concerns overlap but neither should be used to erase the other. A genuinely inclusive service needs technical accessibility and clear, trustworthy interaction design.

This also helps people with changing abilities due to ageing, temporary injuries or situational limitations. A well-designed service should not assume every user has perfect vision, hearing, motor control and attention.

A school learning example: the worksheet nobody can use

Imagine a secondary-school student who relies on a screen reader receiving an online worksheet. The instructions are text, but every mathematical diagram is inserted as an unexplained image.

The student might know the mathematical concepts, yet the assignment does not provide the information necessary to attempt the questions independently.

The appropriate response may involve accessible representations, clear descriptions of the relevant mathematical relationships and suitable assessment arrangements under the school’s policies.

The learning objective should be preserved where practicable. The accessibility problem belongs to the delivery of information, not automatically to the student’s understanding or capability.

See How Online Learning Stalls for how digital lessons fail when delivery and meaningful learning are confused.

Why accessibility should begin before the website is built

A team can try to fix accessibility at the very end of a project, after all interfaces and processes have been approved. By then, correcting inaccessible custom controls or forms may be more costly than using appropriate design patterns from the beginning.

An earlier approach identifies essential user journeys, selects standards-based components and reviews accessibility when requirements, prototypes and content are created.

The relevant government tools and design resources encourage this integration rather than treating accessibility as an afterthought.

For a small business, starting with simple well-structured pages, native controls, proper labels and clear content may avoid many failures that more complicated custom interfaces introduce.

A practical ten-point accessibility review

Purpose: What essential tasks must different users complete?
Perception: Can people obtain essential content through suitable text or media alternatives?
Keyboard: Can expected operations be performed without a mouse where applicable?
Focus: Is the active control visibly and logically identifiable?
Forms: Do labels, instructions and errors make sense to users and assistive technology?
Reading: Does text remain readable with appropriate zoom, contrast and screen sizes?
Structure: Are headings, links and controls implemented semantically and consistently?
Media and documents: Are required videos, charts, PDFs and downloads accessible?
Full journey: Does the process work through login, submission and confirmation, including third-party components?
Verification: Have automated tools, appropriate manual tests and relevant users or specialists checked the real experience?

This is a reader-friendly diagnostic list, not a substitute for a complete WCAG conformance evaluation. The exact criteria and target level depend on the applicable requirements and purpose.

Five warning signs that a website is excluding users

Essential functions can be clicked with a mouse but cannot be completed with keyboard navigation.
Buttons and form fields have unclear or missing accessible names.
Enlarged text causes important controls to become hidden or unusable.
Critical information exists only in an inaccessible image or document.
The homepage passes an automated check, but the actual user journey still cannot be completed by someone using relevant assistive technology.

These issues deserve careful investigation rather than assuming the user lacks computer skills.

What website owners should measure

A team can count accessibility defects fixed and tests passed. Those are useful indicators. But the deeper outcome is whether people can accomplish the intended task reliably and independently where appropriate.

A meaningful review looks for completion barriers in booking, purchasing, reading, applying or obtaining help. It documents which groups encounter problems and uses appropriate privacy protections when gathering feedback.

A website may achieve technical improvements while still confusing users with inaccessible information or unhelpful errors. The process needs iteration, not a one-time badge.

An organisation should also maintain accessibility as it adds new forms, third-party tools, pop-ups and content. A site can become less accessible after an otherwise attractive redesign.

Frequently asked questions

What is WCAG 2.2?

It is a W3C recommendation containing testable accessibility guidance for web content, organised around the four principles Perceivable, Operable, Understandable and Robust.

Does passing an automated accessibility scan mean a website is fully accessible?

No. Automated testing covers only part of the required evaluation. Manual checks and relevant user or assistive-technology testing may be necessary.

Is accessibility only about people who are blind?

No. It concerns a range of visual, hearing, motor, cognitive and other accessibility needs, with benefits that can extend to many everyday users.

Why does keyboard navigation matter?

Some people cannot use a mouse or rely on other devices and assistive technologies. Essential functionality should be operable under relevant WCAG criteria.

Does Singapore require every private website to use the same government standards?

Not automatically. The Digital Service Standards describe specific Singapore Government service requirements. Other organisations need to assess their own applicable legal duties and appropriate accessibility obligations.

What is the first useful website improvement for a small organisation?

Identify the most important task, ensure it can be completed with usable controls, clear labels and appropriate alternatives, then test the real journey rather than only the homepage.

The final idea

Digital accessibility fails when a website is considered finished before the people it must serve can actually use it. Accessible design connects meaning, controls, clear instructions and technology compatibility across the entire journey. A working button is only truly useful when the intended visitor can reach, understand and activate it.

Sources and further reading

General accessibility education. A formal conformance review must follow current applicable requirements, testing methods and relevant professional guidance.

Explore the next How Things Fail guides

How Workplace Safety Fails | When Checklists Replace Hazard Control
How Digital Accessibility Fails | When Websites Exclude Real Users (current guide)
How Scam Prevention Fails | When Urgency Overrides Verification
How Building Maintenance Stalls | When Small Defects Become Major Repairs

For further systems thinking, see How Manufacturing Stalls and How Public Policy Fails. Our unchanged Secondary 1 Mathematics Tutor Clementi | Small Groups Tutorials is an educational reference for distinguishing a completed activity from real ability.

How Digital Accessibility Fails | When Websites Exclude Real Users