Re: Web Browser Preferences and Internationalisation/Accessibility

On Wed, 18 Nov 2009 15:56:16 -0800, Maciej Stachowiak wrote:
> On Nov 18, 2009, at 3:39 PM, Silvia Pfeiffer wrote:

>> All modern Web browsers have user preferences and as part of these,
>> you can choose your preferred languages for displaying Web pages.

In Mac OS X, the "browserLanguage" of Webkit browsers is set by the 
language choice made in the International preference panel [or "Country 
settings" as it so much better is called in the German localization] of 
Mac OS X. The actual localization of your webkit browser doesn't 
matter. Gecko based mac browser Camino and Opera for Mac behave the 
same way. 

The way to get these browsers to report another 
browserlanguage/navigator.language than that of the browser 
localization itself, is to select as your most preferred system 
language one language that the browser isn't localized for. This will 
also simultaneously change the HTTP accept-language headers that the 
browser sends out. For some reasons the Webkit developers hasn't found 
reason to include this cascade in the accept headers that Webkit sends 
out - Webkit browsers on Mac only reports one accept-language (despite 
that the system itself can define a cascade of language preferences).

navigator.language of Firefox = localization of Firefox itself. Firefox 
and Webkit based iCab can be set to prefer Web content in a language - 
or even languages - that are different from that of the language choice 
made in the International control panel. 

>> To detect language preferences in browsers other than IE, you have to
>> analyse the HTTP Request header of the browser, which typically
>> includes something like:
>>  User-Agent:  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
>> rv:1.9.3a1pre) Gecko/20091115 Minefield/3.7a1pre
> 
> Besides HTTP headers, the user-agent string is also available to 
> JavaScript as navigator.userAgent.

For Mac OS X browsers, then, one can be relatively certain that the 
user-agent string, the navigator.language and the HTTP accept header 
say the same thing. It sounded from Maciej that this is also the case 
for Safari on Windows. While iCab and Firefox can set the accept 
headers independently from the the browser language, even if they 
default to that of the browser/system language.

>> So, the server is told what the preference setting of the Browser is
>> and thus, the Web page can extract this from the HTTP header and work
>> with it.
>> 
>> At the recent TPAC, we discussed that to provide better accessibility
>> support for video, we need to be able to read the default language
>> from the browser preference, then also the default setting for
>> displaying captions/subtitles and audio descriptions and react
>> accordingly in the Web page. The HTTP header parsing approach won't
>> work for default caption/subtitle and audio description settings. But
>> the Web pages that are loading will still require to find out about
>> these preference settings.
>> 
>> I believe we need to introduce standard javascript functions for such
>> preferences to be exposed to Web pages directly.
>>
>> If a Web page can read, e.g.:
>> 
>> navigator.userLanguage   -> e.g. set to "de-de"
>> navigator.userCaptions     -> e.g. set to "off" or "en-us"
>> navigator.userAudioDescriptions  -> e.g. set to "off" or "ja-jp"

This sounds very interesting. 

And I would assume that if the user sets his/her caption language to 
English, his/her audio descriptions to Japanese and navigator langauge 
to German, that he/she would also be ready to, in general, accept web 
pages English and Japanese, and probably German as well. And thus that 
this information could also be used when the browser sends out its 
accept language string. 

So, this should not be seens as independent from the accept language 
issues.

>> then it can react accordingly and e.g. display the Web page in German,
>> the captions for videos by default in English, and the audio
>> descriptions by default in Japanese.
>> 
>> I think we need this flexibility and we need such javascript
>> interfaces specified and implemented. Is this part of what HTML5 has
>> to do?

I think it definitely belongs here. After all, accept headers issues 
belongs here. [1]

[1] http://www.w3.org/html/wg/tracker/issues/88
-- 
leif halvard silli

Received on Thursday, 19 November 2009 02:15:30 UTC