Accessibility in one paragraph
An accessible website is one that people can perceive, operate and understand whatever their situation, and the standard to aim for is WCAG 2.2 at level AA. It is the version most accessibility laws and procurement rules point to, and it is achievable for an ordinary business site without special technology.
Think of a customer who is blind and uses a screen reader, a retired guest whose eyesight is not what it was, someone with a tremor who cannot hit tiny buttons, or a delivery rider reading your menu on a phone in full Bangkok sun.
Most of the work is not exotic. It is readable contrast, real text alternatives for images, labelled forms, links that say where they go, a page that works with a keyboard, and the correct language declared in the code. Get those right and you have fixed the bulk of what trips people up. Accessibility is sometimes filed under website design trends for 2026, but it is not a trend: it is basic quality, and the sites that treat it that way age better.
Who benefits
- Permanent disability: blindness, low vision, deafness, motor and cognitive conditions.
- Ageing: smaller text and weak contrast become harder to read every decade.
- Temporary limits: a broken wrist, an eye infection, a lost pair of glasses.
- Situational limits: glare on a screen, a noisy BTS carriage with no headphones, one hand holding a bag.
What is WCAG 2.2, without the jargon?
WCAG stands for Web Content Accessibility Guidelines. It is published by the W3C, the body that also looks after HTML and CSS standards (our web design glossary explains those terms). Version 2.2 became a W3C Recommendation in October 2023 and adds a handful of criteria to 2.1, mostly about focus visibility, drag movements, target size and not making people re-enter information they already gave you.
The four principles
Every rule in WCAG sits under one of four principles. In plain terms:
- Perceivable: people can see or hear the content in some form. Images have text alternatives, videos have captions, text has enough contrast.
- Operable: people can use every control, including by keyboard, and have enough time to do so.
- Understandable: text is readable, pages behave predictably, and forms explain mistakes.
- Robust (compatible): the code is clean enough that browsers and assistive technology can interpret it.
Levels A, AA and AAA
Each success criterion has a level. Level A is the floor: failing it blocks some people completely. Level AA adds the criteria that make a site comfortable for most users, such as a 4.5:1 contrast ratio for normal text and visible keyboard focus. Level AAA is stricter and not realistic for every page; even W3C does not recommend it as a general policy for whole sites.
When a law, a tender or a partner asks for "WCAG compliance", they almost always mean 2.1 or 2.2 at AA. That is the sensible target for a business site in Bangkok too.
Which accessibility failures do most sites have?
Every year WebAIM, a non-profit at Utah State University, runs automated tests on the home pages of the top one million websites. Its February 2026 report found detected WCAG 2 failures on 95.9% of those home pages, with an average of 56.1 errors each. Six error types made up about 96% of everything it detected, which is good news: a short list of fixes covers most of the problem.
These are the six, with the share of home pages affected in the 2026 report and what to do about each.
- Low contrast text (83.9%)Pale grey on white and white on light photos fail most often. Check every text colour against its background and aim for at least 4.5:1, or 3:1 for large text.
- Missing alt text (53.1%)Give meaningful images a short description of what they show or do. Decorative images get an empty alt so screen readers skip them.
- Missing form labels (51%)Placeholder text is not a label. Every field needs a visible label tied to it in the code.
- Empty links (46.3%)Icon-only links, such as a LINE or Facebook logo, need an accessible name, otherwise a screen reader just says link.
- Empty buttons (30.6%)Menu toggles, search icons and slider arrows need a text name too, even if it is visually hidden.
- Missing page language (13.5%)Declare the language on the html element, lang en or lang th, so assistive technology pronounces the text correctly.
Keyboard, focus and forms
Put your mouse aside and press Tab from the top of your home page. This two-minute test tells you more than most reports.
What to check with the keyboard
- Can you reach everything? Menu items, the language switcher, the booking button, the WhatsApp link, cookie consent choices and every form field.
- Can you see where you are? A visible focus outline should move with each Tab. Many themes remove it because a designer disliked the look. WCAG 2.2 added criteria so focus is not hidden behind sticky headers or chat bubbles.
- Does the order make sense? Focus should follow the visual reading order, left to right and top to bottom. If it jumps from the header to the footer and back, the underlying structure is out of step with the design. Our guide to choosing a page layout covers how structure and visual order should line up.
- Can you get out? Pop-ups and menus must close with Escape and return focus to where you were.
Forms that everyone can complete
Forms are where accessibility turns into lost enquiries. Keep each label visible above its field, mark required fields in words rather than only with a red asterisk, and let the browser autofill names, phone numbers and emails. When something is wrong, say what and how to fix it next to the field, for example "Enter a Thai mobile number with 10 digits", not just a red border. Colour alone never carries meaning, because many people with colour vision deficiency cannot tell a red border from a grey one.
WCAG 2.2 also asks that you do not make people type the same details twice in one process, and that login steps do not rely on puzzles or memory tests without an alternative.
Headings, link text, video and motion
Screen reader users rarely listen to a page from top to bottom. They jump between headings and pull up a list of links. That makes two things matter more than they seem.
Headings as a table of contents
Use one H1 for the page topic, H2s for main sections and H3s beneath them, in order. Do not pick a heading level because of its font size; style it in CSS instead. A page where every bold line is an H2 reads like a list of shouting. A clean heading order also helps search engines, one of the points in our guide to how website design affects SEO.
Link text that makes sense alone
"Read more" repeated nine times is useless when heard out of context. Write the destination into the link: "see room rates", "download the menu in Thai". The same habit helps sighted visitors scanning the page, and it is one of several points in our tips for writing website copy.
Video, audio and movement
- Add captions to videos with speech. Auto-generated captions are a start, but check them, especially where Thai and English are mixed.
- Provide a transcript for podcasts or audio tours.
- Autoplaying video or carousels need a visible pause control. Anything that moves for more than five seconds should be stoppable.
- Respect the reduce-motion setting on phones and computers for parallax and large animations; they can cause nausea for people with vestibular disorders.
- Never flash content more than three times a second.
Zoom and reflow
People should be able to zoom text to 200% without losing content, and the layout should reflow to a narrow column at 320 CSS pixels wide without sideways scrolling. Do not block pinch zoom on mobile.
Thai-language accessibility
Most accessibility guides are written for English. A bilingual Bangkok site has a few extra things to get right.
Declare Thai where Thai appears
The Thai version of a page should carry lang="th" on its html element, and the English version lang="en". If an English page contains a Thai phrase, such as a restaurant dish name, wrap it in an element with lang="th". Without this, a screen reader set to English may try to read Thai script with English rules, or skip it.
Give tone marks room
Thai stacks vowels and tone marks above and below the consonant line. A line height that looks fine in English, say 1.3, can make Thai marks collide with the line above. Around 1.6 to 1.8 for Thai body text is a common starting point, then check it on real content. Pick a Thai web font with clear, looped letterforms for body copy; loopless display styles are harder for older readers at small sizes.
Screen readers and word breaks
Thai is written without spaces between words, so screen readers and browsers rely on dictionaries to find word boundaries. The main screen readers, such as NVDA on Windows, VoiceOver on Apple devices and TalkBack on Android, offer Thai speech, but results vary with the voice and version installed. Test key pages with at least one of them, and avoid inserting invisible characters or manual line breaks into Thai text to force wrapping; they can break how it is read aloud.
Mixed scripts in forms
Let people type names in Thai or Latin script. Validation that only accepts A to Z rejects many Thai customers before they reach you.
What the law says
This is general information, not legal advice. Check your own position with a lawyer if accessibility could affect a contract or a market you sell into.
In Thailand
At the time of writing we have not found a Thai law that requires private company websites to meet WCAG. Thailand does have laws on the rights of persons with disabilities, and government agencies work to their own web standards, but we will not state a private-sector obligation we cannot point to. If you supply a government body or a large corporate, their tender documents may ask for WCAG AA, so read them carefully.
If you sell abroad
Rules elsewhere can reach a Bangkok business that sells to customers overseas. The clearest example is the European Accessibility Act, Directive (EU) 2019/882. Its requirements have applied since 28 June 2025 to a set of products and services offered to consumers in the EU, including e-commerce services, with an exemption for microenterprises providing services. EU member states implement it through national laws, and the technical requirements are generally met by following the European standard that maps to WCAG AA.
A Thai hotel taking direct bookings from European guests, or a shop shipping to Europe, should at least ask whether it is in scope. The practical answer is the same either way: build to WCAG 2.2 AA and you are well placed.
Testing your site
Automated tools catch a useful share of problems quickly, but not all of them. A tool can see that an image has alt text; it cannot tell whether "IMG_2044" describes anything. Use both kinds of check.
Automated checks (free)
- WAVE from WebAIM: a browser extension that marks errors directly on the page.
- Lighthouse: built into Chrome DevTools, with an accessibility score and a list of failed audits.
- axe DevTools: a browser extension from Deque, popular with developers because it gives few false alarms.
Manual checks (about half an hour)
- Tab through the home page, a service page and your main form.
- Zoom the browser to 200% and read a full page.
- Turn on VoiceOver or TalkBack on your phone and try to book, buy or send an enquiry.
- Look at the page in greyscale: does anything rely on colour alone?
- Read the link and button text out of context.
W3C publishes a set of "easy checks" for a first review that non-developers can follow.
Why overlay widgets are not the fix
Overlay plugins add a floating icon with contrast toggles and text resizing, and some claim instant compliance. They do not repair missing labels, broken focus order or unclear link text in the underlying code, and they can interfere with the screen readers disabled users already rely on. Many accessibility practitioners advise against them. Fix the site itself instead.
Building it in from the start
Retrofitting accessibility onto a finished site costs more than planning for it. A few decisions early on save most of the rework.
- Choose colours with contrast in mind. If your brand palette is pale, agree an accessible text colour and button colour now, and record them in your brand guidelines for the web so every future page uses them.
- Make components accessible once. A button, a form field or a menu built correctly and reused everywhere means you fix things in one place. That is one of the quiet benefits of a website design system.
- Write alt text and captions with the content, not after launch when nobody remembers what the photos show.
- Test on real content, including long Thai names and menu items, not lorem ipsum.
For an applied example, look at how a menu is handled in our round-up of what makes a good restaurant website: a menu as a scanned image fails nearly every check in this guide, while the same menu as real text works for search engines, translation tools and screen readers alike.
When we build a site, contrast, labels, keyboard focus, language attributes and heading structure are part of our design process from the first layout, and they carry through the Starter package (from THB 10,000) and the bilingual Business package (from THB 30,000). If your current site fails the checks above, a redesign is often cleaner than patching an old theme. Send us the address and get a written quote with the scope spelled out.
Who reviewed this guide
Who builds your site
Litesh Dhir
Builds and ranks the websites: the systems behind the 17 client sites whose Search Console numbers we publish.
More about usMore on web design and UX
Sources
- W3C: Web Content Accessibility Guidelines (WCAG) 2.2
- WebAIM: The WebAIM Million, 2026 report
- W3C WAI: Easy Checks, a first review of web accessibility
- EUR-Lex: Directive (EU) 2019/882, the European Accessibility Act