Re: Web Browser Preferences and Internationalisation/Accessibility

On Thu, Nov 19, 2009 at 10:56 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On Nov 18, 2009, at 3:39 PM, Silvia Pfeiffer wrote:
>
>> Hi all,
>>
>> I have a very concrete request and I am not sure that the HTML WG is
>> the right place to solve it, but please bear with me.
>> If we want to improve accessibility and internationalisation support,
>> I believe we need to do something.
>>
>> All modern Web browsers have user preferences and as part of these,
>> you can choose your preferred languages for displaying Web pages.
>> These preferences are different to the language in which your
>> browser's user interface is presented: you can e.g. run your browser
>> in English and still want your Web pages inside the browser preferably
>> to display Japanese or French or some other language over English.
>>
>> Now, not all browsers actually expose this preference setting to Web
>> pages. AFAIK, only Internet Explorer does:
>>
>> IE has:
>> navigator.browserLanguage -> Browser Localized Language
>> navigator.systemLanguage   -> Windows OS - Localized Language
>> navigator.userLanguage       -> Windows OS - Regional Settings (this
>> is the exposure of preferences)
>>
>> Firefox only has:
>> navigator.language -> only the browser's localized language - no way
>> to get the preference in javascript
>
> navigator.language contains the same info that's in the UA string, I believe
> it works in all the non-IE browsers, and it's totally accessible from
> JavaScript.

No, it doesn't. It contains the language that your browser has been
installed in.
See, for example,
http://stackoverflow.com/questions/1043339/javascript-for-detecting-browser-language-preference
.

I had assumed the same and based my subtitle tests on that and ran
into some nasty issues with some French friends of mine, which upon
debugging exposed this issue. It is mentioned all over the web when
you try and look for language preference exposure in javascript.



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

You're right and it actually exposes the same language as navigator.language.

What I meant to write was that you have to analyse the
"Accept-Language" header of the HTTP request, which in fact contains
the browser preference settings. This is a horrible hack and the only
way for a Web page to find out the browser preference settings.

Try it for yourself: go into Firefox's preferences and add a language
that's not English and make it your first one. Then inspect your
navigator.language setting and your HTTP headers (firebug helps).


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

Apart from the problem with language, we still have to solve the
problem for captions and audio descriptions, since we don't have a
HTTP header for those that we could mis-use.

Cheers,
Silvia.

Received on Thursday, 19 November 2009 01:11:57 UTC