Localized statements of accessibility metadata

[GeorgeKerscher]

On the October 26, 2023 call, the question was asked if there was a collection of accessibility metadata statements that would be available for translation. It was expressed that there is the intention to collect the statements and organize a mechanism for localization. This work has not yet started and we do not have a design that has been proposed.

[gregoriopellegrino]

Given the freedom we allow in implementation, I don't know if Group Note is the best place to work on localization. In my vision localization is more of an implementation aspect, rather than a guideline aspect.

My proposal would be - once the work on the guidelines is done - to work on a tool to serve the supply chain to do ingest of accessibility metadata (ONIX, EPUB metadata, etc.) and generate the Key Information identified in the guidelines. This tool should include a localization system (similar to that used for EPUBCheck). Fondazione LIA can participate this work.

[rickj]

We will be translating (once they are finalized) the descriptive and concise explanations for each of the 9 key accessibility information areas into the following 37 languages, and would be happy to donate them.

Canadienne-française (French Canada)
Catalan
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
English (English)
English-UK (British English)
Español (Spanish)
Español Latino (Spanish Latin America)
Français (French)
Hindi (India)
Iceland (Icelandic)
Ireland (Irish Gaelic)
Italiano (Italian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian Bokmal)
Polski (Polish)
Português (Portuguese)
Português Brasil (Portuguese Brazil)
Pусский (Russian)
Românã (Romanian)
Suomi (Finnish)
Svenska (Swedish)
Tagalog (Filipino)
Tiếng Việt (Vietnamese)
Türkçe (Turkish)
Wales (Welsh)
Ελληνικά (Greek)
български (Bulgarian)
עברית (Hebrew)
العربية (Arabic)
ภาษาไทย (Thai)
한국어 (Korean)
日本語 (Japanese)
简体中文 (Chinese Simplified)
繁體中文 (Chinese Traditional)

[wareid]

@rickj That's incredibly generous and will be so helpful!

In terms of how to provide the translations, it might be good to have a few options. I agree with Gregorio that they can and should be included in tooling, but perhaps making a few other versions available will be helpful too. We could just host from GitHub. Having the files in plain text, HTML, and maybe a JSON format might be beneficial to everyone.

[rickj]

Let me see what our outsource can do. I guess I need to know if the statements in 3.x "Key accessibility information" in this draft are final. Who makes that call?

[martinpub]

Hi everyone,

Even though we haven't been active yet in this group, the Swedish Agency for Accessible Media (MTM) will be happy to provide input on or review the Swedish translations, just let me know. We are starting up a project internally to work with various questions around accessibility metadata, including our production but also promotion work nationally in the light of the EAA.

[gautierchomel]

To deal with different sources of translations and encourage strong linguistic areas localization process we'll need a dedicated translation webpage. We also think that the localization process should be an opportunity for the interprofessional organisations to take ownership of the standard, to work together and to communicate with the public.

Proposed wording to reflect that in the Localization section:

For users looking for books, a similar UX experience is crucial to not add cognitive charge to the already complex task of understanding what features are included in the book and which way to access to it have been thoughts.

The wording is part of the UX and similarities of wordings in language areas are as crucial as the organization and categorization of the information.

The wording proposed in this guide has been widely discussed by a large group representing different actors of the english speaking geographies. It has been improved after proof of concept implementations and panel testers.

To agree on linguistic areas wordings the actors should follow a standardization framework. The ux guide translation webpage proposes such framework and list translations of two types :

• Authorized Translations follow a formal review process and are endorsed by W3C.
• Unofficial translations are not reviewed and are not endorsed by W3C.

[mattgarrish]

Authorized Translations follow a formal review process and are endorsed by W3C.

This is a community group. All it can produce are community group reports which have no standing in W3C, so it seems unlikely it can have "authorized translations" of those reports. Correct @iherman?

I expect any translations will be unofficial, but maybe you could differentiate between the ones the CG has produced and ones that were submitted without any review. Anything more than that probably runs afoul of W3C process.

[iherman]

Authorized Translations follow a formal review process and are endorsed by W3C.

This is a community group. All it can produce are community group reports which have no standing in W3C, so it seems unlikely it can have "authorized translations" of those reports. Correct @iherman?

That is correct. The goal of the authorized translation process is to ensure that translations of recommendations can get more or less the same value and weight as the originals; important when these documents become part of national legislations, for example.

I expect any translations will be unofficial, but maybe you could differentiate between the ones the CG has produced and ones that were submitted without any review.

The CG has the possibility to publish a CG final report, and I believe it is perfectly fine to do so with a translation.

[mattgarrish]

and I believe it is perfectly fine to do so with a translation.

Right, I guess it depends on whether the whole documents are being translated or only the example strings.

If it's the latter, maybe there's a way of incorporating the translations into the report. We had discussed using javascript objects to inject the strings into the document at one point, so that they would be used consistently. Perhaps we could look at adding a language selection box to the examples so that users can rotate through the translated strings without having to leave the document (the translated js files could also be linked to, of course, if people want to grab the complete translation set). But just a thought.

[gregoriopellegrino]

That's right: we don't want to translate the whole document, but to have a repository where we can find the strings in the document in machine-readable format, available in different languages.

However, we would also like to define a control process for figuring out who can publish a localization in the repository.

[mattgarrish]

However, we would also like to define a control process for figuring out who can publish a localization in the repository.

Well, that's where maintaining translations becomes a headache. In this case, the CG controls push access to the repository so what you're asking is how does this group evaluate the quality of the translations being provided, or how are they assigned to individuals/groups to maintain. That can be tough without adequate representation for each language.

It might be less contentious if anyone can submit a translation (without endorsement by the full CG or W3C) but they are encouraged to review existing translations and make suggestions to them rather than submit new ones -- and have to provide a rationale for why a competing translation should be accepted if they can't live with an existing one.

I don't know that this group would have the resources to take on a process more complicated than that.

[gautierchomel]

Thanks for the insights. It looks like only the last phrase is problematic. Here is a proposed different wording (after the quote paragraphs for context):

For users looking for books, a similar UX experience is crucial to not add cognitive charge to the already complex task of understanding what features are included in the book and which way to access to it have been thoughts.
The wording is part of the UX and similarities of wordings in language areas are as crucial as the organization and categorization of the information.
The wording proposed in this guide has been widely discussed by a large group representing different actors of the English speaking geographies. It has been improved after proof of concept implementations and panel testers.

To agree on linguistic areas wordings the actors should follow a localization framework. The UX guide translation webpage will propose such framework and list translations with contextualization of the localization process.

[GeorgeKerscher]

I think this sounds good. When I edit the whole document, I'll make those changes needed, but this is good to include now.

[jonaslil]

We at Celia will be happy to review or give input on the Finnish localization.

[rickj]

Some thoughts after discussing this more with our dev team…

• The techniques document will need some type of mapping of metadata element to canonical English phrase (be it pseudo code, or XSLT used)
• This pairing will also need some reference identifier so a suitable translation of the English phrase can be looked up when needed
• A flexible model for this could be accomplished using JSON where you have <metadata element> <English phrase> <identifier> and for the translation lookup <language> <identifier> <translated phrase>

[rickj]

It would be helpful to have a handful of test items to work with. Does a document exist with <metadata element> <English phrase> pairings?

[gautierchomel]

I think about one .json file per localisation with high-level data to identify Author, Language and a Description then a per key examples list.

A publishing method to allow for an HTML consultation of if would be a plus.

Here is a code example to illustrate the idea:

{
    "author": "W3C Publishing Community Group Accessibility Task Force",
    "language": "en-US",
    "description": "Original wording discussed by a large group representing different actors of the English-speaking geographies. It has been improved after proof of concept implementations and panel testers.",
    "3.1": {
        "Key": "Supports nonvisual reading",
        "Example1.1": "All content is available in generated read aloud speech and electronic braille."
        "Example1.2": "Portions of the content may not be available in generated read aloud speech and electronic braille."
...
      }
  }

[avneeshsingh]

We should also explore if using a tool would be a good option. For example EPUBCheck is using transifex.

[gautierchomel]

Attached is a proposal canonical.json file to start iterations on the structure. I see two questions raising:

• Do we want human readable Keys? (i.e. "positive-compact": "Readable in read aloud and braille." instead of "4": "Readable in read aloud and braille.").
• Do we go with nested keys? (meaning that publication and authoring tools must accept such structure)

[clapierre]

Hi Gautier,
I would think we would want them to be human readable.
We need to make sure that the translation file to JSON file if these are not the same thing there is an easy way to go from one to the other.

ie.
Supports nonvisual reading: Positive Impact= "Readable in read aloud and braille."

Unless I am not understanding what you are asking.
Also, not 100% about your 2nd question.

[rickj]

assuming "variante": "canonical" should be "variant": "canonical", ?

[gautierchomel]

WIP #255