Currently, the UI language of a browser is exposed via window.navigator.language. Some "clients" need to access the value of Accept-Language the same way ( window.navigator.acceptLanguages). See http://crbug.com/14574
sorry for bug spams.
It would be great to simplify localization for Web applications, if that's the rationale for adding this feature to the Web platform, and not just as an extension for Chromium plug-ins. But it is not obvious whether exposing accept-language is the way to do it. This really looks like a topic for whatwg discussion to me.
The use case we had in mind was actually translation. If we had the accept languages of the browser available to JavaScript, it could be implemented as Chrome extension. This seems like a reasonable thing to explain through the web platform, but I agree it should also get brought up on whatwg.
Since https://bugs.webkit.org/show_bug.cgi?id=163220, this information is available through the window.navigator.languages property (https://html.spec.whatwg.org/#navigatorlanguage), so I believe this can be closed.
In WebKit, window.navigator.languages is just an array with one element, so it doesn't add anything new that window.navigator.language didn't provide. That said, Accept-Language has been simplified accordingly too, so this feature would be pointless.