Language declaration necessary in the body tag for certain Reading Systems

[antoinentl]

Certain Reading Systems need a language declaration in the body tag : "iBooks, for instance, ignores xml:lang on html and this is why we must attach it to body as well. Else, hyphenation and TTS will be completely messed up." (source)

Is it possible to add this point in the EPUB 3 Accessibility Guidelines ?

[mattgarrish]

Thanks for the report. Sounds like a failure of the reading system, since the scope extends down to all descendants unless overridden.

I don't really like giving guidance to work around a failure, as it could be taken to mean just put the attribute(s) on the body and forget about the root, while that would leave the title and any metadata in the head without a language. But we may have to note given the popularity...

I was hoping to find out if there were other failures, but I don't see language being tested in the fundamental accessibility checks on epubcheck.org. I'm going to look into that, as well. I'll update the docs once I have a more complete picture.

[antoinentl]

@mattgarrish I agree that this is a problem on the reader's side, to complement: https://gist.github.com/dvschultz/3a3c4836458aceca744d#file-bkcontentcleanup-L202 (thanks @JayPanoz)

[JayPanoz]

To provide further details:

1. we had had hyphenation issues for 2 years in iBooks then apps using the iOS WebView until we discovered adding lang to body fixed this issue (2 years ago).
2. then we discovered this is how InDesign EPUB output manages it by default (correlation, not causation)
3. while testing text-to-speech using VoiceOver in MacOS and iOS in various apps, I witnessed the scope doesn't extend down at all: you must declare lang for every element, directly, e.g. li cos’ it won't work for ul or ol, p as it won’t work on blockquote, etc.

As far as I can tell, there’s another important issue when it comes to overrides: lang packages actually installed by the user on OS X, Android, etc.