Accessibility Policy

Yanolja Cloud Solution is committed to making yanoljacloud.com usable by as many people as possible, including people who browse with a screen reader, navigate by keyboard alone, use screen magnification, need reduced motion, or rely on high-contrast or enlarged text.

Accessibility is treated as a build requirement on this site, not a retrofit. Every page template and content block is checked against our internal accessibility rules before it ships, and an automated accessibility score of 100 in Google Lighthouse is part of the release criteria for the site alongside performance and SEO.

We design and develop this website to meet Web Content Accessibility Guidelines (WCAG) 2.2, Level AA.

We consider the site partially conformant with WCAG 2.2 Level AA. "Partially conformant" means most of the site meets the standard, but some content — noted in Known limitations below — does not yet fully conform. We have not yet commissioned an independent third-party audit or published a VPAT; when we do, we will link the report from this page.

Structure and semantics

• Every page is built from real HTML landmarks — a single <main> region, a consistent site header and footer, and properly nested headings from <h1> down, so screen-reader users can jump between sections instead of reading linearly.

• Headings are never chosen for their size. Our shared heading component only renders <h1>–<h6>, and visual size is applied separately, so the document outline always reflects the real structure.

• Data tables use column headers (<th scope="col">), and images with an editorial caption are marked up as <figure> / <figcaption>.

• Breadcrumbs and a full HTML sitemap give more than one way to reach any page.

Images and icons

• Every content image carries alternative text supplied by the content team in the CMS.

• Purely decorative images, background graphics, icons and animated illustrations are marked as decorative (empty alt and hidden from assistive technology) so screen readers are not made to announce visual noise.

• Where a visual element duplicates text that is already on screen — for example a scrolling logo strip — the duplicate is removed from the accessibility tree so it is not read out twice.

Keyboard navigation

• All interactive elements — navigation, mega menus, mobile menu, search, filters, dropdowns, tabs, accordions, carousels, forms and video controls — can be operated with a keyboard alone.

• Esc closes the search bar, the language switcher, the mega menu and the mobile menu; in the mobile menu it steps back one level at a time rather than dumping you out of the whole navigation.

• When a panel or dialog closes, focus returns to the control that opened it.

• Content that is visually hidden — a closed menu, an off-screen mobile pane, the header behind an open search bar — is made programmatically inert, so keyboard users never tab into something they cannot see.

• Focus is always visible. Links, buttons and cards show a clear focus ring or outline when reached by keyboard.

Forms

• Every field has a visible, programmatically associated label. We do not rely on placeholder text as a label.

• Errors are announced, not just coloured: invalid fields are flagged with aria-invalid, the error message is linked to the field it belongs to, and it is announced immediately to screen-reader users.

• Success and status messages after submitting a form are announced in a live region.

• Results that update in place — search results, filtered listings, pagination — announce their new state politely rather than changing silently.

Motion and animation

• The site respects your operating system's "reduce motion" setting. When it is on, scrolling marquees, orbiting graphics, progress rails, parallax and reveal animations stop; carousels stop auto-advancing; and smooth scrolling is replaced by an instant jump.

• Animation is never the only way information is conveyed — anything an animation reveals is also present as static content.

• Any automatically moving content can be paused or stops on interaction, and no content flashes more than three times per second.

Video

• Background and hero videos play muted and expose a control to turn sound on or off.

• Videos opened in the player use native browser controls (play, pause, seek, volume, fullscreen), so they work with your own assistive technology, and the player is labelled and closable with Esc.

Text, colour and zoom

• Body text, headings and UI text use relative units, so they scale with your browser's text-size settings.

• Layouts are fluid rather than fixed-width, and are tested at 100%, 125% and 150% browser zoom / display scaling without loss of content or functionality.

• Colour combinations are drawn from a single design system and checked for contrast; colour is never the only means of conveying meaning.

• In-page anchor links account for the fixed header, so a heading you jump to is never hidden underneath it.

Language

• The site is published in English, Thai and Spanish, and each page declares its language and text direction in the markup, so screen readers use the correct pronunciation and voice.

We build to web standards rather than to a single tool, and we test the site in current versions of Chrome, Edge, Safari and Firefox on desktop, iOS and Android, including with the built-in screen readers on those platforms (VoiceOver, TalkBack) and with keyboard-only navigation.

If you use an older browser or a less common assistive technology, some features may behave differently. Please tell us — real-world reports from people using this site are the most useful input we get.