What Is Digital Accessibility? WCAG and the POUR Principles

When the founder of the web said that the power of the web lies in its universality, he added one more sentence: that everyone should be able to reach it regardless of disability is an essential part of that power. The concept of digital accessibility is that sentence put into practice.

Contents

The concept bears directly on localisation. Localised products often end up less accessible than their original versions. The reason is not ill will but the fact that the content responsible for accessibility does not appear on screen and is therefore forgotten when the translation scope is drawn up.

In this article we take up the definition of the concept, whom it covers, the four principles of the international guidelines, and what has to be watched during the localisation process.

What is digital accessibility?

According to the international definition, the concept refers to designing and developing digital products, tools and technologies in such a way that people with differing abilities can interact with them successfully. The issue, in other words, is a design decision rather than a compliance effort bolted on afterwards.

A definition drawn from the field of games is useful as well: the ability to play even while under restrictive conditions. Restrictive conditions may be a loss of function, or disabilities such as blindness, deafness or restricted movement.

The situations covered are broad: auditory, cognitive, neurological, physical, speech-related and visual disabilities. Each of them calls for a different form of interaction and a different assistive technology. Screen readers, voice commands, font enlargement and contrast settings are the best known of these.

In many countries the matter has become a legal obligation. In the European Union a standard applies to the websites of public bodies and other organisations; in the United States a regulation on the accessibility of communications and video is in force.

Not only permanent disabilities

The field covers not only disabilities but access conditions too. An access condition is the situation the user happens to be in at that moment. Someone who wants to play a game with subtitles in a noisy environment falls within this frame.

A user with a broken arm has to work an application one-handed. Someone glancing at a navigation app while driving is trying to process text, image and sound at the same time. These situations are temporary, but the need is the same.

This way of looking at things takes accessibility out of the realm of a small minority. Everyone benefits from the adjustments made, at least at certain moments. High contrast, large touch targets and plain text are the typical examples.

For localisation the conclusion is this: accessibility is not a separate service item but part of the nature of the work. Adding this item to the list while the scope is being set is both quicker and cheaper than repairing it later.

Four principles: from perceivable to robust

The most important international initiative from the point of view of localisation is the web content accessibility guidelines. The guidelines cover not only websites but web-based games, smartphone applications and augmented reality solutions as well. Their structure is built on four principles.

Principle	What does it require?	What it means in translation
Perceivable	Information must be perceivable by the user or by assistive technology	Image descriptions and subtitle texts are translated too
Operable	All components must be operable and interaction must be predictable	Button and link names state the action clearly
Understandable	The information presented must be readable and understandable	Plain sentences, consistent terminology, clear error messages
Robust	Content must be accessible to different user agents	Text fields inside the code are carried over without corruption

The principles remain abstract on their own, which is why each of them is divided into guidelines, and the guidelines in turn into testable success criteria. The first guideline under the first principle, for example, concerns text alternatives.

The first success criterion under that guideline covers non-text content: images, presentations, videos, sounds, charts, buttons with icons. The criterion requires all non-text content presented to the user to have a text alternative that serves an equivalent purpose.

A second example is the guideline on time-based media. For pre-recorded content consisting of audio only or of video only, a transcript presenting equivalent information is expected.

Not every non-text element needs a description. Elements serving only decoration or formatting are kept outside this rule, and it is asked that they be presented in a way that lets the screen reader skip them. A line used to separate content, read aloud over and over, becomes an obstacle to the user rather than a help.

Techniques: sufficient, advisory and failure

The methods that show how the success criteria are to be met are called techniques. Techniques are not binding; they are guidance, and they contain code examples, resources and tests. They fall into three groups.

1. Sufficient techniques: reliable ways of meeting a success criterion.
2. Advisory techniques: recommended methods that improve accessibility.
3. Failures: practices that create barriers and directly prevent the criterion from being met.

The third group is the most instructive from the point of view of localisation. Using generic placeholders such as image or video for non-text content is one example of a failure. So is putting the file name in place of a description.

Imagine the file name being read out as the description of a video embedded in a page. To the person using a screen reader, that piece of information says nothing at all. The same mistake can be repeated in translation: writing the name of the source file into the description field.

Some of the techniques hold for all technologies, while others are specific to particular technologies such as smartphones or smartwatches. The criteria stay fixed while the techniques are updated regularly.

The web content guidelines do not stand alone either. A separate set of guidelines, aimed at making content production tools themselves accessible, seeks to make it possible for disabled people not only to use content but to produce it. There is a further set of guidelines prepared for browsers and similar user agents.

This distinction points to something important: accessibility does not cover the consumption side alone. The chance to contribute to content, to write a comment and to create a product has to be accessible as well. If the power of the web is its universality, then both the products people use and the tools that produce them have to be open.

The visible layer and the invisible layer

The real difficulty met in localisation is that the content which delivers accessibility does not appear on screen. There is a twofold division: the visible layer consists of the interface, multimedia, text, graphics and photographs, while the invisible layer sits inside the code and the attributes.

If these elements in the deep structure are not localised properly, an unintended digital exclusion follows. The classic example is the text alternatives provided for images and moving content. They sit inside the code and can be extracted easily with translation tools.

Another important element is the title tag that identifies the page. Users who rely on a screen reader recognise the content by this title. For a user moving between tabs, the title is the identity of the page.

The translator’s responsibility here has two layers. The text alternative has to be carried over into the target language; and if the image has been changed during localisation, the description has to match the new image. The two must be checked together.

Research in this area shows that localised products frequently become less accessible than their original versions. Yet the localisation stage also offers an opportunity: descriptions left incomplete in the source product can be completed in the target version. That choice can make the product more inclusive than it was in its original form.

The interventions may be linguistic, technical or cultural. On the linguistic side, knowing the writing guidelines for screen readers matters. On the technical side, the text fields inside the code have to be carried over without corruption. On the cultural side, the descriptions of images whose meaning changes in the target market are rethought.

What are automated checkers for?

The accessibility of a localised product can be checked with automated auditing tools. These tools scan the semantic markup of the page, list the points that need attention and most of the time offer an explanation of what those points do.

Tools of this kind are useful at two stages. Before translation they can be used to see the current state of the source content; after delivery they can be repeated as a quality control step. The second scan brings out the points that the translation has broken.

The most valuable thing about these tools is that they make visible the elements hidden in the deep structure, which an inexperienced eye finds hard to notice. They also offer an instructive framework for beginners.

Automated scanning is not sufficient on its own, however. A machine can answer the question of whether an image has a description; whether that description is meaningful can be judged only by a human being. The two methods do not take each other’s place, and the best result comes from applying them in sequence.

The Türkiye context

In Türkiye, accessibility is defined as a general obligation by Law No. 5378 on Persons with Disabilities. The guides prepared for the websites of public bodies also refer to international criteria. The level of implementation varies from one institution to another.

In the private sector the matter largely remains a voluntary one. That creates a risk for Turkish companies opening up to the European market; the regulations of the target market arise not from the product itself but from the country in which it is published.

On the language side, Turkish support in screen readers is a heading of its own. The way abbreviations, number formats and English terms are read aloud can produce unexpected results. When writing text alternatives, thinking about how they will sound when read aloud is a practical habit.

This article is for general information and is not legal advice.

What does this mean for you?

If you limit the scope to visible text alone when you place a translation order, your product’s accessibility features are lost in the target language. On most projects, widening the scope is a small additional cost and a clear gain in return.

1. Add image descriptions and page titles to the translation scope in writing.
2. Have the descriptions of any images changed during localisation rewritten.
3. Plan transcripts for video and audio content.
4. Have an automated scan run twice, once before delivery and once after it.
5. Assess the scan results together with a trial by someone who uses a screen reader.

Most of these steps can be added to your existing processes. For an assessment suited to your scope you can ask for a quote, and you can reach the other related articles from our knowledge centre.

Frequently asked questions

How is digital accessibility defined?

It is the designing and developing of digital products, tools and technologies in such a way that people with differing abilities can interact with them successfully. The definition covers not only permanent disabilities but temporary and situational constraints as well.

What are the POUR principles?

Perceivable, operable, understandable and robust. Information must be perceivable, all components must be operable, the information presented must be readable and understandable, and content must be accessible to a variety of user agents.

Why is alternative text skipped in translation?

Because it is not visible on screen; it sits inside the structure of the code. The visible interface may be translated while the image descriptions and page titles stay in the source language. That in turn leaves the person using a screen reader outside.

Are automated checkers enough?

Not enough, but valuable as a starting point. They list the gaps inside the code quickly and offer an instructive framework for beginners. Whether the text is meaningful can be judged only by a human being.

Sources

• Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, pp. 109–113.
• W3C (2018). Web Content Accessibility Guidelines (WCAG) 2.1. World Wide Web Consortium.
• Law No. 5378 on Persons with Disabilities (2005). Official Gazette.