For manifest in FPWD: Should Natural Language be Required per WCAG 2

[Ryladog]

https://rawgit.com/w3c/wpub/manifest-consensus-proposal/index-manifest-proposal.html#abstract-versus-concrete-manifest

[lrosenthol]

I assume that the relevant portion of WCAG on this one is https://www.w3.org/TR/2008/REC-WCAG20-20081211/#meaning-doc-lang-id

If so, this clearly refers to a web page - which is a single content document in a publication. There is nothing here in WCAG about the requirement that language be specified for the entire publication.

Also, given that the manifest (where the language will appear) does not have any text that needs to be specified - such a value in the manifest serves no practical need. However, it might be useful as metadata for something like search or identification - but that's why it shoudl be optional.

[avneeshsingh]

In WCAG 2.1, a publication consisting of set of files can also fall in definition of Webpage. The example of publication is added in definition of webpage
http://www.w3.org/TR/WCAG21/

This was to provide update for the work done in WCAG 2.1.
But coming to practical use, AT is more concerned with language of current HTML page instead of the language code placed in manifest.
On the other hand, language in metadata is important for search and discovery for accessibility reasons also. If my screen reader does not support Japanese, I should know from metadata itself (before loading the Japanese publication) that my AT will not work on the publication.

[lrosenthol]

On Wed, Aug 16, 2017 at 7:01 AM, Avneesh Singh ***@***.***> wrote: Language in metadata is important for search and discovery for accessibility reasons also. If my screen reader does not support Japanese, I should know from metadata itself (before loading the book) that my AT will not work on the publication.

I agree with that, Avneesh. Which is why we should consider the definition of Language in the metadata with "search and discovery" in mind and not with the eye towards reading (as it would be on the page). As such, I see that having two implications 1 - It's optional, because if the author doesn't put it in there, then the publication won't be found and it's their fault. 2 - We need a structure that allows for multiple values, to enable proper specification of a multi-lingual publication.

[laudrain]

I do agree with 1 and 2.
1 will also be for AT reading the metadata (title, authors) in proper language.

[iherman]

Thinking about this a bit further, I just realized that

• We know that each HTML file (looking at those only for the moment) have a language tag (albeit it may be the default, ie, English)
• I do not think that a language tag provided in the manifest should overwrite the language information in a specific primary resource

Which tells me that the language tag in a manifest may be valid for the manifest only, as far as reading, etc, goes. If this is indeed the case, then its usage is, after all, fairly limited and very specific...

(Yes, the situation is different for, say, primary resources that are all images.)

[iherman]

I do agree with 1 and 2. 1 will also be for AT reading the metadata (title, authors) in proper language.

Yes, absolutely. But what I am getting that is that the usage of the language tag in a manifest is (almost) exclusively for that purpose!

[mattgarrish]

Which tells me that the language tag in a manifest may be valid for the manifest only

That depends on what we're talking about. If it's language declaration for any text in the the json file, yes. If it's like dc:language in the EPUB package file, then no.

The reason EPUB requires language up in the package document is also because you can't necessarily easily determine when a publication is multilingual by inspecting the content. It also allows the user agent to quickly provide the option for downloading a dictionary, TTS extension, etc.

I can't argue it has to be required when it's only providing hints to the content, though.

And it doesn't set the language of any of the resources in the publication, so in that sense it is limited to the manifest.

But I can't see an xml:lang-like property being a stand-in for declaring a multilingual publication, since repeating it would result in gibberish.

[lrosenthol]

On Wed, Aug 16, 2017 at 8:44 AM, Matt Garrish ***@***.***> wrote: That depends on what we're talking about. If it's language declaration for any text in the the json file, yes. If it's like dc:language in the EPUB package file, then no. I don't believe that it is. Any text in the manifest should identify it's

own language. The language in the manifest, as discussed earlier, is about helping search & discovery of the publication.

[avneeshsingh]

Having multiple languages in metadata is important in some cases e.g. English to French dictionary. But, it looks that something like double core metadata is a better choice for it instead of xml:lang attribute.

[iherman]

Note the discussion related on PR #51, e.g., #51 (comment) and what preceded it.

[mattgarrish]

Closing this issue as discussed on the 2017-08-28 call. Issue #53 picks this up in relation to the current wording.

[iherman]

See telco discussion on closure.