Bad language

On this page:

Post details

By bim. 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.


Comments (7)

Tag: Hidden barriers

Posted at: 1/08/2007 12:53 PM by Verity Cork

Comments

language attributes

JackP said:

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.

Posted at: 12/4/2010 7:43 PM by Verity Cork

Good point Jack

Bim said:

This is especially true 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.

Posted at: 12/4/2010 7:47 PM by Verity Cork

Correct language

Adrian Higginbotham said:
and of course specifying the correct language in the first place is rather important, see my recent post re exactly this problem.

Posted at: 12/4/2010 7:56 PM by Verity Cork

JAWS setting

Bim said:
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

Posted at: 12/4/2010 8:00 PM by Verity Cork

LANG attribute

Bim said:

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?

Posted at: 12/4/2010 8:04 PM by Verity Cork

Audible cues

JackP said:

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...

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?

Posted at: 12/4/2010 8:14 PM by Verity Cork

Tone indication?

Bim said:

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?

Posted at: 12/4/2010 8:23 PM by Verity Cork

Add a comment

If you would like to add a comment, you need to login first.
Back to top

Other Blogs

Links