Define what the switch promises
A visitor reading a maintenance guide usually expects the language control to open that guide in another language. Write that expectation into the component specification before choosing its appearance. Record whether the control changes the current resource, the site preference or both. A label that only says Arabic should not silently send every visitor to an unrelated homepage.
Build a mapping with a stable content identifier and the published address of each edition. Resolve the destination from that mapping instead of replacing en with ar in a string. Different slugs, publication dates and missing translations make mechanical path replacement unreliable. Confirm the destination exists and answers the same question before adding it to the switch.
Make navigation an explicit action
Use clearly named language choices, such as English and العربية, and indicate the current selection. For two editions, ordinary links make the destination inspectable. Google recommends links between language versions and cautions against automatic language-based redirection that prevents visitors and crawlers from accessing other versions. A remembered preference should not trap someone in the wrong edition.
For a select control, provide an explicit action button or explain automatic navigation before the control is used. W3C’s On Input guidance addresses unexpected context changes caused by changing a control’s value; activating a link is a different interaction. Test the actual behavior rather than assuming that a dropdown or a button is accessible because of its visual appearance.
Specify missing translations and page state
When no equivalent edition is published, do not fabricate its address. Explain that this page is unavailable in the requested language and offer a clearly labelled route to that language’s resource library if useful. Keep that fallback distinct from a claim that the current article has been translated. The publishing workflow should remove unavailable destinations from the mapping.
Decide separately what happens to a section anchor, a search filter or an unfinished form. Preserve an anchor only if the matching section exists in the destination. Do not copy sensitive form values into a URL to carry them across languages. For a form with unsaved work, define a warning or a safe preservation mechanism with the application team and test it explicitly.
Illustrative example: a guide with different slugs
Imagine an English guide at example.com/en/maintenance-checklist/ and its Arabic counterpart at example.com/ar/site-care/. The fictional content record guide-17 maps both addresses. Selecting العربية from the English guide opens the Arabic guide, and choosing English returns to the English one. The destination headline confirms the same subject instead of merely displaying a translated navigation bar.
Suppose the English guide contains an emergency-contact anchor but the Arabic edition has no corresponding section. The implementation sends the reader to the beginning of the Arabic guide, following the documented anchor policy, rather than an invalid fragment. If the Arabic guide is withdrawn, the control shows an honest availability message. These are proposed test cases, not results from a customer site.
Check the whole journey before release
Create a small test matrix covering both directions, a missing counterpart, a renamed slug and a URL with an anchor. For every row, record the initial address, activated choice, final address, visible language and whether the expected resource survived. Repeat using the keyboard and on a narrow screen; inspect the accessible name, visible focus and reading order.
Also test a direct visit to each language URL with a different browser-language preference. Confirm that automatic behavior does not immediately undo the visitor’s choice. A successful switch test does not prove indexing or full accessibility conformance. Keep navigation evidence in the release checklist, while reviewing canonical and hreflang annotations as separate technical checks.