Pagination

The whole row mirrors: page 1 sits at the far right, the last page at the left, and the "next" arrow ends up on the left edge. A flex-direction: row container does this by itself, because the inline axis follows direction. Never add row-reverse under [dir="rtl"]: it double-flips and drops page 1 back on the left. Alignment has a similar trap: justify-content: flex-start is a logical value that follows direction, while justify-content: left is physical and hugs the left edge in both languages.

These two are directional in the literal sense: "previous" must point right in Arabic and "next" must point left, because they point at where the page sits on screen, not at an abstract idea. An SVG knows nothing about bidi, so flip it explicitly with [dir="rtl"] .chevron { transform: scaleX(-1) }. The opposite mistake is worse. Never swap the two buttons in the markup: direction already does the visual flip, and reordering the DOM flips them a second time, putting them back where they started while making Tab reach "next" before "previous".

The digits themselves never mirror, but the neutral character between two of them does: inside an Arabic paragraph the dash in "١٢١–١٤٠" takes the direction of its surroundings and the range renders as "١٤٠–١٢١", so a "showing … of 349" line reads back a reversed count. <bdi> only rescues Latin digits here، rule W7 retypes them as strong inside an LTR isolate، while Arabic-Indic digits are bidi class AN, which isolation does not change, so the range stays flipped; put an LRM (U+200E) on each side of the dash, or unicode-bidi: bidi-override with direction: ltr on the range alone, or write "من ١٢١ إلى ١٤٠" and be rid of the neutral entirely. Pick one numeral system for the whole region, Arabic-Indic ١ ٢ ٣ or Latin 1 2 3, and never mix them as in "صفحة ٣ من 18". The value in the URL always stays Latin: ?page=٣ is not a number to your server and Number("٣") returns NaN, so format the visible label with Intl.NumberFormat("ar-EG") and send the value untouched.

A keydown event hands you a physical key: ArrowRight stays ArrowRight whatever the page direction, and the browser will not mirror it for you. But an Arabic reader expects the right arrow to move to the previous page and the left arrow to the next, the exact opposite of English. WAI-ARIA requires that of every composite widget in RTL. Read the direction off the element with el.matches(":dir(rtl)") or getComputedStyle(el).direction, multiply the step by -1 under rtl, and never wire "next page" straight to ArrowRight in the handler.

The dot row mirrors just like the numbers: the dot for the first slide sits at the right. The layout is fine; the arithmetic is what breaks: in an RTL scroll container scrollLeft starts at 0 at the rightmost position and goes negative as you advance, so Math.round(el.scrollLeft / slideWidth) yields a negative index and lights the wrong dot; the correct form is Math.round(Math.abs(el.scrollLeft) / slideWidth). To move, use slide.scrollIntoView({ inline: "start" }) or scroll-snap-align: start, both logical and direction-aware, unlike a track driven by translateX(-100% * i), whose sign has to be inverted under RTL.