Thailandka
Все правовые документы

Accessibility Statement

How accessible Thailandka is today against WCAG 2.2 Level AA — what we built in, what still does not work, how we tested, and how to tell us when something blocks you.

Effective 9 September 2026 · Last updated 9 September 2026

This statement is about how usable www.thailandka.com is with a keyboard, a screen reader, magnification or high contrast — and how to reach a person when it gets in your way.

What this statement covers

The whole website at www.thailandka.com, in all seven languages we publish it in: English, Thai, Russian, Spanish, Italian, Hebrew and Chinese. There is no Thailandka mobile app; if we build one it gets its own statement.

Our automated scans cover the home page in all seven languages and the deeper pages in fewer — the table under How we tested says which. The catalogue is sample content and the site is not yet listed in search engines. Neither reduces what we owe you: every commitment here applies today.

The standard we hold ourselves to

We assess this site against EN 301 549 V4.1.1 (2026-09), the European accessibility standard. It takes its web requirements from WCAG 2.2 at Level AA — the Web Content Accessibility Guidelines are the international rulebook for making a website usable by disabled people, and AA is the middle of their three levels, the one regulators expect. In plain terms: you can perceive everything on the page, operate it, understand it, and rely on it working with your assistive technology.

That one claim covers Israel and Thailand too. Israeli Standard 5568 — the bar regulation 35א sets for websites — rests on the same guidelines at Level AA, and WCAG 2.2 AA meets the earlier versions underneath it. Thailand's national guidance follows WCAG as well; it does not bind a private commercial site like ours, and we test to it anyway.

Three things we do not claim: no presumption of conformity with any European directive, because no harmonised standard exists that would create one; no badge, seal or certificate, because nobody has certified this site; and no percentage score, because no honest single number exists. One thing we will not install: an accessibility overlay. Overlays do not deliver conformance, and they interfere with the assistive technology you already use.

Where we stand today

Why not a stronger word. We have done no screen-reader testing, no testing with disabled users, and no independent audit. A full claim must also hold for complete journeys: we scan one, in Hebrew, at every step, and have not done the same in the other six languages.

What we have built in

These are in the site today, not plans. Each is either checked by a test we run against a production build, or structural to how the site is written.

  • Everything on the pages we test works from the keyboard, with a visible focus ring — our suite walks the tab order and fails when one is missing.
  • One first-level heading per page, headings that descend without skipping, and proper landmarks — checked on the home page and a legal document, and structural elsewhere.
  • Colour contrast checked automatically on every page we scan, and in dark mode on the English home page. The theme follows your system setting until you choose.
  • Every image carries a text description — written out where it means something, blank where it is decoration. The build checks this on the home page.
  • Full right-to-left support in Hebrew, and every page declares its language and direction, so a screen reader switches voice for these English documents.
  • Text can be enlarged and pages reflow to a single column at narrow widths. We have not measured that at 200% zoom in every language.
  • Animated decoration stops for anyone whose system asks for reduced motion — and our scans run in that state, because it is what a motion-sensitive visitor gets.
  • The map's draw-to-search also works from the keyboard, through a list of named places. It does not yet do everything drawing does.
  • Serious and critical findings fail our accessibility suite, which we run against a production build before we ship. It is not yet an automatic release gate.
  • The link to this statement sits in the footer of every page, in the same position in every language.

What does not work yet

Here is what we know is imperfect or unchecked, where you will meet it, and what we are doing. The rule number is there for anyone who wants it. If you hit something that is not on this list, please tell us.

Known accessibility barriers and gaps in our testing
What does not work, or is uncheckedWCAG ruleWhere you will run into itWhat we are doing
Alternative text on our photographs describes the picture rather than its purpose on the page. No tool can tell the difference.1.1.1 Non-text Content (A)Home page, destination cards, galleries, guidesRewriting them for purpose, not content.
Some things may be shown by colour alone — the savings badge and the partner colours are where to look.1.4.1 Use of Colour (A)Search results, property comparisonA manual pass, adding a text or shape cue.
The two price fields are named only by the example figure inside them, which vanishes as you type, so a screen reader may not tell the lowest from the highest.3.3.2 Labels or Instructions (A), 4.1.2 Name, Role, Value (A)The filters on the search results pageGiving each field a visible label.
Search-by-drawing on the map needs a pointer. The keyboard route searches around named places, but cannot reproduce an arbitrary shape.2.5.7 Dragging Movements (AA)The map view opened from a destinationExtending it to build an area without drawing.
Not every small control has been measured against the minimum target size.2.5.8 Target Size, Minimum (AA)Filter chips, star ratings, card and map controlsMeasuring them and enlarging what falls short.
The header stays fixed as you scroll. We have not checked everywhere that it stays clear of the item you just moved focus to.2.4.11 Focus Not Obscured, Minimum (AA)Any long page — legal documents and guides most visiblyTesting focus under it on every kind of page.
No screen-reader testing, no testing with disabled users, no independent audit. The redirect that hands you to a booking site is not itself scanned.Whole pages and complete journeys (EN 301 549, clause 9.6)The whole siteNVDA and VoiceOver passes, then an audit.

WCAG 2.2 added six criteria and we walked all six. Four bite here and appear above: 2.4.11 Focus Not Obscured, 2.5.7 Dragging Movements, 2.5.8 Target Size and 3.2.6 Consistent Help — which is why the accessibility and contact links hold the same footer position in every language, including those that mirror right to left. We meet 3.3.7 Redundant Entry: the dates and guests you enter are carried through search and never asked for twice. 3.3.8 Accessible Authentication cannot arise — there are no accounts and no login.

Content we did not make

A statement like this may exclude content the operator did not write, fund or control. We have nothing to exclude: the catalogue is our own seeded content, and the photographs are stock images we chose and placed.

One gap to know now: those listings are a sample catalogue, so we hold no accessibility information about individual properties. Step-free access, roll-in showers and hearing loops are not described or filterable here yet — check with the property or the booking site before you book. When our partners supply that information we will show it rather than drop it on the way through.

We are not claiming anything is too expensive to fix

Some rules let an operator leave a problem unfixed by arguing the fix would be an unreasonable burden. We make no such argument: nothing above is left undone because of what it would cost.

Tell us about a barrier

If something here stops you, or you need information in a format you can use, tell us. Give the page address, what you were trying to do, and what happened instead. Naming your browser and any assistive technology helps, but not knowing should not stop you writing. The same address is on our contact page.

Accessibility contact:to be supplied: accessibility contact address(The link to this statement is in the footer of every page, in every language.)

What we commit to: a reply within five working days; a confirmed barrier corrected as soon as we can and no later than 60 days from the day your message reaches us; that we tell you when it is done; and another way to get what you needed meanwhile. We record every message with its arrival date, so that clock runs from when you write.

There is no contact form here, deliberately. The only things you can type into this site are the search fields — dates, guests, a price range — and none of them reaches us as a message. A form built only for barrier reports would create the collection point we tell you does not exist: see what we do with data about your visit.

If we do not put it right

You do not have to come to us first, and going to a regulator does not depend on having complained to us. But telling us first is usually fastest: in Israel it starts a 60-day clock we must meet, and everywhere it is how we learn the barrier exists.

  • Israel — the Commission for Equal Rights of Persons with Disabilities, at the Ministry of Justice, which supervises the Service Accessibility Regulations.
  • European Union and EEA — there is no single European body. Each Member State designates its own market surveillance authority; contact the one where you live. In most Member States an organisation representing disabled people can act for you.
  • Thailand — the Department of Empowerment of Persons with Disabilities, at the Ministry of Social Development and Human Security, and the Thai courts, under the Persons with Disabilities Empowerment Act B.E. 2550 (2007).

If you are not sure which authority covers you, write to us and we will tell you where to look — even when the complaint is about us. And nothing in our Terms limits your accessibility rights.

How we tested

Method: self-assessment, following the structure of the W3C's Website Accessibility Conformance Evaluation Methodology, which is built to accommodate in-house evaluation. Nobody outside Thailandka prepared or reviewed it.

The automated part runs axe-core 4.13.0 from our end-to-end suite, in Chrome, against a production build — the build a visitor gets. Serious and critical findings fail the run. The rules we switch on are the WCAG 2.0, 2.1 and 2.2 A and AA sets, so the machine checks the standard we claim. Four other checks run beside it: keyboard traversal, a Hebrew right-to-left check, heading structure, and a text description on every image.

Automated scan coverage
Kind of pageLanguages scannedThemes scanned
Home pageAll sevenLight in all seven; dark in English
Search resultsEnglishLight
Property pageEnglishLight
Guide pageEnglishLight
Map view, opened over the home pageEnglishLight
Legal documents — a rotating sample of three: Terms, Privacy, CookiesEnglish, Hebrew, ThaiLight
Search, filter, sort, property, click-out control — one journey, scanned at every stepHebrewLight

The honest limit: automated testing cannot decide whether a site conforms, because tools find only what a machine can check. The judgement calls need a person — whether the focus order makes sense, whether a link says where it goes, whether reading order survives mirroring in Hebrew. We do those by hand, on the kinds of page above.

When this statement was prepared

Prepared on 9 September 2026, following an evaluation of the site and its accessibility test suite carried out on 9 September 2026. Last reviewed on 9 September 2026. We review it at least once a year, and sooner after any substantial change to the site or to the standards we test against.

What we are doing next

We have tied these to the point where the site stops showing sample data and opens with real hotels, rather than to calendar dates we might miss.

  1. Label each price field in the filters, so the lowest and highest are told apart when read aloud.
  2. Extend the scans to the dark theme on every kind of page, not only the English home page.
  3. Test every kind of page with a screen reader: NVDA in Firefox, VoiceOver in Safari.
  4. Measure every interactive target against the minimum size, and check against regressions.
  5. Make the accessibility suite a required check before deployment, so a failing run cannot ship.
  6. Commission an independent audit before we open with real inventory, and publish what it says here.

Two changes ahead will change this statement, and we will update it before they ship: live partner data brings in text and images we did not write, and any consent banner we ever add becomes part of this claim — keyboard operable, dismissible, unable to trap or hide focus, or it does not ship.

The language of this statement

The English text is the operative version. Translations are provided for convenience; if a translation and the English differ, the English governs.

Today this statement, like our other legal documents, is published in English at every language address of this site, and the notice above says so. That is not good enough for this one: a page telling you how to report a barrier is no use in a language you do not read. Full Hebrew and Thai versions are in preparation; this paragraph changes when they are published. Until then, write in any of our seven languages and we will answer in yours.

Version history

Version 1.0 — 9 September 2026
First publication. Status: partially conforms to EN 301 549 V4.1.1 / WCAG 2.2 Level AA. Seven entries in the barrier and gap table; self-assessment method and reporting route recorded.

When a barrier above is fixed we remove its row and record the change here, so you can see what moved and when.