Inclusive Tech – Page 4 – Advice and opinions on creating apps, websites and user interfaces for all users

The internet is not only used by sighted people, and it’s important to remember that blind and partially sighted people may be visiting your website. You’ll want to make sure the information on your site is accessible as possible. One way to accomplish this is to make sure your website is usable with screen-reader software. Screen readers are applications installed on computers and mobile devices that read text on websites, dialogue boxes and application windows out to their readers. Some common screen-reading programs include JAWS (Windows), VoiceOver (Mac/iOS), NVDA (Windows) or Festival (Linux).

There are several ways you can make your website usable by people who use screen readers:

Using alternative text in your HTML code – you can insert a description for your image using the ‘alt’ property in HTML. For example, if you have a photo of a woman holding a dog, you could insert a description saying ‘Woman holding a brown dog’, which will be read by the screen reader. If your image is just a decorative element, like a divider, use the alt text code, but use a blank space so the screen reader doesn’t just give the user the file name. Remember to keep your descriptions simple and basic – offer the information you need, but don’t make the descriptions so lengthy and complicated that it distracts your readers from the content on the website itself. (Note: If your site is based on WordPress, recent versions (3.9.2 as of writing) allow you to add an image description when you’re uploading an image using the media uploader.)
Avoid building your site entirely in Flash. You can insert Flash videos, but keep your text in plain HTML. Flash is more difficult for screen readers to recognise. This is luckily a dying trend, but there are still some sites out there that tend to use large amounts of Flash.
JQuery and AJAX effects can be visually appealing to sighted users, but can be a barrier to blind and partially sighted/visually impaired users. Tumblr used to be accessible with screen readers, but since the site has introduced more advanced effects, it’s become more difficult for people using screen readers to use. Do you really need another animated slide-in window or pop-up input window?

You may also want to read ‘The blind community’s fight for a more accessible web‘ at The Daily Dot.

Language selector with flags. Spanish and Chinese are labelled in English.

Internationalisation, Localisation

Avoid using flags to designate languages

28 August 201431 December 2017 fg

Web designers use flags as a convenient shorthand to stand for languages on multilingual websites. For example, a site available in French, English, Spanish and Japanese might show a French flag, a Union Jack (or an American flag), a Spanish flag and a Japanese flag. Unfortunately there are a lot of problems that the use of flags in language selectors invites, especially for languages that are used by several countries, like German, Spanish, English, French and Chinese.

There are lots of people who may be offended – or at the very least, perturbed – by an American flag to represent English: Canadians, British people, Australians and New Zealanders for example (and you may also offend Americans who recognise their dialect doesn’t represent the totality of the English-speaking world). A Union Jack for English may offend or confuse non-British, but English-speaking, users like Americans, South Africans, Canadians and Irish people. If you want to mark a specific dialect of a language, write something like Português do Brasil or Português brasileiro rather than using a Brazilian flag. And sometimes the flag doesn’t even match the dialect being used; examples include websites that have an English option that’s marked with the Union Jack, but the site itself is full of American spellings (or vice versa, where the American flag is used, but the English variant used is a Commonwealth version), or even worse, Brazilian Portuguese websites that use the flag of Portugal (which can confuse European or African Portuguese-speakers visiting the site and expecting European Portuguese).

Not to mention there are some countries that have multiple languages: India, China, Belgium, Nigeria, South Africa, Switzerland and Canada, for example. What language would you choose if you used an Indian flag? It could represent Hindi, Gujarati, Punjabi, English or Kannada, amongst others.

Bad:

Deutsch – German is also spoken in Switzerland, Austria and Belgium.
English – English is spoken in multiple countries, not just the UK. The Union Jack is preferable to the American flag, since English did originate in one of the UK’s constituent countries, not the US. But it’s still not a good choice.
English – Using an American flag can be annoying or offensive to British, Canadian, Australian and other non-American speakers. English did not originate in the US.
English – Using the flag of England may be confusing if you don’t recognise it.
Español – Using a Spanish flag may be confusing if you’re using a Latin American Spanish dialect. Also, Castilian Spanish is one of many languages spoken in Spain; others include Basque, Catalan and Galician.
Español – Spanish is spoken elsewhere, and Spanish did not originate in Mexico. Using a Mexican flag to represent Latin American Spanish is wrong. There are many other Spanish-speaking countries in Latin America, including Guatemala, Argentina, Honduras, El Salvador and Colombia.
Português – Using a Portuguese flag can confuse or annoy Brazilian users if you’re using Brazilian Portuguese despite using the Portuguese flag. If the flag of Portugal is used to label Brazilian Portuguese, it may also mislead users who may be expecting European or African Portuguese because of the flag.
Português – Potentially misleading or offensive to users from Portugal, Cape Verde or other countries that speak Portuguese. Portuguese did not originate in Brazil.

There are a few cases when there’s a one-to-one correspondence between language and the country associated with it, like Japanese, Turkish and Danish. But with large pluricentric languages like Chinese, English, Portuguese, French, Spanish and German, it’s not a good idea to have languages indicated with flags.

Countries like South Africa, India and China have large numbers of official or common languages. What language would a South African, Indian or Chinese flag represent? China alone contains nearly 300 languages. India has sixteen recognised languages. South Africa has eleven official languages. Not to mention that Mandarin Chinese is a pluricentric language that’s spoken outside Mainland China, as is Cantonese.

Examples of what not to do seen in the wild:

Panic.com blog: English is labelled with an American flag on the blog page, and Japanese is labelled with a Japanese flag – and with its own name in kanji and an English translation. These flags are redundant.

I like Panic. I use their Coda product regularly. But it’s a shame to see them resorting to this frustrating trope, especially with the American flag used for English. Just label the languages without the flags – the names are already there. The flag is admittedly less of a problem for Japanese than it is for English, but I stand by the principle that is never a good idea to label languages with flags.

This French lyrics site offers an English translation, which is indicated with a Union Jack. The word ‘English’ would be better and more recognisable – people visiting the site from the US, Canada or other countries may think the Union Jack button without an accompanying ‘English’ label means they’re being taken to a UK-centric site.

At oldapps.com, flags are used for languages. An American flag is used for English – again, English did not originate in the US. They didn’t use a Mexican flag for Spanish, did they? Even worse, Chinese and Spanish are labelled in English instead of in their own languages, though German says ‘Deutsch’ as it should. It’s not even consistent. I can say that this is the worst language selector I’ve ever seen.

Don’t use flags for languages.

Here’s what you can do instead:
Languages

Deutsch (Deutschland)
Deutsch (Österreich)
Deutsch (Schweiz)
English (UK)
English (US)
English (Canada)
Español (España)
Español (Latinoamérica)
Français (France)
Français (Belgique)
Français (Canada)
Português (Brasil)
Português (Portugal)

Countries

Click for UK orders
Click for US orders

If you’d like to read a blog dedicated to the criticism of flags to indicate languages, you can visit Flags are not languages – an excellent resource for anyone developing multilingual websites.

Screenshot of the German-language version of Microsoft Exchange. 'Status' is mistranslated as 'State' or 'Bundesland'.

Internationalisation, Localisation

Provide accurate translations

27 August 201421 October 2014 fg

If you want to translate your software into other languages (or foreign dialects of the same language), please be sure your translations are accurate – otherwise your users might be confused, irritated or even offended. This should be self-explanatory advice, but for some developers – including large multi-national companies like Microsoft, Apple and Yahoo – it’s not.

Image from here

In the German translation of Microsoft Exchange 2007, a particularly ridiculous error turned up in the user interface – ‘state’ (as in ‘status’) was translated as Bundesland or ‘federal state’. This is like a piece of English-language software asking for the ‘province’ of an internet connection. According to the website I found this image from, Microsoft may have been using an automatic translator from English to German, which is fraught with pitfalls. Don’t use automatic translation without having a fluent speaker read the translation to see if it’s accurate. Computerised translations can often be wrong, and your user base will let you know it. It takes longer, but it’s worth it. The example is from Microsoft, a billion-dollar company – surely they, of all people, have the resources to create an accurate German translation?

A lot of people end up using English-language software even though they’re not fluent English-speakers or readers, simply because the translations into their native language are that bad. If you plan on marketing outside your home country and have the resources, make the effort to provide good translations. Not perfunctory machine translations that haven’t been reviewed by native speakers or reasonably fluent second-language learners – good translations. It’s absolutely inexcusable that a billion-dollar company like Microsoft couldn’t proofread their software well enough to avoid asking their German-speaking users about the ‘federal state’ of a connection.

Internationalisation, Localisation

Use flexible date and time formats and avoid confusing users

27 August 201416 September 2015 fg

(updated 16 Sep 2015 – information about LinkedIn and date formatting issues)

Some developers will hard-code the date and time format in their software. Sometimes this only applies to their English-language interfaces, but sometimes it extends further, which is even more thoughtless. Many American and anglophone Canadian developers tend to impose the ‘Month/Day/Year’ date format on everyone, regardless of what is popular elsewhere. Do not hard-code date and time formats. Either let the user choose it (like Wikipedia) or detect it from the user’s computer settings (like Github).

There are three date formats, listed in approximate order of popularity:

Day/month/year – Long form: 21(st) January 2015 Short form: 21.01.2015 (most popular in Europe, Central America, non-English-speaking North America, South America, Africa and Western Asia, and used in a military context in the USA). Please note that commas are not used in this date format.
Year/month/day – Long form: 2015 January 21 Short form: 2015-01-21 (the ISO standard, most popular in East Asia, also used as a standard date format when sorting dates in computing)
Month/day/year – Long form: January 21(st), 2015 Short form: 01/21/2015 (popular in anglophone North America, particularly the USA; you may see the month/day/year format written in long form by other English-speakers, but not the confusing short form)

Of these three date formats, Day/Month/Year is the most popular. If you asked North American software developers, you’d think it would be Month/Day/Year, even though this date format is only used on a widespread basis in the USA, by some people in English-speaking Canada and Belize.

The Month/Day/Year format can be confusing when written in short form, especially with a date like 03/04/2014 – are you referring to 3 April, or 4 March?

Avoid using numerical dates, where most date-format confusions happen. 10/09/2004 can be 10 September 2004 or 9 October 2004. Write the month name out or abbreviate it using words, not numbers. ‘10 Sep 2004’ and ‘Sep 10 2004’ are unambiguous, unlike 10/09/04 and 09/10/04. You’ll also want to write the year out to avoid confusion. Christopher Heng has an excellent article about avoiding numerical dates on The Site Wizard if you’d like to read more.

Dropbox, a popular cloud-storage provider based in San Francisco, had a hard-coded Month/Day/Year date format (written numerically, to add to the confusion) on the English-language version until the end of 2013, after years of complaints from their international user base. Evernote and Firefox OS are currently the subject of similar complaints. There is a two-year-old thread from Dell users complaining about one of their products having a hard-coded M/D/Y date format if their language is set to English. It should not take five years for a website with an international user base to support date formats understandable by a wide variety of people. People on LinkedIn have been complaining about a default, unchangeable US date format (written numerically on certain parts of the site) for the last two years, with no change in sight. If I am able to change the date format from M/D/Y to D/M/Y on a cheap mobile phone, then I should be able to do it with a smartphone UI or a web app.

What not to do: Apple’s support website shows numerical Month/Day/Year dates for updates, even if you have a region chosen that should change the way dates appear. The first three dates could be ambiguous, especially at the end of the year. I tried this list of updates with both the US and UK localisations of the Apple sites and the date formats didn’t change.

Date separators can also use different punctuation – in English-speaking countries, there are a variety of different date separators, depending on region (the commonest are the slash/stroke and the full stop/period), but in German-speaking countries, people use the full stop.

Give the option for 24-hour time (0:00 to 23:59) and 12-hour time (12:00am to 11:59pm). Most non-English-speaking countries don’t use 12-hour time, and there are many English-speakers who prefer 24-hour time in user interfaces (it’s the standard in UK English regional settings on OS X, Windows and iOS).

Examples of date format flexibility: Windows allows the user to choose any date order they like, even when using English (US) as their region format.

Examples of date format inflexibility: English-language OS X and iOS will only allow you to put the day in front of the month if you’re using a region format other than US or Canada. I ended up changing my region format to UK to get my preferred date order – I hate month/day/year.

Some flexibility, but room for improvement: Trello will detect 12-hour and 24-hour time formats, and will understand different inputted date formats, but the text still shows Month/Day/Year date formats. They’re not numeric, but some users may want to have the dates to be displayed as ’12 October 2015′ instead of ‘October 12, 2015’. (Update, 16 May 2015: Trello now detects both date and time format; the day is now in front for me, which is in line with my date settings on OS X.)

Here is a good example of what to do from Wikipedia – there are no numerical dates except for year-month-day, which is unambiguous, and you have the choice between Day Month Year, Year Month Day and Month Day Year.

Addition, 11 April 2015:

I’m convinced that the US ‘Month/Day/Year’ date format should be avoided in sites that will be used outside the US – and especially websites that will be translated into other languages. People including date formatting in scripts should make the default English format the ISO standard (Year/Month/Day), making regional preferences like MDY and DMY opt-in by specifying a language and dialect. I’ve seen too many websites where the American date format lurks as an artefact, even on localisations for other languages like French and German.