– DRAFT –
Monday 5 Dec 2022 Adapt Task Force Teleconference

Draft CR resolution

DRAFT RESOLUTION: Subject to the CfC for the AAC Registry's First Public Working Draft (FPWD) being successful, the WAI-Adapt TF will request a transition to Candidate Recommendation (CR) for the Symbols Module 1.0 specification.

<CharlesL> +1

+1

<janina> +1

<Roy> +1

<Becky> +1

<Lionel_Wolberger> +1

<mike_beganyi> +1

RESOLUTION: Subject to the CfC for the AAC Registry's First Public Working Draft (FPWD) being successful, the WAI-Adapt TF will request a transition to Candidate Recommendation (CR) for the Symbols Module 1.0 specification.

matatk: Well done everyone! Special ACK to Lisa.

Lionel_Wolberger: We'll let Lisa know we're making this request.

Adapt Symbols Module Status

https://w3c.github.io/adapt/symbols/

Lionel_Wolberger: Looks like we're done! Does anyone have any thoughts about needed work?

janina: We don't need to go back to the TAG; I sent an email (CC'd to the list) and we got a response from management to agree with the email, requesting we add this info to the GitHub threads, which Roy did. So we take this as implicit permission to move forwrad.

Lionel_Wolberger: Do we need to explicitly confirm with TAG?

janina: When we make the transition request, management will see this.

Readiness of Explainers

matatk: I have to make the tweak to the example needed, raised by Becky. Didn't do it yet, due to CR and other prep, but will be on it shortly.

<Lionel_Wolberger> https://www.w3.org/TR/adapt/

Lionel_Wolberger: Is there also a TAG explainer we need to chase?

janina: We don't need to chase the TAG explainer.

Lionel_Wolberger: This hints at work to come, covers Adapt as a whole.

janina: There are some sections that are not yet done, but are placeholders. We'll get to them.

Lionel_Wolberger: It talks about modules, and each one having use cases.

matatk: The Editor's Draft is updated to refer to the Symbols Module as opposed to content module.

https://w3c.github.io/adapt/

Lionel_Wolberger: There's not a link to Bliss from the Explainer.

Lionel_Wolberger: Think we should reference Bliss/the registry in the Explainer.

janina: The magic comes from the Registry being used by/in conjuction with other specs.

Lionel_Wolberger: No actions on the Explainer? We need you all to read it!

janina: We're going to continue to publish updated WDs.

Lionel_Wolberger: Can we have volunteers to read it this week?

BCI Registry Specification

Lionel_Wolberger: We just met with Bliss. I was on the call too. We're good to go from Bliss' perpective on the FPWD. [We await the close of the formal APA CfC.]
… We discussed what'll happen after the Registry is published, future work.

https://w3c.github.io/aac-registry/

Due Diligence regarding our attributes vs existing alternatives (CSS Media Queries, @autocomplete, microformats, DPub, etc.)

<Roy> https://raw.githack.com/w3c/aac-registry/main/snapshot.html

BCI Registry Specification

CharlesL: Last time I mentioned the symbols are too small; looks better now. Please increase the size even more if possible.

Roy: I tweaked the CSS; could look into it further.

Roy: Some of the SVGs are different sizes.

Roy: We get the symbols from BCI; can make CSS tweaks but can't adjust them extensively.

CharlesL: Suggest bringing this up with BCI.

Roy: ACK; will ask Bliss.

matatk: I was looking into styling for prefers-color-scheme too. May be able to process the SVGs; we'll discuss with BCI as Roy mentioned.

CharlesL: Under Acknowledgements, it would be remiss to not have Lisa included here.

Lionel_Wolberger: +1

matatk: +1

janina: +1

<Becky> +1

Roy: I'll fix that.

<mike_beganyi> +1

janina: I'd like to be specific about who worked on the documents exactly. We must ensure that Lisa is acknowledged in the Symbols Module.

<Roy> https://w3c.github.io/adapt/symbols/#ack_group

CharlesL: ACK janina's point. I don't think we could've gotten here without Lisa bringing Bliss to the table.

Lionel_Wolberger: Lisa has been heavily involved with the AAC agenda; not directly with the Registry. So let's make sure Lisa is ACK'd on the Explainer and Module.

Due Diligence regarding our attributes vs existing alternatives (CSS Media Queries, @autocomplete, microformats, DPub, etc.)

Lionel_Wolberger: We've had a lot of debates on this; not sure where to start. Specific technical details on specific attributes, all the way up to philosophical issues on broad approaches.

Lionel_Wolberger: Floor is open

CharlesL: Specifically on @autocomplete. This was brought up many times. Some confusion over whether the functionality that's already there is enough. The problem is @autocomplete is only for form fields. We want to be able to put it on any element.

CharlesL: So we can't just use @autocomplete. We may share the same values, but can't use the attr.

Lionel_Wolberger: E.g. a footer might have an address in it. You think Adapt may want to mark that up with this attribute?

CharlesL: Yes; address (home/work) symbol could show up above the address.

matatk: We could just wask WHATWG about allowing @autocomplete in more places? That may require us to align completely on attr values(?), and in this attr's case, may complicate parsing rules too much, but worth asking?

<Lionel_Wolberger> Lionel says to Becky, your headset is cutting in and out

Becky: What exactly would @autocomplete mean if not applied to a form field? To me that's not about input, but just adding more info. A different attr would be more apt.

<Lionel_Wolberger> Sample: <label> Address: <textarea name=ba autocomplete="section-blue shipping street-address"></textarea> </label>

<Lionel_Wolberger> Sample: autocomplete="section-blue shipping address-level2"

CharlesL: @autocomplete I agree is a red herring, but it has a number of values that it uses to indicate common purposes. Those values are what we want to replicate, but we didn't want to duplicate things (or duplicate them, with new value names).

Becky: But how are we completing something if it's not a field?

CharlesL: Agree the name autocomplete doesn't make full sense here, but if these are all the same values, there is something in common there.

Becky: Why would we put any of these _values_ on a <div> (e.g.)?

CharlesL: We want to be able to convey the same "purpose" semantics as @autocomplete uses. E.g. the address in the footer is your street address. We don't necessarily want to call it "autocomplete" but we don't want to independently duplicate the values.

Becky: So we're not saying we should call it "autocomplete"?

matatk: The name isn't quite right (not even for what it's being used for now); I _was_ actually suggesting we consider asking to make the attr more widely appilcable to avoid duplication. Maybe we just link to the WHATWG spec for our adapt-purpose values though?

Becky: One confusing thing about this is that "autocomplete" implies the info is being filled in from somewhere. Wouldn't this cause confusion if, for example
… the address in the footer _didn't_ match the stored address for the user?

matatk: Agree that could be confusing.

Lionel_Wolberger: "autocomplete" has multiple different mantles; an anchor one, and an autofill expectation one.
… We're talking about extending that to other elements.

Lionel_Wolberger: Thanks for the discussion; have to wrap now.