Web
Corporate sites and platforms, in English and Arabic.
Built for speed, accessibility and search, with right-to-left treated as a layout problem rather than a translation problem. You are reading the working example.
Bilingual
Right-to-left is a layout problem, not a translation problem.
Most bilingual sites are an English site with the text swapped and a stylesheet flipped, and it shows within about ten seconds. Doing it properly means these decisions, made in the design system rather than patched on at the end.
The layout mirrors, the brand does not
Spacing, alignment and grid order all reverse because they are written with logical properties rather than left and right. The logo never mirrors, and neither do external-link marks, code, email addresses or URLs.
Arabic gets its own metrics
Its own line height, its own optical size, and tracking held at zero, because negative letter-spacing breaks a connected script. No uppercase, because Arabic has no case. No italic, because it has no italic form.
Two families, loaded separately
A Latin face and an Arabic face, self-hosted, with the Arabic family not preloaded on English pages. An English reader should not pay for a font they will never see rendered.
Directional elements flip, deliberately
Arrows, breadcrumb separators, back links, carousel controls, progress indicators and numbered connectors. Each one is on an explicit list, because the ones that get missed are always the small ones.
Mixed content stays readable
Latin strings inside Arabic prose are isolated so the bidirectional algorithm cannot scramble them. Anyone who has seen an email address rearrange itself mid-sentence knows why this has to be handled rather than hoped for.
Arabic is written, not translated
Copy composed for an Arabic reader, with its own sentence rhythm. A page translated clause by clause from English reads like one, and the audience notices immediately even when they cannot say why.
Every item above is running on this page. Switch the language in the header and check.
Scope
What the work covers.
Most engagements are one of these with part of another.
Corporate sites
Multi-language, multi-stakeholder sites with a content model that survives a second year of edits by people who were not in the original workshop.
Web platforms
Content, search and personalisation engineered as one system rather than assembled from plugins that each solve a tenth of the problem and fight each other over the rest.
E-commerce
Catalogue, checkout and fulfilment integration, with the payment methods and tax rules of the market the store actually sells into rather than the one the platform was built for.
Frontend engineering
Design systems and component libraries that hold their shape across both reading directions, every breakpoint and every state, including the ones nobody drew.
Migration
Moving off a platform without losing rankings: URL mapping, redirects in one hop, structured data carried across, and a plan for what happens to the pages nobody remembers publishing.
Maintenance
Dependency upgrades, security patches, content model changes and the performance work that keeps a fast site fast after two years of additions.
Performance
A budget with a number, enforced in the build.
Sites do not become slow through one bad decision. They get there through a sequence of small additions, each one approved by somebody who did not have a number to measure it against. So we set the number first.
The budget comes before the design
A weight and a timing target per page type, agreed early. A design that cannot be built inside it is a design problem, and it is much cheaper to find that out at the wireframe stage.
It is enforced where changes happen
Checked in the build rather than measured after launch. A pull request that pushes the page over its budget fails, which turns performance into a conversation at the right moment.
The usual suspects get named
Fonts, images, third-party scripts and unnecessary client-side JavaScript. In that order, most of the time. A tag manager quietly loading six vendors is the single most common cause.
Measured on real devices
On the hardware and the connections the actual audience uses, not on a developer laptop on office fibre. The gap between those two is where most performance reports go wrong.
Rendered on the server by default
Pages ship as HTML that reads and indexes without JavaScript, with interactivity added only where something genuinely has to be interactive.
Accessibility
Usable by people who do not use it the way you do.
Built to WCAG 2.2 AA as a working target rather than an audit at the end, because retrofitting accessibility means rebuilding the components you already shipped.
Keyboard first
Every control reachable and operable without a pointer, in an order that matches the visual one, with nothing that traps focus.
Focus you can see
A visible focus style on every interactive element, tested against the dark palette rather than assumed from a light-mode default.
Contrast that holds
Checked on the actual background each element sits on. A dark palette makes this harder, not easier, and mid-grey text on near-black is where it usually fails.
Motion that can be turned off
Reduced-motion preferences respected throughout, with content fully readable when nothing animates. Animation is an enhancement, never the thing that reveals the text.
Forms that explain themselves
Real labels, errors described in words rather than signalled by colour alone, and messages associated with the field they belong to.
Semantics before ARIA
Native elements wherever one exists. A button is a button. ARIA is for the cases the platform genuinely does not cover, not a layer over the ones it does.
Delivery
How a project runs.
Content readiness is almost always the critical path, so it starts in the first phase rather than the last.
Architecture
Sitemap, URL structure, the content model and the language strategy. Decided before anything is designed, because these are the parts that are expensive to change later.
Design system
Type, colour, spacing and components, built and reviewed in both reading directions from the start rather than checked for Arabic at the end.
Build
Pages assembled from the system, against the performance and accessibility budgets, with both languages developed together.
Content and migration
Copy in both languages, redirects mapped in one hop, structured data and metadata carried across from whatever is being replaced.
Operate
Monitoring, dependency upgrades, search console follow-up after launch, and the performance work that keeps the budget honest as content grows.
Questions
The ones worth asking first.
Will it really work properly in Arabic?
You can check that yourself rather than taking our word for it. Switch the language in the header and look at what moves: the navigation order, the arrows, the breadcrumb separator, the alignment, the line height, the font. Then look at what deliberately does not move: the logo, the email address, any Latin product name. That is the standard, and it is running on the page you are on.
Do you use a CMS?
Usually, and which one matters less than the content model behind it. A good model with a mediocre CMS survives; a bad model breaks whatever you put on top of it by the second round of edits. We design the model against who actually edits what, then pick a system that fits it and your team.
Can you work to our brand guidelines?
Yes, and if the guidelines do not cover Arabic yet we will tell you which decisions are missing rather than inventing them quietly. Type scale, tracking, line height and the minimum sizes for the Arabic face usually are not in a guideline written for Latin.
How long does a corporate site take?
The build is rarely what sets the date. Content and approvals are, especially in two languages where every page needs a reviewer per language. We plan around that and say so at the start, because a schedule that assumes content arrives on time is a schedule that slips.
What about SEO?
Structure, metadata, hreflang, canonicals, performance and clean URL architecture are part of the build rather than a phase after it. What we do not do is buy links or publish thin pages to fill a keyword list, both of which cost more than they return.
What happens to our existing URLs?
They get mapped before anything launches. Every address that has traffic or links either keeps working or redirects in a single hop to the closest real equivalent, and nothing is deleted quietly. Losing rankings in a redesign is avoidable and usually caused by skipping exactly this step.
Tell us what you are trying to build.
Describe the audience and the languages it reads in. If the honest answer is that your current site mostly needs content work rather than a rebuild, you will hear that on the call.
info@eorbitt.com · We reply within one business day.