Designing for international conditions: slow connections and more than one language

The GOV.UK Service Manual requires every government service to follow progressive enhancement: the service must work with HTML alone, and CSS and JavaScript are added on top. Health products used across borders meet the same idea in a wider form. Networks are slow, phones are old, and people read in several languages. This guide covers what published guidance says about these, and what it changes on a health screen.

Slow connections and older devices

The Service Manual page on progressive enhancement gives three layers. HTML is the base, and browsers carry on if they meet markup they do not know. CSS comes next. JavaScript comes last, and the page describes it as the layer that does not tolerate faults: one error or unsupported feature can stop a script. So it should improve a working page, not replace it.

The same page lists why a script or style sheet may not arrive: network errors, a corporate firewall, changes made by a mobile network, a browser extension, or an outage at a third party. It names "users with device or connectivity limitations" among the people this protects. The Service Manual's page on browsers and devices adds that a service need not look identical everywhere, but people must be able to use every feature they need.

The pages read do not give a page-size target, so this guide gives none. What they do support is a design habit: build the basic task first, then add the extras. For a health product, that habit points to three plain choices.

• Say that a reading arrived. If a person sends a blood-pressure reading over a weak connection, show a clear message that it was received, or that it is still waiting to send. Silence looks like failure, and people may send it again.
• Keep what people typed. If a form fails, keep the entries and show the problem. The Showcase card The error summary shows one way to report problems on a form.
• Offer a route that does not need the app. A phone number or a printable version covers the case where the screen will not load. The Design for Vulnerable Users article covers non-digital routes in more depth.

A caution: none of the pages read describes offline apps or how much data a screen uses. The choices above are this guide's own reasoning from the progressive enhancement principle. Test them with people on the connections and devices your users really have.

More than one language

WCAG 2.2 has two criteria on language. Success Criterion 3.1.1, at Level A, asks that the main language of each page can be identified by software. Criterion 3.1.2, at Level AA, asks the same for each passage in another language, with exceptions such as proper names and technical terms. W3C's guidance explains the reason. Software can only use the right pronunciation, or offer translation, if the page says which language it is in. In HTML this means a language attribute on the page and on any part in another language.

A health screen often mixes languages. A page in English may carry a drug name, a clinic name or a phrase in another language. Marking those parts lets a screen reader speak them with suitable rules, instead of reading them as English.

Language labels do not translate anything. The words still need care, and the risk is greater with medicines. A 2010 study of pharmacies in the Bronx, New York, looked at computer-generated Spanish labels on medicines. It found that half of the labels it examined contained errors, and most of those were incomplete translations that mixed English and Spanish. It also found that few of the pharmacists who checked the translations reported being fluent in the language. This is one study of one city and one language pair, so treat it as a warning, not a rate. The design lesson is narrow: do not assume machine output for a dose instruction is right. Have a fluent reader check it. Keep the dose wording simple, as the Showcase card Write the dose the patient reads, not the dose the chart stores describes.

For the plain wording underneath every translation, see Health Literacy & Plain Language and the card Write to a reading age.

Right-to-left text

Arabic, Hebrew and several other scripts run right to left. W3C's internationalization guidance says to set the direction in the markup, with a direction attribute on the page, not only in the style sheet, because direction affects meaning. For form fields where the person's language is not known in advance, it suggests letting the browser pick the direction from the first strongly directional character.

The same W3C page advises writing layout rules with start and end in place of left and right. Done that way, CSS can mirror the layout by itself. The page does not say which icons to flip, so that stays a judgement to test. In health screens, one item needs a decision: numbers, units and dose strings mixed into right-to-left text. Check that a dose such as a number with a unit still reads in the right order, and test it with a reader of that language.