Do be careful to define a base (natural) language on all web pages. Otherwise, defining other languages can result in the entire page being read by a screen reader trying to use the pronunciation rules for the wrong language.
This can happen where the HTML tag isn’t given a LANG attribute, for instance:
<httml lang="en">
The problem arises if there is any coded “change” to the natural language on the page, because the “change” is, in fact, the first time that a language is defined. So everything after it may be pronounced as if it is in the “foreign” language.
Screen readers have a library of pronunciation rules, and if the “foreign” language is in the library, then any text after a LANG attribute will be pronounced using the correct rules for that language.
On a properly coded page, with a defined natural language, this applies only for the element to which the LANG is applied. At the end of that element, the natural language pronunciation rules are reapplied.
But where no natural language is defined, when the content on the page goes back to the natural language, the screen reader has no natural language to revert to, and so it may carry on using the current rules for pronunciation.
Ever heard English pronounced as though it were Portuguese?
Believe me, no-one from either England or Portugal will understand it.
JackP | 01/08/2007 at 16:33 | Permalink
I’ve been involved in some debates (well, okay, arguments) about language attributes…
I accept that failing to mark up a change in language isn’t as good as marking up a change in language, because things will be pronounced incorrectly.
My contention however is that this - depending on the context and so on - doesn’t necessarily mean that it makes the text is then impossible to access, although it will make it more difficult.
For example, the phrase “Arnie said ‘hasta la vista, baby’” should have a change in language marked up. Yet unless you understand the language, it makes little difference whether it’s pronounced correctly or not…
In my case, not understanding the language doesn’t prevent me from understanding the phrase: that’s what Arnie said. Although I don’t know what he meant, admittedly…
At least, that’s my theory: that not marking up language won’t necessarily make something impossible to access (as would be suggested by it being WCAG Priority 1): although I’d accept that it will certainly do that in some cases.
I’d be interested to know what you think…
For what it’s worth however, I tend to mark up language changes with the lang attribute of the i element: that way things pronouncing the phrase get a change in tone/pronounciation style, and those looking at it visually also get a visual cue that the word isn’t a plain english word per se.
I’d be interested to know what you think of this technique too, as I’m happy to revise it if appropriate.
Bim | 01/08/2007 at 17:53 | Permalink
Good point Jack, especially if a phrase is in common use in a different language. The importing language may well change the pronunciation, so if it were spoken as though by a native of the phrase language, it might be less familiar than if it were mispronounced .
This is, I think, covered in WCAG 2.0 3.1.2 where it gives the exceptions to the need for markup, "Note: This requirement does not apply to individual words. It also does not apply to proper names, to technical terms or to phrases that have become part of the language of the context in which they are used."
So now all we need to do is agree which phrases have become part of each language. :) Don’t think the discussion will stop yet.
Ben 'Cerbera' Millar | 01/08/2007 at 18:12 | Permalink
Gah, getting more “Connect was reset” errors when trying to reply to this article. :-(
Bim | 01/08/2007 at 18:22 | Permalink
Erk, did you use any bad language? :) What I mean is did you use anything other than alpha numeric or standard punctuation ? If you’d like to e-mail me with the message I’ll see if there’s any reason within the message, and send back suggestions. My e-mail address is bim.egan@rnib.org.uk;
Adrian Higginbotham | 02/08/2007 at 11:51 | Permalink
and of course specifying the correct language in the first place is rather important,
see my recent postre exactly this problem.Bim | 03/08/2007 at 9:10 | Permalink
Good post Adrian, and the point’s well made. If the page is coded as having the wrong natural language from the start, screen readers will mispronounce everything. It’s good that JAWS has an “ignore languages” setting, but I wonder if all of the screen readers have one.
Bim | 03/08/2007 at 9:24 | Permalink
Jack,, sorry, I didn’t comment on your technique about applying the LANG attribute to the <i> element. Neat idea. giving a visual clue that the language is different. It might not be ideal for entire paragraphs, people with dyslexia find italics more difficult to read, but it’s a great idea for short phrases.
I didn’t notice any difference in the audible output tone though. I don’t know of any emphasis elements that do change screen reader tone, does anyone else?
JackP | 03/08/2007 at 15:59 | Permalink
Bim, I deliberately used i rather than em, because I wasn’t seeking to add emphasis: I was presuming that there would - for example - be an audible cue because of a change in accent or tone that c’est la vie was in french, and therefore I used i only to attempt to give an equivalent visual cue.
If I was attempting to add emphasis, then I would have used c’est la vie like so!
Hopefully, the screenreader will have pronounced both of them in french, but have added emphasis to the second…
JackP | 03/08/2007 at 16:01 | Permalink
Hmm. It obviously doesn’t work here: looking at the source, it appears that while the italic and emphasis elements have been retained, it has actually removed the language attributes inside ‘em both.
Bim - you couldn’t try knocking up a quick test of that could you, and let me know how it sounds?
Bim | 03/08/2007 at 18:45 | Permalink
Ok Jack, here’s the test, first we have the French language attribute applied to the <em> tag,c’est la vie. Then we do the same thing using the <i> tag, c’est la vie. This was originally done on a test page that was checked as valid XHTML Transitional, so if wordPress makes the attributes disappear, at least I know it’s not due to faulty code.
The audible output of both seems to be identical, which is what I would expect, I haven’t ever heard any tone changes due to using any specific element.
However, there are plenty of more experienced JAWS users out there than I am, Adrian, for example, perhaps one of you could answer the question: does JAWS give any tone indication that a piece of text has been given emphasis either by use of the <em> element or the <strong> element??
Ben 'Cerbera' Millar | 04/08/2007 at 5:13 | Permalink
I’ve written Absent
langon Root Element to get around the problem I was having. The code for that entry is what I was trying to use here earlier, except I wasn’t including<p>.(Commenting on my comment should happen here, since this is where the discussion is taking place.)
The comments here allow some HTML. But if you use an element which isn’t allowed, some sort of Out of Cheese Error occurs on the server which results in a Connection was reset for the client. Commenting systems are difficult, so please don’t take my niggle reports as criticisms. :)
Ben 'Cerbera' Millar | 05/08/2007 at 21:55 | Permalink
I’ve commented on this in Absent lang on Root Element. Basically: I’m pretty sure the screen reader is wrong and
<i>is a sensible choice.Responses on my comment should go here, since this is where the discussion is taking place.