- From: John Foliot <john.foliot@deque.com>
- Date: Wed, 16 May 2018 15:42:29 -0500
- To: public-personalization-tf <public-personalization-tf@w3.org>, W3C WAI Accessible Platform Architectures <public-apa@w3.org>
- Message-ID: <CAKdCpxy+LT5gW-SaPLH0KRmY5qq23yphnObboOTEJPukjHgP2g@mail.gmail.com>
>From today's APA Call, the following was recorded in the minutes: Michael: John is objecting to these examples. Not offering to clean them up. We thought the examples are better than nothing for now. Can I please know who the "we" is here? Was this group consensus decision recorded anywhere? Is there a public or private URI or previous meeting minutes I should review? Michael: Objection is not to the deliverable. The chair could determine that this objection is not relevant. With all due respect, the focus of my objection *IS* the deliverable(s). >From my CfC response: " Deque supports the ongoing work of the APA WG, as well as moving the Personalization Task Force from the ARIA WG to the APA WG. *Our concern is with the Rec Track Modules defined in the Charter deliverables.* **"** Continuing: Janina: John objects to having attribute prefixes in examples. But in the past 24 hours we have put a disclaimer in. I note the presence of this new disclaimer on the Editor's Draft(s) of the Content Module, The Help and Support Module, but NOT the Tools Module (May 16 version) <https://rawgit.com/AreaOfAKite/personalization-semantics/thad-tools/tools/index.html>, which also states: Introduction This section is non-normative. This document lists examples of the Personalization Tools *attributes.* Additionally, the Personalization Semantics Explainer <https://w3c.github.io/personalization-semantics/#vocabulary-implementations> (Editor's Draft 16 May 2018) effectively states that the aui-* attribute pattern is part of the deliverable. To be clear then, the principle objection is to the implied AND STATED approach of using attributes to solve (at times undefined) problem statements, which more than one TF member has expressed to me privately as being overly complex for content authors and unsustainable at scale. I concur with these observations. I would like to see indicated in the Charter a work item that clearly indicates that one of the important and principle tasks of this Task Force is to revisit the attribute approach that has been explored to date (due to expressed concerns), and additionally that each of the modules remove any reference to aui-*, coga-* or aria-*. If example code is deemed critical to better understanding, then the TF should be using notation similar to @@-* (or TBD-*) - but clearly STOP referencing any of the previously proposed prefixes to further ensure that observers(*) who are not part of the weekly discussions of this TF can none-the-less conclude that the existing proposed approach is being revisited, and that other approaches are being investigated. (* i.e. AC Reps who will also need to approve this Charter) JF -- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion
Received on Wednesday, 16 May 2018 20:42:53 UTC