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.

[matatk]

Thank you @cookiecrook, @domenic, @zcorpan, @annevk and all for your consideration and input (and sorry for not replying to you substantively on w3c/adapt#203 yet, @cookiecrook; we've been updating our gap analysis to answer your questions in that issue).

We've re-focused for now on the symbols work (and are working closely with Bliss). We're investigating the best ways to support the other aspects, and we think that some may be do-able via other means, as you suggest, but others may still need attributes (in which case, we'll update this thread).

Our expectation is that the assistive technologies developed to add the appropriate symbols to pages will be browser extensions, at least for now, so we're not requesting any major browser engine changes (the symbols would be inserted via DOM manipulation via a content script).

Given that we need to garner 2+ independent implementations of ATs that support symbols in order to move our spec to the next stage of maturity within W3C, it seems best that we come back to this issue when we have done that, so we can show you the progress we're making. In the meantime, we take on board all of your feedback.

@cookiecrook: might we be able to meet at TPAC to go over our latest symbols work with you? (If so, can we email you, or please could you email us?)

Thanks again all; more from us in due course.

[annevk]

@zcorpan and I ended up echo-ing @cookiecrook's feedback in w3c/adapt#240 (comment) (and asking for that to be reopened) after a chat with @JaninaSajka and @matatk at TPAC. No need to have a second registry for symbols in the web platform.

[cookiecrook]

@matatk Sorry I missed the last @ mention in June, but it was good to discuss this (albeit too briefly) at TPAC this year.