w3c / adapt

Semantics to describe user personalization preferences.
https://w3c.github.io/adapt/
Other
51 stars 27 forks source link

data-purpose attribute referencing #145

Closed aphillips closed 3 years ago

aphillips commented 4 years ago

(From your I18N self-review #133)

data-purpose attribute does pattern after autocomplete attribute of HTML5 and author is responsible for any internationalization concerns.

This section contains many potential issues for I18N, but these are mainly external to your spec (as you call out). Is there a way for you to not need to duplicate that spec's keywords, etc. and just import the fields by reference? You'll have to avoid breakage as we work with them or as their spec evolved :-).

@becka11y suggests:

We incorrectly stated that we pattern data-purpose after the autocomplete attribute values of HTML5. We are basing the values off of WCAG 2.1. Specifically, Section 7. Input Purposes for User Interface Components. At this point, the listing matches HTML5 but may diverge in the future. If it does, we will follow WCAG 2.1. We will investigate a way to refer to the fields by reference.

lseeman commented 4 years ago

Are there additional questions? If not we may close this issue.

snidersd commented 3 years ago

Closing this issue since we have heard no objects.

aphillips commented 3 years ago

I was actioned with reopening this issue by I18N WG. We remain concerned that there are duplicate lists and that, by forking from HTML, you are importing a myriad of internationalization woes from that spec. For example, there are several date and time related fields, but no mention of different non-Gregorian calendar systems. There is a country code type but not a reference to country/region code standards such as ISO3166 or BCP47's registry. Etc.

Is it possible to separate this material and use it by reference? Or should we comment in detail on these keywords because you intend them to be distinct from HTML?

johnfoliot commented 3 years ago

Thank you for this feedback.

The Personalization Task Force are sensitive to these concerns, which is why we strongly support recent efforts/discussions around the creation of a W3C Registry for important spec fragments such as this.

One of our concerns however is the need for a rigid 'taxonomy' which we can explicitly control, which unfortunately discounts the current list referenced in the WHAT WG HTML5 Specification. (We also note that the same list is mirrored in WCAG 2.1 - Section 7 for exactly the same reason)

Due to the fact that many of our Accessibility specifications also become part of legally legislated requirements (etc.), and the fact that this emergent technology solution will likely be adopted as part of WCAG 2.x/WCAG 3.x this is a risk we cannot afford to take: if WHAT WG makes changes to their specification, it could invalidate or frustrate other requirements we must account for.

We also appreciate the direct feedback with regard to specifying 'which' ISO language codes can and should be used [*], as well as alternative calendaring systems, which the group will discuss and respond back with a proposed editorial change.

[ NOTE: WCAG 2.1's list is also remise w.r.t. specifying which* language code should be used: https://www.w3.org/TR/WCAG21/#input-purposes - will i18n file an issue there, or would your group prefer we do so?]

aphillips commented 3 years ago

@johnfoliot Thanks for the update.

WRT the language item, I am opening an additional issue now.

johnfoliot commented 3 years ago

I18n appears to accept our response. Closing as resolved.