Extending accessibilityFeature for CJK writing directions

[murata2makoto]

The Japan DAISY Consortium proposes to add four values for CJK writing directions. At most one of these four values may be specified for a given EPUB publication.

Although this proposal is dated in 2021 March, we hope to make more experiments before we finalize these values. I explained this idea to CLREQ people.

1) cjkWritingDirection/vertical-writing

The EPUB publication containing this value can be rendered in the vertical-writing mode. Vertical-writing stylesheets are embedded.

Note: Some text in vertical-writing publications may be in the horizontal writing mode.

<meta property="schema:accessibilityFeature">cjkWritingDirection/vertical-writing</meta>

2) cjkWritingDirection/horizontal-writing

The EPUB publication containing this value can be rendered in the horizontal-writing mode. Horizontal-writing stylesheets are embedded.

<meta property="schema:accessibilityFeature">cjkWritingDirection/horizontal-writing</meta>

3) cjkWritingDirection/vertical-writing-alternate-horizontal-writing

The EPUB publication containing this value can be rendered in both the vertical-writing and horizontal-writing modes. But the primary target is vertical writing. When the horizontal-writing mode is used, the result might not be totally satisfactory.

<meta property="schema:accessibilityFeature">cjkWritingDirection/vertical-writing-alternate-horizontal-writing
</meta>

4) cjkWritingDirection/ horizontal-writing-alternate-vertical-writing

The EPUB publication containing this value can be rendered in both the vertical-writing and horizontal-writing modes. But the primary target is horizontal writing. When the vertical-writing mode is used, the result might not be totally satisfactory.

<meta property="schema:accessibilityFeature">cjkWritingDirection/horizontal-writing-alternate-vertical-writing
</meta>

For more background information, see Discovery of the Writing Direction.

[mattgarrish]

Just on a skim, there are two potential issues I see:

• the slash method of extending enumerations that was in place when we developed the accessibility properties has since been dropped by schema.org. See the page on extensions and you'll find the slash model under the archived 2011-2014 approach. It might be more modern not to persist it even if we're stuck with it for the old values (but we should look at retiring the slashes eventually).
• in that old model, when you used a slash it was supposed to extend an existing value, but <meta...>cjkWritingDirection</meta> appears to be a descriptor.

The solution might be as simple as changing the slashes to dashes and the dashes to underscores so the values don't look like the old extensions (e.g., (cjkWritingDirection-vertical_writing). You can see examples of this approach in the GS1 vocabulary linked from the schema.org extensions page.

[clapierre]

+1 to just changing the / to a - for this and the other proposed new values

[murata2makoto]

The JDC has changed its mind. We would like to begin with simple values: verticalWriting and horizontalWriting. I will create a pull request for them soon.

[mattgarrish]

@xfq I see you opened an issue for the i18n group to track this issue. Does that group have any input on the proposed additions in #79 before we look to merge it?

[aphillips]

The i18n-tracker label automatically creates a tracking issue. I have added this issue to the I18N WG's 2023-06-29 agenda.

I would call out that cjkWritingDirection might be inappropriate, as it implies that only CJK documents use vertical text. Many other languages use a vertical writing mode, either natively or at least optionally. Support for vertical text should allow for writing mode and block progression and such in any document that needs it.

[mattgarrish]

Thanks @aphillips. As @murata2makoto mentions in https://github.com/w3c/a11y-discov-vocab/issues/3#issuecomment-1597244770, the proposed pull request only adds the more generic terms verticalWriting and horizontalWriting, so these values should be of use more widely than the original proposal.

They're also asking for fullRubyAnnotations to differentiate from publications with only partial ruby (which the existing rubyAnnotations term would be used for).

[murata2makoto]

@aphillips

As @mattgarrish wrote, I changed the name from cjkWritingDirection to verticalWriting and horizontalWriting. However, I would like to point out that these values are unlikely to be used for non-CJK, since dc:language implies the writing direction for non-CJK languages.

[mattgarrish]

since dc:language implies the writing direction for non-CJK languages

That only works for EPUB, though. The vocabulary is intended for the web generally, too, so I think it's still helpful to have non-region specific terms.

[murata2makoto]

That only works for EPUB, though. The vocabulary is intended for the web generally, too, so I think it's still helpful to have non-region specific terms.

Right. Should we add a mechanism for specifying the language just in case the underlying format does not have dc:language?

[mattgarrish]

Should we add a mechanism for specifying the language just in case the underlying format does not have dc:language?

That's getting beyond the scope of this vocabulary. I'm assuming the lang/xml:lang attributes are probably similarly sufficient for individual web pages, when present, but that assumes other information harvesting is going on.

[r12a]

The direction for Mongolian (in CSS vertical-lr) is vertical but lines go from left to right. This means that books open from the opposite side from CJK vertically-set text. This option appears to be missing from the list proposed.

[r12a]

@murata2makoto Could you explain in more detail what this metadata will be used for ?

[murata2makoto]

@r12a

First, both vertical writing and horizontal writing are used in Japan and Taiwan.

Second, some Japanese cannot read vertical writing. Other Japanese cannot read horizontal writing. (This appears to be much rarer.) I suppose that the same is true for the Taiwanese.

The proposed values are intended to be used for those Japanese or Taiwanese who cannot read horizontal or vertical writing.

In other words, the proposed values are useless when the language of the content has only one permissible writing direction or when everybody can read both writing directions.

[mattgarrish]

The accessibility feature property is generally intended to provide users information about how the content meets accessibility needs. Existing terms cover features like the inclusion of captions, transcripts, alternative text, long descriptions, the ability to transform the default text styling, etc.

I assume for languages that can be written in either direction, these values are intended to help users select the format that is easiest for them to read. Is that correct @murata2makoto ?

The metadata isn't intended to describe the general layout, so if a language isn't written in multiple directions then it shouldn't be handled as an accessibility "feature".

[r12a]

Ok, so this metadata doesn't affect the layout or treatment of the content; instead it informs the potential reader about what type of content this is. Is that correct?

[murata2makoto]

@r12a

RIght. This metadata does not change the layout or treatment of the content. It merely makes clear what the content is.

[mattgarrish]

For background, the original project to get accessibility metadata into schema.org was to help students find material they can use, whether by being able to filter search results or by having the information displayed (e.g., we're making progress on getting accessibility information displayed in bookstores with EPUB).

It was definitely never intended to influence rendering and it's not used for that purpose anywhere I know of.

[aphillips]

A few minor points.

However, I would like to point out that these values are unlikely to be used for non-CJK, since dc:language implies the writing direction for non-CJK languages.

Language information should only be used to infer base direction of content and I18N recommends NOT to use language metadata as anything except a hint about the direction of content. While it is the case that most non-CJK languages do not use vertical text or use it only rarely (and noting classical Mongolian is an exception), the world is a big place and it is a good idea not to assume this is strictly the realm of CJK.

Also, vertical vs. horizontal writing is only one aspect of content presentation. Is the introduction of vertical/horizonal metadata also intended as a proxy for something like EPUB's page-progression-direction ("PPD")? In CJK, vertical/horizontal imply a different PPD. PPD determines a variety of paginated media navigation controls, spine location, margin handling, and so forth.

[murata2makoto]

@aphillips

Please understand that this issue is about accessibility metadata, which is not used for rendering. EPUB uses CSS and the page-progression-direction for rendering, but does not use accessibility metadata. In other words, EPUB reading systems rely on CSS for determining the writing direction. They NEVER use the proposed value.

This proposed value is primarily for those CJK users who can read horizontal writing but cannot read vertical writing. Bookstores or libraries are expected to use the proposed value for allowing such users to find what they can read. If some Western users would like to search for vertically-written books written in Western languages, specifying the proposed value would make sense.

[mattgarrish]

For reference, this metadata is required by the EPUB Accessibility specification for discovery purposes. See https://www.w3.org/TR/epub-a11y-11/#sec-disc-package

[mattgarrish]

We've had this issue and pull request open for several weeks now, so it would be good to finalize it.

Please consider this as 72hrs notice that we're going to merge the pull request and close the related issues unless there's new feedback (so by 15UTC on July 18).

[mattgarrish]

Closing with #79