- From: Charles LaPierre <charlesl@benetech.org>
- Date: Thu, 7 Apr 2022 00:29:46 +0000
- To: John Foliot <john@foliot.ca>
- CC: Lionel Wolberger <lionel@userway.org>, public-personalization-tf <public-personalization-tf@w3.org>, Judy Brewer <jbrewer@w3.org>, Philippe Le Hegaret <plh@w3.org>
- Message-ID: <6151A5AD-2B10-4B33-BF47-C989CFA7F886@benetech.org>
I am surprised by your reaction John, because just last week in a call for consensus you replied and stated on record: FWIW, I can live with WAI-ADAPT, could live better with WAI-Adapt (case sensitivity), and strongly oppose WAI-APT (what's a WAI Apartment<https://www.merriam-webster.com/dictionary/apt#:~:text=an%20apt%20pupil-,apt,2%20aptitude>?) So they actually went with the “could live better with” option you said. I realize it's not perfect and we could bike shed this for the next year, lets move on as we have bigger fish to catch ;) Thanks Charles EOM Charles LaPierre Principal, Accessibility Standards, and Technical Lead, Global Certified Accessible Benetech Twitter: @CLaPierreA11Y On Apr 6, 2022, at 1:59 PM, John Foliot <john@foliot.ca<mailto:john@foliot.ca>> wrote: This is truly sad to hear Lionel, especially given there were some real and valid reasons why both Lisa (one of the original co-chairs) and I were unhappy with that particular name choice. I fear it is far too focused on the ACC symbols piece, which is but 1/6th of our initial module - even though that one proposed attribute has taken a lion's share of our time since i18n got involved (who also did not understand our intentions). I am also quite disappointed that a decision is being dictated to the group that worked on this specification by outside commentators (so much for seeking consensus at the W3C). I thought that Groups should favor proposals that create the weakest objections, which is preferred over proposals that are supported by a large majority but that cause strong objections from a few people. FWIW, I strongly object to this name choice, and regret that I was not as forceful in expressing the strength of that objection earlier. ********************* I again reiterate that there is NOTHING specifically related to adaptation (def.: the act or process of changing to better suit a situation) with the proposed attributes of: * Action<https://www.w3.org/TR/personalization-semantics-content-1.0/#action-explanation>: The action attribute provides the context of a button. It is typically used on a button element or element with role="button". * Destination<https://www.w3.org/TR/personalization-semantics-content-1.0/#destination-explanation>: The destination attribute categorizes the target of a hyperlink. * Purpose<https://www.w3.org/TR/personalization-semantics-content-1.0/#purpose-explanation>: The purpose attribute provides the context of a text input field such as a text box. It is typically used on an input of type text, or an element with a corresponding role. Two of the above three specifically note that the attribute adds additional contextual information to the parent element. It is true that we envision that *user-agents* will be able to use our embedded metadata to customized a specific user's experience based on that contextual information (which may or may-not involve changing or modifying the user interface to meet specific user needs), but we are creating an authoring spec, and not a tool/mechanism/API/process that does the adaptation, which I argue the current name choice seems to allude to. It also presumes that the ONLY reason to add these attributes and values is for adaptation purposes, completely ignoring the fact that embedded metadata can be far more useful than just that. For example, the attribute that was a bit of a template for our work, and one that is currently the only technique for WCAG SC 1.3.5 "Purpose of Input" is @autocomplete - where we essentially reverse-engineered that attribute's intent (which was initially intended to simply assist in filling forms) by noting that besides performing an action, we could use that attribute and its fixed taxonomy list (tokens) to also output information about the input in "different modalities". But at the end of the day, that particular attribute does NOT provide any adaptations - it simply tells user-agents what data to inject into form inputs. I realise it is likely now too late to reverse things - the fiat decision<https://www.merriam-webster.com/dictionary/fiat#:~:text=1%20:%20an%20authoritative%20or%20arbitrary,world%20was%20created%20by%20fiat.> has been made, and life moves on. But I remain quite unhappy with how this all evolved; it was very un-W3C-process<https://www.w3.org/2021/Process-20211102/#Consensus>-like. JF On Wed, Apr 6, 2022 at 3:26 PM Lionel Wolberger <lionel@userway.org<mailto:lionel@userway.org>> wrote: Dear Public-Personalization-Tf, We just completed the WAI Coordination Call, Janina, Matt, Sharon and Lionel attending representing Personalization, Shawn and Brent representing EO, as well as others. After a discussion where all issues that we have raised were aired, the decision was made: WAI-Adapt WAI-EO will consider composing a tagline, a short descriptor that would appear alongside it for example on the TPAC Introductory Slide. Thanks for a good process surrounding this, - Lionel [https://docs.google.com/uc?export=download&id=1lTmh0NemstqEtf_RzlGZvzGa-8QlCS4f&revid=0BzNhq44zrVUWRm5XMzNyRUxsdTFsNEhxaS9SV0RSSHBBUER3PQ] Lionel Wolberger COO, UserWay Inc. lionel@userway.org<mailto:lionel@userway.org> UserWay.org<http://userway.org/> <https://userway.org/>[text] -- John Foliot | Senior Industry Specialist, Digital Accessibility | W3C Accessibility Standards Contributor | "I made this so long because I did not have time to make it shorter." - Pascal "links go places, buttons do things"
Received on Thursday, 7 April 2022 00:30:03 UTC