– DRAFT –
WAI Adapt Task Force Teleconference

Holiday schedule reminder

janina: Dec 26 off for Winter Holiday. Jan 2 off, too close to New Years. Jan 9 on, Jan 16 off (MLK)

CR status

<matatk> https://github.com/w3c/adapt/pull/237

janina: We are merging Matthew's PR into the Explainer

janina: Should we publish an updated explainer working draft?

becky: Yes. Major enough changes were made, and updating working drafts is routine.

sharon: This includes all the symbol updates as well, so yes

<matatk> +1

+1

<janina> +1

<mike_beganyi> +1

RESOLUTION: Task Force requests publication of Explainer updated working draft

Symbol Module Implementations

Lionel_Wolberger: I was thinking that one implementation could be that, a symbol board user could get an interopable JSON file describing the symbols that were on the board that I learned
… then I as a patient could have a continuation of my therapuetic surrounding

janina: Consider that current symbol dedicated-devices could also load and render symbols for web pages.
… if they are increasingly using small device off-the-shelf operating systems, where Web support is built in already

sharon: We had minuted a discussion with a Firefox developer

janina: And Matt's prototyped AAC tool

Autocomplete

matatk: This is part of an overall due diligence series, taking a new look at our architecture.
… There are a few technical details to check against the last version of the spec
… autcomplete may not work in all our use cases
… the rules already seemed quite complex, so broadening autocomplete may be out of the question
… Critical to check exactly how we are using it

<janina> +1

<matatk> +1 to Lionel's idea of doing something structured, and recording the result

Lionel_Wolberger: Sounds like we are embarking on a gap analysis between certain pre-existing standards and our proposed standard.
… if so, we should summarize any findings, so we can refer to this in future.

<matatk> +1 to sharon, Janina, re making the results clear and discoverable.

janina: We need to satisfy TAG that we have thought this through

Lionel_Wolberger: Gap analysis can proceed lightweight as follows:
… Identify the two HTML elements that you want to compare

Determine the purpose and intended use of each

Lionel_Wolberger: Determine the purpose and intended use of each
… Compare the structure and content of the two elements
… Identify any discrepancies or differences between the two elements. These may include differences in structure, content, or functionality.
… Summarize list of the specific areas where the two elements differ and note any potential impacts or consequences of these differences.
… look at root cause of any discrepancies or differences that you have identified.

<matatk> Starting point: https://github.com/w3c/adapt/wiki/Comparison-of-ways-to-use-vocabulary-in-content

matatk: The table, https://github.com/w3c/adapt/wiki/Comparison-of-ways-to-use-vocabulary-in-content, is an ideal starting place for these gap analyses
… We focus on the delivery mechanism
… the vocabulary style
… Then there are cases where we decided that we are going to use an attribute.
… Then, given that decision that we are committed to using an attribute
… we have a decision, shall we use a pre-existing attribute or a newly invented attribute
… @rel was a good example, it was similar to 'destination'
… this led to discussion of, what is the minimal number of changes that we require of @rel as-is, to make it do what Adapt TF deems needed for the 'next billion' disabled?
… We certainly have considered all the different vocabularies
… I suggest we put the results of our Gap Analyses, such as they might be, and add them to the wiki