Web accessibility.

Web accessibility means a website can also be used by people with visual, hearing, motor or cognitive differences.

The definition is easy; the practice is hard. The difficulty is not technical: accessibility almost always comes up after the work is done, as a “let’s add this too” item. At that point, retrofitting is expensive, incomplete and mostly cosmetic. This guide argues the opposite — accessibility is a design decision, not a layer added afterwards.

The guide does three things. It relays the legal framework in Türkiye as it stands. It separates the four principles and three conformance levels of WCAG 2.2 without leaving room for confusion. And most importantly: it shows what automated audit tools measure and what they do NOT — because a high accessibility score does not mean an accessible site.

The situation in Türkiye: the 2025 circular

The Presidential Circular dated 24 June 2025 put accessibility on the agenda for the websites and mobile applications of public institutions. The standard the circular references is WCAG 2.2, and the targeted conformance level is A.

The Ministry of Family and Social Services followed with a checklist. The list expands the 31 success criteria of WCAG 2.2’s level A into 126 assessment questions, grouped under the four principles. Not an abstract statement of principle, but a document that can be audited item by item.

The circular directly binds the public sector. In practice its reach is wider: suppliers working for the public sector, agencies entering public tenders and software vendors selling to corporate buyers end up looking at the same list. As of 2026, level AA counts as the de facto standard for public institutions and large-scale businesses — one step above the level A the circular mandates.

The law asks for level A; the market expects AA. On most sites, the gap is a few days of work.

Four principles: perceivable, operable, understandable, robust

All of WCAG rests on four principles, known by their initials as POUR. Every success criterion lives under one of the four, and together they give the operational definition of the word “accessible.”

1. Perceivable — content must be presented in a form the user can perceive. Alternative text for images, captions for video, a second distinguishing cue besides color.
2. Operable — interface components must be operable. Without a mouse too: by keyboard, by switch access, by voice command.
3. Understandable — both the text and the interface’s behavior must be predictable. An error message must say what happened and what to do.
4. Robust — content must be reliably interpretable by today’s and tomorrow’s assistive technologies. Semantic HTML is the foundation of this.

The order is not accidental; it is a chain of dependencies. Content that cannot be perceived cannot be operated; an interface that cannot be operated cannot be understood; and even if understood, it will not work tomorrow unless it is robust. Auditing a site in this order works too.

A, AA, AAA: which level?

WCAG defines three conformance levels, and they stack: a site conforming to AA also conforms to A. The levels are an ordering of scope, not difficulty — AAA is not “better,” it is broader, and some of its criteria are unrealistic for every content type. Even the W3C itself does not recommend targeting AAA for an entire site.

1. A — the floor. Criteria whose absence makes content completely inaccessible for some users. Alternative text, keyboard access, no focus traps. The circular in Türkiye references this level.
2. AA — the de facto standard. Contrast 4.5:1, non-text contrast 3:1, visible focus, touch target 24×24 CSS pixels. This is the level expected in corporate and public work.
3. AAA — extended. Contrast 7:1, touch target 44×44, sign language interpretation. Not recommended as a whole-site target; meaningful in specific flows.

The practical advice: take AA as the floor and collect AAA where it is cheap. Reaching AAA on contrast, for instance, is often just a color change and costs nothing — this site’s body text measures 18.15:1 against the paper ground, two and a half times the AAA threshold of 7:1. Adding sign language to captions, by contrast, is a real production cost. Two criteria written at the same level do not deserve the same priority.

Accessibility cannot be added later

A site’s accessibility is largely decided the moment the palette is chosen. The contrast ratio is a color decision; the focus indicator is a design decision; the touch target is a grid decision. These live at the deepest layer of the CSS, at token level. Returning to these decisions after the site is finished is like putting back a brick pulled from the foundation.

The healthy method is therefore to treat accessibility as a budget item, not an audit item — like a performance budget. If the contrast of every color pair is written in the palette file, the designer cannot use the wrong pair. If the focus ring is a token, no component forgets it. If the touch target is a minimum, it does not shrink on mobile.

Adding accessibility afterwards is like consulting the earthquake code after the building is finished.

The measured floor: this site’s own numbers

Claimed accessibility and measured accessibility are different things. The values below are computed from this site’s palette file, and the verification suite re-measures them on every run — if a color changes, the test turns red. The values are computed with WCAG’s own relative luminance formula.

1. Body text / paper ground — 18.15:1. The AAA threshold is 7:1.
2. Secondary text / paper ground — 7.07:1. Just above the AAA threshold; this value was chosen deliberately.
3. Accent color / paper ground — 10.22:1. Links and the focus ring use this color.
4. Body text / card ground — 16.01:1.
5. Accent on dark / ink — 4.55:1. Just above the AA threshold of 4.5:1 in the dark band.
6. Error color / paper ground — 6.25:1. Used only in form errors; never in decoration.

The real function of this table is not publishing the numbers but freezing them. When the palette file is edited and a color drifts, the test turning red means the contrast decision no longer depends on anyone’s eye. That is how accessibility is preserved: not by eyeballing, but by a guard.

The limit of automated auditing

Accessibility tools — axe, Lighthouse, WAVE — are genuinely useful and should run on every project. But they share one blind spot: they only measure the questions they ask, and the questions they do not ask never appear in the list. A high score does not mean “everything is fine”; it means “the answers to what I asked were good.”

Exactly this happened on this site, and it is on record. Lighthouse accessibility score 96, zero axe violations. At the same time, the only visual boundary of the text fields in the contact form — the site’s single conversion path — measured 1.29:1 contrast against the ground; where a field began and ended was unclear even for a sighted user.

The reason is simple and instructive: axe’s contrast rule measures TEXT against its own background. WCAG 1.4.11, “non-text contrast,” concerns the boundary of the interface component and asks for 3:1. They are different questions; the tool was asking the first, the defect was in the second. The border was raised to 3.13:1 and a guard was added.

The score was high because the score was not asking that question.

The lesson is not to distrust tools. The lesson is: a score cannot be trusted without knowing which question the tool asks. Automated auditing goes in front of the checklist, not in place of it; the rest of the list is walked by hand.

Where to start

For someone who wants to make an existing site accessible, here is a starting list ordered by impact. The order matters: the items at the top affect more users and cost less.

1. Do a keyboard tour. Put the mouse away and try using the site end to end with only Tab and Enter. Every place you get stuck is a defect.
2. See where the focus is. Whenever you press Tab, which element is selected must always be visible. If it is not, that is a 2.4.7 violation.
3. Measure contrast, do not eyeball it. The eye misleads; compute the palette pairs and write them into the file.
4. Write alternative text for images — give decorative ones EMPTY alternative text, not an omission.
5. Fix the heading hierarchy. One h1, an unskipped h2/h3 order. This is the screen reader user’s table of contents.
6. Make form errors audible. The error text must be tied to the field and announced from a live region.
7. Tie motion to the preference. If the operating system says “reduce motion,” the animation must not be set up — not toned down: not set up.

These seven steps close most of level A and a significant part of AA. The rest — touch targets, non-text contrast, screen reader verification — is covered in detail on the cluster’s separate pages.

One last note: accessibility is misunderstood when it is presented as a minority issue. Keyboard navigation also serves the power user; high contrast also serves a phone in sunlight; a clear error message serves everyone in a hurry; captions also serve someone watching video in a quiet room. Accessible design is not design for fewer people — it is design for more situations.