# Right-to-Left Website Visual QA Workflow from Figma > Compare RTL website builds against Figma designs to catch mirrored layout, typography, icon, and responsive implementation drift. - Canonical page: https://www.hypermatic.com/articles/pixelay-right-to-left-website-visual-qa-workflow-from-figma/ - Published: 2026-08-14T00:00:00.000Z - Updated: 2026-08-14T00:00:00.000Z A localized page can contain accurate Arabic or Hebrew text and still feel visibly wrong. Navigation order, padding, icons, mixed-direction values, form alignment, and mobile breakpoints may all preserve assumptions from the left-to-right build. That is why right-to-left QA needs more than translation review. It needs a comparison between the approved RTL design and the website running with realistic content. [Pixelay](/pixelay/) can overlay Figma designs on live, staging, local, or private website URLs and provide several comparison modes. It reveals visual differences; language accuracy, semantic direction, keyboard behavior, and assistive-technology support need their own reviewers and tests. ## Define what should mirror—and what should not Before opening the staging site, annotate the intended direction behavior in Figma. Commonly mirrored elements include: - navigation and breadcrumb progression - horizontal layout order - text alignment and directional spacing - forward and back controls - drawers or panels tied to reading flow Elements that may stay unchanged include brand marks, media controls, charts with fixed axes, clocks, phone numbers, code, and some universally understood icons. The correct behavior depends on context; “flip everything” is not a QA specification. Create a short decision log for disputed elements. This prevents design and engineering from repeatedly debating the same arrow or data visualization on each page. ## Prepare comparable states Match the Figma frame and browser viewport exactly enough for visual comparison. Use the same locale, content record, authentication state, consent state, and feature flags. Include realistic stress content: - long navigation labels - a short and long heading - mixed Arabic or Hebrew with Latin product names - dates, prices, percentages, and phone numbers - user-generated content - validation errors and empty states If design uses idealized strings while staging uses different data, an overlay will show noise rather than actionable drift. The general [responsive website QA workflow](/articles/pixelay-responsive-website-qa-from-figma/) explains viewport discipline, while the [localized website QA workflow](/articles/pixelay-localized-website-qa-workflow-from-figma/) covers translated assets and text expansion across locales. This article is narrower: it focuses on bidirectional layout rules, mirroring decisions, mixed-direction strings, and the RTL interaction defects those broader reviews can miss. ## Compare structure before polish Start with low-detail checks: 1. Is the overall page flow mirrored as intended? 2. Do navigation, sidebars, and primary actions begin on the correct side? 3. Are content and controls in the approved order? 4. Do containers align to the correct grid edges? Then inspect component details: logical padding, icon placement, input affordances, list markers, carousel controls, progress indicators, and table columns. Using [Pixelay](/pixelay/) in overlay, split, or difference modes can make one-sided spacing and incorrectly anchored components obvious. Capture the viewport, route, locale, and state with each finding so engineering can reproduce it. ## Test typography as layout behavior RTL typography changes more than alignment. Check the intended font loaded, glyphs are supported, line height fits the script, punctuation sits correctly, and emphasis does not break shaping. Mixed-direction content deserves its own pass. A price such as `USD 1,250`, a version like `v2.4`, or a product name inside an RTL sentence may display in an unexpected order even when the surrounding paragraph is correct. Compare headings, buttons, inputs, helper text, and dense data separately. A global direction rule that fixes paragraphs can still leave tokens, badges, tables, and code-like strings wrong. ## Exercise responsive reflow Check at the approved desktop, tablet, and mobile widths, then test just above and below the breakpoints. RTL defects often appear when a component switches layout mode: - a menu icon stays on the old side - cards stack in an unintended order - an off-canvas panel enters from the wrong edge - a sticky CTA overlaps translated copy - horizontal scrolling begins at the wrong end Do not resize one desktop overlay and call the page responsive. Use dedicated Figma frames or clearly documented expected behavior for each key width. ## Separate visual drift from functional defects Tag findings so they reach the right owner: `visual mismatch` — spacing, type, color, size, or alignment differs from Figma `direction decision` — the implementation and design disagree about mirroring `content defect` — translation, punctuation, or locale formatting is wrong `interaction defect` — focus order, keyboard navigation, scrolling, or controls behave incorrectly `source-design gap` — Figma does not specify the state clearly enough Pixelay is strongest for the first category and useful evidence for the others. It does not replace native-speaker review or browser accessibility testing. For a broader release pass, use the [frontend QA checklist for landing pages](/articles/pixelay-frontend-qa-checklist-for-landing-pages/) after resolving direction-specific issues. ## RTL signoff checklist - Mirrored and non-mirrored elements have explicit decisions. - Figma and staging use the same locale, content, viewport, and product state. - Navigation, component order, spacing, and directional icons match the design. - The intended fonts and glyphs load in the browser. - Mixed-direction names, numbers, dates, prices, and punctuation were reviewed. - Desktop, tablet, mobile, and breakpoint edges were compared. - Findings identify route, viewport, locale, state, and owner. - A native-language reviewer and accessibility tester have covered what visual comparison cannot prove. RTL quality is not a mirrored screenshot. It is a coherent reading and interaction experience. Comparing the real build with an intentional RTL design makes visual drift concrete while leaving the deeper language and behavior checks with the people and tools equipped to verify them.