Web Accessibility for Ecommerce in Thailand: WCAG, Screen Readers, and Why It's Good Business

Accessibility conversations tend to get filed under "compliance for a market we don't sell into" — something relevant to a US or EU store worried about legal exposure, not a Thai ecommerce site. That framing misses most of what accessibility actually delivers. A store that's genuinely usable with a keyboard, readable by a screen reader, and legible in bright sunlight on a cracked phone screen isn't serving some narrow edge case — it's serving Thailand's aging population, shoppers with temporary or situational impairments, and, as a direct side effect, every other visitor too, because most accessibility fixes are just good design decisions that happen to be measurable against a standard.

The standard worth targeting: WCAG 2.2 AA

The Web Content Accessibility Guidelines organise requirements around four principles — content has to be Perceivable, Operable, Understandable, and Robust — with three conformance levels (A, AA, AAA). Level AA is the practical, widely-adopted target: rigorous enough to cover the issues that actually block real users, without chasing the more exhaustive AAA criteria that few production sites — accessible or otherwise — fully meet. Most of what follows maps directly onto specific AA success criteria, but the point isn't passing an audit tool; it's whether an actual shopper using a screen reader, a keyboard, or a small screen in harsh sunlight can complete a purchase.

Color contrast breaks more often than brand guidelines admit

A brand's primary color frequently looks great in a logo and fails a contrast check the moment it's used as text on a light background or as a button label. WCAG AA requires a contrast ratio of at least 4.5:1 for normal text against its background (3:1 for large text) — a threshold that a surprising number of "on-brand" color pairings quietly fail, especially light greys on white, or a saturated accent color used for body copy instead of just accents. This isn't only an accessibility issue: low contrast is measurably harder to read for everyone in bright outdoor light, which describes a large share of mobile browsing in Thailand specifically. Testing actual brand colors against a contrast checker — not eyeballing them on a calibrated office monitor — catches this before it ships.

Keyboard navigation is where most sites quietly fail first

A shopper who can't use a mouse — because of a motor impairment, a broken trackpad, or simply because they're tabbing through a form — needs to be able to reach and operate every interactive element using only a keyboard. This is also where a lot of modern, JavaScript-heavy ecommerce UI breaks first, often without anyone noticing, because nobody on the build or QA team actually tested it that way:

• Every interactive element needs a visible focus state — a mobile menu, filter dropdown, or "quick view" modal that removes the browser's default focus outline for aesthetic reasons, without replacing it with something visible, leaves keyboard users with no way to see where they are on the page.
• Modals and dropdowns need to trap and return focus correctly — focus should move into an opened modal, stay contained inside it while it's open, and return to a sensible place when it closes, not silently jump back to the top of the page.
• The tab order should follow the visual order. A layout built with CSS positioning that visually reorders elements without matching source order creates a tab sequence that jumps around unpredictably.

Screen readers and Thai-language content need their own testing pass

Screen reader support is frequently tested against English content and assumed to carry over to the Thai version, but Thai text has its own quirks that are easy to miss without testing directly: lang="th" needs to be set correctly so the screen reader uses Thai pronunciation rules instead of trying to read Thai text with English phonetics, and product images need real, specific Thai alt text — "รูปสินค้า" (product image) on every single product photo tells a screen reader user nothing useful, where a proper description ("เสื้อยืดสีกรมท่า คอกลม แขนสั้น" — navy crewneck short-sleeve t-shirt) actually does the job alt text exists for. Icon-only buttons (a cart icon, a search icon, a hamburger menu) need an aria-label in Thai as well, not just a visual icon that a sighted user can infer the meaning of.

Forms are where checkout accessibility either works or quietly fails

Checkout is the highest-stakes place on the site for accessibility to break, because it's also the highest-stakes place for a shopper to abandon if it does:

• Every input needs a properly associated <label>, not just placeholder text that disappears the moment the field is focused — placeholder-only labelling is a common pattern that fails screen reader users the moment they start typing and lose the only description of what the field was for.
• Error messages need to be announced, not just shown as red text near the field — a screen reader user who submits a form with a missing required field needs to be told what's wrong and where, not left to guess why nothing happened.
• Required fields need to be marked programmatically (via the required attribute or aria-required), not just visually with an asterisk that a screen reader may not announce at all.

Motion and video need an off switch, and captions

Autoplaying carousels, animated hero sections, and parallax scroll effects can be genuinely disorienting or even physically uncomfortable for users with vestibular disorders — the prefers-reduced-motion media query lets a site respect a user's OS-level setting and tone down or disable non-essential animation for anyone who's turned it on. Video content needs captions for anyone who's deaf, hard of hearing, or simply browsing with the sound off — which, on mobile in Thailand, describes a large share of casual browsing regardless of hearing ability.

The overlap with SEO and conversion isn't a coincidence

Most accessibility fixes and most SEO fundamentals point at the same underlying practice: clean semantic HTML, real alt text instead of empty or generic strings, a logical heading structure, and forms that are actually machine-readable, not just visually styled to look like a form. A site built accessibly tends to be a site Google can parse cleanly too, and a site that's genuinely usable for a shopper on a low-end phone in bright sunlight, with shaky wifi, one-handed — the actual majority use case in Thai ecommerce — converts better than one that only works in ideal conditions on a flagship phone on an office desk.

A practical audit order

1. Run an automated accessibility scanner (axe or similar) across the main templates — homepage, category, product, cart, checkout — as a fast first pass, understanding it catches maybe a third of real issues and misses the rest.
2. Tab through the entire checkout flow with a keyboard only, no mouse, and note every point where focus disappears or gets stuck.
3. Run the homepage and a product page through a screen reader (VoiceOver on iOS, TalkBack on Android, NVDA on Windows) with Thai content, not just English test copy.
4. Check contrast on the actual brand color palette as used in real buttons and text, not just the logo.
5. Confirm forms announce errors and associate labels correctly, especially on checkout and the contact/enquiry form.

None of this requires rebuilding the site from scratch. Most of it is small, specific fixes layered onto an existing design system — and the audience it opens up, and the conversion lift that tends to come with it, extends well past the shoppers using assistive technology directly.