Accessibility Attribute Request

[JaninaSajka]

W3C's Accessible Platform Architectures (APA) Working Group requests registration of adapt- as a attribute prefix per joint conversations on intended use during W3C TPAC
+2022, and further supported in this followup issue.

Our initial use is in support of Augmentative and Alternative Communication (AAC) symbols as specified in the W3C WAI-Adapt: Symbols specification currently in Candidate Recommendation
+(CR) status. Additional specifications for distinct uses of the attribute based on the WAI-Adapt Explainer will follow.

[zcorpan]

cc @whatwg/a11y

[cookiecrook]

As I understand it, this is an open-ended prefix request, but with currently two primary, slightly overlapping use cases: symbolic representation and complexity simplification.

Symbolic Language Representation (adapt-symbol attr)

As I understand it, the APA group is interested in a path toward using Blisssymbolics or another symbol set which I could not find as easily ("Aroset" perhaps?). At TPAC ~2018 several people (including but not limited to me) suggested that APA members help shepherd the adoption of the Bliss symbol set into Unicode. Response was that this was first proposed in 1993, and has remaining blocking questions as of the last Wikipedia edit in 2009.

There was some hallway discussion that this could be incubated/prototyped using Unicode symbols (once available in UCS/Unicode) and Ruby-style render box stacking.

Complexity Simplification

Some examples from the explainer:

1. <span adapt-easylang="90% of the time this happens"> normally this is the expected outcome</span>
2. <p adapt-simplification="critical">Today’s forecast is a high of 95° and a low of 40°</p>
3. Another listed looks like microdata better solved IMO by other means <input type="textarea" id="address" adapt-purpose="street-address">

In my opinion, 1 will be better solved at scale by AI/ML language models. Something similar to Number 2 may be useful in the context of important content that is inadvertently omitted by a solution to Number 1. Number 3 should be removed and addressed elsewhere.

Personal Recommendation

I think the request to reserve adapt-* for open-ended use by APA is premature given the W3C's current approach to prefer an incubation process for this type of proposal. If a WICG incubation group was spun up that ideally included browser implementations behind flags, that may result in a good outcome for one or more of the ideas.

[cookiecrook]

Similar comments from an earlier TAG review:
w3ctag/design-reviews#476 (comment)

and later discussion where the TAG’s feedback was reiterated.
https://www.w3.org/2022/09/13-apa-minutes.html#t01

[domenic]

We discussed this issue on the HTML triage call (#9308) today. First, we were all thankful to the APA group for opening the issue to discuss with the HTML community. It's great when HTML is developed collaboratively in this way, including such early notice for incubation-stage specifications.

We were a bit unsure on the situation because we weren't clear whether the proposed specification was targeting implementation in web browsers.

If the proposed specification is targeting implementation in web browsers, then our usual criteria (per the WHATWG working mode) applies. This needs 2+ browser engines interested in implementing the specification, and ideally already landing code. Then we can consider such attributes as reserved.

If the proposed specification is not targeting implementation in web browsers, but instead is a vocabulary for some communities to use when marking up their documents, then the path forward is a bit less clear. We can generally commit that the HTML Standard itself will not introduce new attributes with a dash in their name. But whether the rest of the HTML-writing community will respect your claim on these attributes, is not really within our scope. We discourage the community from using any attributes with dashes in them unless they are prefixed with data-, but as you can see from #2271, it's not clear how well our guidance is taking hold, and there's also a general idea of allowing custom attributes similar to how we allow custom elements. This space of "custom attributes" isn't at all settled yet, nor is it something anyone is actively pursuing, so the intersection is hard to understand.