Re: Identify Common Purpose - resolving issues

I've created a branch to propose Andrew/Alastair/Jake's wording arranged
with bullets. I think it's much easier to parse, to help with Detlev's
concern... I'd like to see if the Hail Mary pass will address all comments.

http://rawgit.com/w3c/wcag21/1.3.4_autofill_david/guidelines/#identify-common-purpose



Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Wed, Jan 17, 2018 at 5:27 AM, David MacDonald <david100@sympatico.ca>
wrote:

> To try to address Detlev's concern of the cognitive load of the SC:
>
> The purpose of common interface components can be programmatically
> determined if the following are true:
>
>    - The content is implemented using technologies that support
>    identifying the expected purpose for interface components
>    - The Interface component has a purpose that maps to the [link]list of
>    common interface
>
>
>
> Nothing in the meaning has changed... I just put the conditions at the end
> in bullets to make it easier.
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613.235.4902 <(613)%20235-4902>
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> twitter.com/davidmacd
>
> GitHub <https://github.com/DavidMacDonald>
>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>
>
>
> *  Adapting the web to all users*
> *            Including those with disabilities*
>
> If you are not the intended recipient, please review our privacy policy
> <http://www.davidmacd.com/disclaimer.html>
>
> On Wed, Jan 17, 2018 at 5:18 AM, David MacDonald <david100@sympatico.ca>
> wrote:
>
>> ​Jake to address your concern, ​l
>> et's go back to "interface component" as in the current wording rather
>> than "element"
>>
>> “In content implemented using technologies with support for identifying
>> the expected meaning for interface components, for each element that has a
>> purpose that maps to any of the [link]list of common interface components,
>> the meaning of the element can be programmatically determined.”
>>
>>
>>
>> Cheers,
>> David MacDonald
>>
>>
>>
>> *Can**Adapt* *Solutions Inc.*
>>
>> Tel:  613.235.4902 <(613)%20235-4902>
>>
>> LinkedIn
>> <http://www.linkedin.com/in/davidmacdonald100>
>>
>> twitter.com/davidmacd
>>
>> GitHub <https://github.com/DavidMacDonald>
>>
>> www.Can-Adapt.com <http://www.can-adapt.com/>
>>
>>
>>
>> *  Adapting the web to all users*
>> *            Including those with disabilities*
>>
>> If you are not the intended recipient, please review our privacy policy
>> <http://www.davidmacd.com/disclaimer.html>
>>
>> On Wed, Jan 17, 2018 at 5:15 AM, David MacDonald <david100@sympatico.ca>
>> wrote:
>>
>>> HI Jake
>>>
>>> Your wording "common input fields" doesn't solve your most recent
>>> concern about wanting to make the normative text all for more than input
>>> fields... so the SC can expand in future versions.
>>>
>>> My concern with "types" is that  it will be confused with input types
>>> <input type="text" ...>
>>>
>>> Cheers,
>>> David MacDonald
>>>
>>>
>>>
>>> *Can**Adapt* *Solutions Inc.*
>>>
>>> Tel:  613.235.4902 <(613)%20235-4902>
>>>
>>> LinkedIn
>>> <http://www.linkedin.com/in/davidmacdonald100>
>>>
>>> twitter.com/davidmacd
>>>
>>> GitHub <https://github.com/DavidMacDonald>
>>>
>>> www.Can-Adapt.com <http://www.can-adapt.com/>
>>>
>>>
>>>
>>> *  Adapting the web to all users*
>>> *            Including those with disabilities*
>>>
>>> If you are not the intended recipient, please review our privacy policy
>>> <http://www.davidmacd.com/disclaimer.html>
>>>
>>> On Wed, Jan 17, 2018 at 5:01 AM, Abma, J.D. (Jake) <Jake.Abma@ing.nl>
>>> wrote:
>>>
>>>> @Alastair, in opposition to previous suggested text I see you're using
>>>> "elements" where I used "types".
>>>> Focusing on "elements" I'm wondering if we want the purpose of an
>>>> "element" to be known or do we want to hinge more to "types" which was part
>>>> of previous suggestions (more neutral also maybe?!)
>>>>
>>>> For reference here the two different ones:
>>>>
>>>> - “In content implemented using technologies with support for
>>>> identifying the expected meaning for elements, for each element that has a
>>>> purpose that maps to any of the [link]list of common input fields,  the
>>>> meaning of the element can be programmatically determined.”
>>>>
>>>> - “For the list of common input fields that are supported by the
>>>> technology for specifying the purpose of specific types, the purpose can be
>>>> programmatically determined.”
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Abma, J.D. (Jake)
>>>> Sent: woensdag 17 januari 2018 10:51
>>>> To: 'Alastair Campbell' <acampbell@nomensa.com>; Andrew Kirkpatrick <
>>>> akirkpat@adobe.com>; WCAG <w3c-wai-gl@w3.org>
>>>> Subject: RE: Identify Common Purpose - resolving issues
>>>>
>>>> “In content implemented using technologies with support for identifying
>>>> the expected meaning for elements, for each element that has a purpose that
>>>> maps to any of the [link]list of common input fields,  the meaning of the
>>>> element can be programmatically determined.”
>>>>
>>>> +1 looks identical to my recently suggested text :-)
>>>>
>>>> -----Original Message-----
>>>> From: Alastair Campbell [mailto:acampbell@nomensa.com]
>>>> Sent: woensdag 17 januari 2018 10:45
>>>> To: Abma, J.D. (Jake) <Jake.Abma@ing.nl>; Andrew Kirkpatrick <
>>>> akirkpat@adobe.com>; WCAG <w3c-wai-gl@w3.org>
>>>> Subject: Re: Identify Common Purpose - resolving issues
>>>>
>>>> Jake wrote:
>>>> > I see a limitation in “for each user-specific input field” if we want
>>>> to expand this SC to also apply to NON user-specific input fields (or even
>>>> links / buttons)
>>>>
>>>> If we have the list in WCAG, we can use the line at the top of the
>>>> appendix (there now) to indicate the user-aspect, we can remove it from the
>>>> SC text.
>>>>
>>>>
>>>> David wrote:
>>>> > ​Now if  we  ​want to address Jake's issue we could go with a
>>>> variation of his text
>>>> >
>>>> > “In content implemented using technologies with support for
>>>> identifying the expected meaning for elements, for each user-specific
>>>> element that has a purpose that maps to any of the [link]list of common
>>>> input fields,  the meaning of the element can be programmatically
>>>> determined.”
>>>>
>>>> I’d be happy with that, and combing those points would leave:
>>>>
>>>> “In content implemented using technologies with support for identifying
>>>> the expected meaning for elements, for each element that has a purpose that
>>>> maps to any of the [link]list of common input fields,  the meaning of the
>>>> element can be programmatically determined.”
>>>> (Removing user-specific)
>>>>
>>>> Cheers,
>>>>
>>>> -Alastair
>>>>
>>>>
>>>> -----------------------------------------------------------------
>>>> ATTENTION:
>>>> The information in this e-mail is confidential and only meant for the
>>>> intended recipient. If you are not the intended recipient, don't use or
>>>> disclose it in any way. Please let the sender know and delete the message
>>>> immediately.
>>>> -----------------------------------------------------------------
>>>>
>>>> -----------------------------------------------------------------
>>>> ATTENTION:
>>>> The information in this e-mail is confidential and only meant for the
>>>> intended recipient. If you are not the intended recipient, don't use or
>>>> disclose it in any way. Please let the sender know and delete the message
>>>> immediately.
>>>> -----------------------------------------------------------------
>>>>
>>>
>>>
>>
>