Re: Identify Common Purpose - resolving issues

I think Alastair & Co's move to make the language looser to allow more 
future stuff to hang on it is an important alteration. I believe it needs 
a "both the following are true" statement, to read "...determined when 
both the following are true:"

There are a couple of other things that I think need to be addressed:

the language in the preamble immediately after the heading 7 Common 
Purposes for User Interface Controls needs to be reworded, given we are 
providing keywords which must be used (as I understand from the latest 
round of exchanges).
we seem to have lost the wording that these items are user-specific. That 
has to be there, otherwise, we are right back in the situation of an 
author being forced to use the metadata for anything that meets the 
meaning, even where it is for a different entity's name, etc.

I still have some concerns with both the solutions being pushed here: 
either copying the 5.2 list into a normative list in WCAG or locking in a 
reference to the 5.2 version in HTML. In both situations, if the autofill 
information changes in HTML 5.3, particularly if a value is removed, what 
are authors to do? However, I get the arguments, and I can live with the 
assumption we'll 'fix it' in some way if/when that arises.

Michael Gower
IBM Accessibility
Research

1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com
voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034



From:   David MacDonald <david100@sympatico.ca>
To:     "Abma, J.D. (Jake)" <Jake.Abma@ing.nl>
Cc:     Alastair Campbell <acampbell@nomensa.com>, Andrew Kirkpatrick 
<akirkpat@adobe.com>, WCAG <w3c-wai-gl@w3.org>
Date:   2018-01-17 03:50 AM
Subject:        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
 
CanAdapt Solutions Inc.
Tel:  613.235.4902
LinkedIn 
twitter.com/davidmacd
GitHub
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

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
 
CanAdapt Solutions Inc.
Tel:  613.235.4902
LinkedIn 
twitter.com/davidmacd
GitHub
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

On Wed, Jan 17, 2018 at 5:18 AM, David MacDonald <david100@sympatico.ca> 
wrote:
​Jake to address your concern, ​let'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
 
CanAdapt Solutions Inc.
Tel:  613.235.4902
LinkedIn 
twitter.com/davidmacd
GitHub
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

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
 
CanAdapt Solutions Inc.
Tel:  613.235.4902
LinkedIn 
twitter.com/davidmacd
GitHub
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

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.
-----------------------------------------------------------------

Received on Wednesday, 17 January 2018 15:30:44 UTC