Re: Disappointment (was: And... WAI_Adapt it is)

Hi Charles,

Yes, I did say I could live with it, but I truly am disappointed, for the
reasons I have laid out. I guess I am also disappointed that so many
external commenters had such an influence here, but, c'est la guerre.

I am moving on, and agree that forward movement is best.

JF

On Wed, Apr 6, 2022 at 8:29 PM Charles LaPierre <charlesl@benetech.org>
wrote:

> 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> 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>
> 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
>>
>>
>>
>>
>> Lionel Wolberger
>> COO, UserWay Inc.
>> lionel@userway.org
>> UserWay.org <http://userway.org/>
>> <https://userway.org/>[image: 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"
>
>
>

-- 
*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"