Re: Proposal for support personlization AA from John, Chris, Jan and myself

If there is no objection I will change the proposal with the word function

All the best

Lisa Seeman

LinkedIn, Twitter





---- On Thu, 20 Jul 2017 16:12:22 +0300 lisa.seeman<lisa.seeman@zoho.com> wrote ---- 

I think we may need a different word rather then purpose  because of the overlap with different SC.Role, purpose  and function are all synonyms in conversation but can have slightly different meanings is speck writing 




Can we use function in place of the word purpose ? I searched though WCAG 2.0 and I think it is more consistent with the usage. 


 This SC is about identifying the purpose in a machine understandable way to enable personalized content. In both this Sc and 3.2.4 it should be done consistently. The idea is to make conforming via a taxonomy the best way but allow other ways as well to give industry time to adjust. 

We may be able to merge it with other SC's later, so long as the easiest way to conform is via a machine understandable way

All the best

Lisa Seeman

LinkedIn, Twitter





---- On Thu, 20 Jul 2017 11:31:16 +0300 David MacDonald<david100@sympatico.ca> wrote ---- 

> I think the AA requirement very specifically doesn't achieve much, but the few things it does achieve are profound.  There were two key buzzwords from the call today as they relate to cognitive disabilities, "purpose" and "consistency". That some form of consistency is maintained in identifying the purpose of a control is important, even if in the current state of the web, this can't always be seen by the user without the help of some form of AT.


I don't think "consistency" is a new concept in 2.1. 


3.2.4 Consistent Identification: Components that have the same functionality within a set of Web pages are identified consistently. (Level AA) ​
​In this case "identification" is used instead of "purpose"​.  At the very least there is ​so much
 overlap, that they would probably have to be merged after August.




See the understanding to see the similarities further:
https://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-consistent-functionality.html



Combine that with the SC 


3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input. (Level A)
​
The understanding is here:
https://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-cues.html​


​These two together seem to cover off most of this new AA SC.


I think that we should work any existing requirements in the AA proposal into these two SCs. Surely Instructions and labels could provide the purpose of the user interface components at least in many situations.


I think the new SC should be ALL about a short list of COGA semantics and identification of situations where the ACCNAME, ACCDESCRIPTION, ROLE, VALUE, or STATE. are sufficient in providing the purpose, and leaving it for the plugins to figure out the purpose if it sees keywords in those buckets. The requirement might be that certain keywords are used in those buckets.


I personally think I have to spend some time with the COGA Personalization spec to better understand situations where the purpose can be **implicitly ** provided by the ACCNAME, ACCDESCRIPTION, ROLE, VALUE, or STATE, (to be discovered by the Plugins) and where it needs to be **explicitly provided** using COGA semantics (Also discovered by the plugins)


I think we could put this at AA with an "at risk" marker, that it may be moved to AAA or removed depending on developments with COGA, browsers and plugins over the next 6 months. At AAA there could be more requirements added.


I'd also like to talk with the IBM decision makers to understand their reasons for not proceeding with the COGA semantics. If it is that there is no WCAG requirement then we can provide that. But if it is because close investigation revealed problems with implementation, and execution etc., I think that is important to know.  


​

​




Cheers,
David MacDonald
 
CanAdapt Solutions Inc.
Tel:  613.235.4902
LinkedIn 

twitter.com/davidmacd
GitHub
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






 
On Wed, Jul 19, 2017 at 11:08 PM, Chris McMeeking <chris.mcmeeking@deque.com> wrote:
Alastair, I don't believe John's comment intended to say "No Accessible Name Cannot Be", but rather that it is one of many potential ways developers could use to satisfy this.


I think the AA requirement very specifically doesn't achieve much, but the few things it does achieve are profound.  There were two key buzzwords from the call today as they relate to cognitive disabilities, "purpose" and "consistency". That some form of consistency is maintained in identifying the purpose of a control is important, even if in the current state of the web, this can't always be seen by the user without the help of some form of AT.

The fact that the AA requirement does so without requiring a "taxonomy" is important, because there is no taxonomy. Dozens of taxonomies is not a taxonomy. This version of the requirement acknowledges that, and encourages I suppose "domains" to use their own consistent methods, WHATEVER those may be. For example, if a given domain were to always use title="Send Email" for send email buttons, a browser extension could be written to detect that and respond to it. But perhaps another site could use aria-label="Send Mail" for ALL of its send email controls. We could then do the same. Sure, this does not accomplish much, however, it starts developers thinking about purpose, and how to consistently communicate it and what that means exactly. 


Finally, there is a clear plan (as discussed on the call) that when the taxonomy is ready, that the AA requirement be removed completely, and the AAA requirement replace it at the AA level.  Forward thinking organizations that have done the AA level requirement correctly WOULD NOT have to modify their entire website one property at a time. Rather they could take advantage of this consistent identification they have been using as a result of the current AA requirement to write a srcipt that says:


forAll(alt="Go Home").apply(coga-purpose="home");  //My appologies for the pseudo code and butchering of "Coga" this is purely hypothetical example!!!


The fact that they could use this, to satisfy the now more strict AA standard is VERY important. The AA standard begins the process of developers thinking about the consistency of identifying purpose, and the ones that want to do it right will start working and helping develop and testing standards. With the AAA requirement waiting in the wings, more will see the value of being able to do this consistently across the entire web, EVEN IF perhaps the AA standard doesn't have immediate impact, it will drive the impact of the AAA requirement much more quickly than without it. With the proper techniques built around the two criteria together, we will minimize the short term economic impact on organizations, by giving them time to think about this consistency in a MUCH SIMPLER sandbox and yes admittedly, it is not as helpful as we may have hoped. But, the folks from the Coga task force on the call seemed quite happy with it.


Chris


On Wed, Jul 19, 2017 at 6:57 PM, Alastair Campbell <acampbell@nomensa.com> wrote:
   Hi John,
  
 I like the term “purpose” for this, but I’m confused as to why “consistently” and “across a set of web pages” have been added?
  
 If the point is to identify conventional controls across *websites*, each site having its own version is not desirable.
  
 The changes imply that it will be different on different sites, so how does a user agent know what to do with these programmatically determined controls? 
  
 In the same way that name/role/value needs ARIA to specify things beyond native semantics, there needs to be a central / standardised way of saying what the purpose is.
  
 I’m missing what it achieves at AA at the moment. 
  
 -Alastair 
  
  
  
  From: John Foliot [mailto:john.foliot@deque.com] 
     
 
   @(AA):
 In content implemented using markup languages, the purpose of conventional controls[1] can be consistently, programmatically determined across a set of web pages. 
 
    
 
 
   @(AAA):
 
 
   In content implemented using markup languages, the purpose of conventional controls[1] can be consistently, programmatically determined and modified across a set of web pages through the use of metadata or semantics.