What Is Universal Design? Why Accessibility Cannot Be Added Later

In most projects, accessibility comes up at the final stage. The product is built, launch approaches, and only then does someone ask what can be done to comply. This order of events is expensive and its results are limited. The alternative approach is called universal design, and it proposes asking the question at the very beginning.

Contents

The approach rests on taking the needs of people with differing abilities into account from the earliest stages of development. It is not a patch added afterwards but part of the product’s architecture. It matters for localisation too, because the translation stage can either carry that architecture through or damage it without anyone noticing.

In this article we look at how the concept is defined, why it is a matter for the early stages, what role customisation plays and how it connects to social participation. We then summarise the problems encountered by type of disability and the criteria put forward as recommendations.

What is universal design?

The definition in the international convention is clear: the design of products, environments, programmes and services to be usable by all people, to the greatest extent possible, without the need for adaptation or specialised design. What stands at the centre of the definition is the requirement that no adaptation should be needed.

In the field of human-computer interaction, the approach covers the whole set of design methods aimed at meeting the diversity of needs that arises when interactive technologies are developed. The goal is not merely to comply; it is to improve human performance, health and social participation.

The concept also goes by the name design for all, and the two labels express the same idea. The difference lies in emphasis: one looks at the reach of the design, the other at the diversity of users. In practice the two are used side by side.

Its relationship with localisation is direct. Ideally the product has already been built and tested with accessibility and universal design principles in mind. The translation team’s task is to reproduce those features in the target language: not to create them from scratch, but to carry them across.

Why can it not be added later?

The essence of the approach is that the needs of people with differing abilities are brought in from the earliest stages of development. They should not be treated as an afterthought. The principle looks simple, but in practice it is the one most often broken.

The reason is structural. An information scheme built on colour, an interface with a fixed font size, or a task that can only be solved by sound are decisions that cannot be undone later. Once they have been taken, all that can be done is partial compensation through patches.

The cost side points the same way. A decision taken early takes no longer than a meeting, whereas taking the same decision late means redevelopment, retesting and retranslation. Across a whole project, the difference turns into a visible line item.

Localisation faces something similar. If text alternatives were never written in the source product, there is nothing to translate at the translation stage. Material that is missing does not appear of its own accord in the target language.

That leaves two options. Either the missing descriptions are commissioned in the source language and then translated, or they are produced directly in the target language. The second route looks faster but carries a risk of inconsistency between languages; which one to choose should be decided according to the scale of the project.

One size does not fit all

The limits of universal design are debated as well. In games, a one-size-fits-all solution is sometimes impossible because of the dynamic and interactive nature of the product (Mangiron 2021). Think of a visual puzzle: the whole game is built on sight.

In that case the route that comes to the fore is to increase the degree of customisation and the number of accessibility features on offer. When users can adjust things to their own needs, the diversity that a single design cannot cover becomes possible to meet.

Customisation concerns the text as well. If it is not clear what the options on the settings screens do, the feature does not count as present. The descriptions of accessibility settings are among the parts of an interface that need translating with the greatest care.

The same logic holds for software and web products. Offering options for text size, contrast, reduced motion and sound is a more realistic goal than searching for a single flawless design.

Customisation has its own limit too. As the number of options grows, the settings screen can itself turn into a barrier. Putting the few most needed settings somewhere visible and the rest at a second level therefore tends to give better results.

Accessibility is a question of inclusiveness

Design for all does not mean developing products separately for particular groups. Specially designed products can be valuable, but the real aim is for mainstream products to be open to as many people as possible.

The reasoning is social. Users care about using the same product as their friends and families; social participation grows largely out of that shared ground (Cairns et al. 2021). Offering a separate version may solve the technical problem while weakening the social tie.

This perspective takes accessibility out of the category of a compliance obligation and moves it under the heading of inclusiveness. The more people your product is open to, the wider your user community. Here the commercial outcome and the social outcome point in the same direction.

Localisation adds a further layer to this picture. Language is a condition of access too: a user who cannot read in their own language still cannot use a product that is technically accessible. The two fields share one goal, which is to open content up to more people.

That shared goal is reason enough to handle the two together within the same project. The translation team already touches every line of the text; dealing with accessibility-related texts in the same pass takes far less effort than setting up a separate project.

Types of impairment and the problems encountered

Concrete examples bring the discussion down to earth. In game accessibility, the problems most often met fall under four headings. The table below shows them together with the corresponding points to watch in localisation.

User group	Problem encountered	What it means on the text side
Cognitive impairments	Difficulty level, little time to decide, long manuals	Plain sentences, short tutorial steps
Hearing impairments	Information and tasks given by sound alone	Providing a written equivalent of audio information
Visual impairments	Information given by image alone, small text and icons	Translating text alternatives in full
Motor limitations	Dependence on a controller, no support for alternative input	Translating settings screens clearly and understandably

Solutions come from several directions. For motor limitations, some companies have produced adaptive controllers; one example released in 2018 provides a high degree of flexibility during play. Hardware solutions only take on meaning alongside adjustments on the software side.

For limitations of vision, the basic criteria recommended come down to the following points.

1. No essential information should be conveyed by colour alone.
2. A default font size that is easy to read should be used.
3. Plain, clear text formatting should be chosen.
4. High contrast should be provided between the text and the background.
5. Interactive elements should be placed generously and with space between them, especially on small and touch screens.

Most of these criteria are design decisions, but the last point bears directly on translation. Labels that grow longer in the target language can break a generous, well-spaced layout. Length limits are therefore not merely a matter of aesthetics but of accessibility.

How are design and translation planned together?

The most practical way to make the two fields work together is to write accessibility requirements into the product requirements list. A verbal agreement is not enough; a written item settles any later argument about scope and takes its place automatically in the translation brief.

The second step is to decide who checks what. The design team becomes responsible for colour contrast, the development team for code structure and the language team for descriptive texts. When responsibility is not shared out, gaps appear that everyone can see and nobody owns.

The third step is to add accessibility items to the quality control checklist. Whether image descriptions have been translated, whether page titles are in the target language and how clear the settings screens are can all be added to that list easily.

The fourth step is real use. A short trial with someone who uses assistive technology brings out problems that no automated scan can see. That trial gives the highest return when it happens before launch.

Finally, continuity is needed. Every time the product is updated, new texts are added and some of them touch the accessibility layer. A one-off audit will have lost most of its validity six months later.

The Türkiye context

In Türkiye the accessibility debate ran for a long time through physical environments; ramps, lifts and pavement adjustments were at the centre of the agenda. Giving the digital side the same attention is more recent. That delay has left accessibility, in many products, as a heading that comes after development.

Accessibility expertise is not yet widespread in local software teams either. Even so, a few low-cost practices can make a difference: a text size setting, adequate contrast and support for keyboard navigation come first among them.

The structure of Turkish also has to be taken into account. Labels that grow longer can narrow touch targets, and the way screen readers pronounce abbreviations and English terms can produce unexpected results. These details only come to light when the product is tried on a real device with a real user.

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

What does this mean for you?

If you are building a new product or opening an existing one to a new market, writing accessibility into the scope document from the outset is the cheapest route. Additions made later cost more and usually remain partial.

1. Add accessibility requirements to the product requirements list in the first release.
2. Test your colour, sound and text size decisions at the design stage.
3. Have the texts of the settings and accessibility screens translated with particular care.
4. Leave a margin for label length that is specific to the target language.
5. Try the product at least once with real users who rely on assistive technology.

These steps are not a one-off investment but a habit that has to be kept up. For work that fits your scope you can get in touch, and you can read other articles on the subject in the knowledge centre.

Frequently asked questions

How is universal design defined?

According to the definition in the international convention, it is the design of products, environments, programmes and services to be usable by all people, to the greatest extent possible, without the need for adaptation or special design.

Why can accessibility not be added later?

Because the decisions taken at the design stage shape every stage that follows. When the needs of people with differing abilities are not taken into account from the very start, later additions both cost more and stay limited.

Does a single design suit everyone?

Not always. In interactive and dynamic products in particular, a single solution may not meet every need. In that case, increasing the customisation options and the accessibility settings is seen as the route that comes to the fore.

Is making a separate version for disabled users the answer?

Usually not. Rather than separate products, the preference is for mainstream products to be open to as many people as possible, because users care about using the same product as their friends and families.

References

• Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, p. 115.
• United Nations (2006). Convention on the Rights of Persons with Disabilities, Article 2.
• Cairns, P., Power, C., Barlet, M., Haynes, G. and Kaufman, C. (2021). Enabled players. Games and Culture, 16(2), pp. 262–282.