Re: Subgroups proposal for support personlization and important request from coga

Hi John

In my email I explicitly wrote that we could remove importance for simplification from the definition. We are agreed on that (Although I did add in the github issue a way to to this using IMS) 

To be honest, I still do not understand the second part of your email, but I would be with your proposal of an 'easier' AA, and the more robust AAA which includes using metadata. 



All the best

Lisa Seeman

LinkedIn, Twitter





---- On Mon, 17 Jul 2017 23:33:10 +0300 John Foliot<john.foliot@deque.com> wrote ---- 

 > Hi all,
 > 
 > 
 > Re: Option 2 @ AA - please see Issue #305
 > 
 > 
 > contextual information
 > Proposed
 > The concept; role; importance for simplification; information that clarifies the meaning; relationships
 > to other elements; position in a process; process of which this element is a part.
 > 
 > 
 > 
 > 
 > How does a content author provide "...importance for simplification..." outside of using coga-semantics? 
 > Is there any other means of doing this today?
 > How is "importance" measured? 
 > By whom? 
 > How do we test for this today? 
 > How do we verify accuracy? 
 > This seems to me to be something of a back-door attempt to require coga-semantics, despite the fact that the coga-semantics draft spec is not complete.
 > 
 > 
 > 
 > Q: if the definition of contextual information was edited to remove the 'requirement' of "...importance for simplification...", and instead only read:
 > 
 > 
 > contextual information
 > 
 > The concept; role; importance for simplification; information that clarifies the meaning; relationships
 >  to other elements; position in a process; process of which this element is a part.
 > 
 > 
 > 
 > 
 > ... would COGA still be happy with the AA proposal as now being presented? 
 > 
 > 
 > That would then allow for the following:
 > 
 > ​​
 > concept; (can be a random text string, any language​: <form title="Create your user account">​
 > )
 > 
 > 
 > ​​
 > role; (can be determined from ARIA, or document native semantics)
 > 
 > 
 > ​​
 > information that clarifies the meaning; (can be a random text string, any language​. This potentially could be provided as a "help" icon or similar and conveyed as prose in a modal dialog, etc.​
 > )
 > 
 > 
 > ​​
 > relationships to other elements; (can be a random text string, any language​; native semantics could also factor here. For example, Screen Readers today announce lists and how many bullet points [sic] are in the list when voicing, because all of the <li>s are contained within a parent <ul> or <ol>, (so we get announced "bullet, one of four"
 > ) 
 > 
 > 
 > ​​
 > position in a process; (can be a random text string, any language​, and could include "breadcrumb" style navigation, especially in multi-step forms​
 > )
 > 
 > 
 > ​​
 > process of which this element is a part. (can be a random text string, any language​; can be provided as on-screen text: 
 > 
 >      <h3 id="education">Information About Your Previous Education​
 > </h3>​... 
 >            <form aria-describedby="education"> 
 > 
 > ...where on-screen proximity and aria-describedby both provide the required information as on-screen text, and the aria-describedby providing the programmatic linkage)
 > 
 > I
 > f the COGA TF finds this all agreeable, then I could certainly back making this an AA proposed SC.
 > 
 > 
 > 
 > 
 > ***************
 > 
 > 
 > 
 > 
 > If however you believe that "no, that isn't good enough", then why / why not? 
 > 
 > 
 > 
 > 
 > I will continue to assert that it is because without a fixed taxonomy you get contextual information, but presented to the end user in prose, which is hard to then transform (personalize). 
 > 
 > 
 > 
 > 
 > That's why a couple of us have suggested a more stringent AAA "Must use metadata" approach, which will certainly be slower to see take-up, but certainly more robust when delivered upon, as the taxonomical terms can then be mapped to machines & software applications, machine-learning, and machine-testing.
 > 
 > 
 > 
 > 
 > But to get there, we have to crawl before we sprint (never mind marathon racing...)
 > 
 > 
 > 
 > 
 > ***************
 > 
 > 
 > 
 > 
 > 
 > Idea:
 > 
 > 
 > 
 > 
 > Instead of making this an either/or, could we instead have both? A significantly 'easier' AA, and the more robust AAA which includes using metadata?
 > 
 > 
 > 
 > 
 > FWIW, I would stand behind that idea too.
 > 
 > 
 > 
 > 
 > JF
 > 
 > 
 > 
 > 
 > On Mon, Jul 17, 2017 at 1:08 PM, lisa.seeman <lisa.seeman@zoho.com> wrote:
 > Hi Folks
 > 
 > Here is the draft email for wcag. Let me know if there are any issues with it. I will need to send it tomorrow morning.
 > 
 > 
 > 
 > 
 > ---
 > Hi WCAG
 > 
 > A subgroup from last weeks Thursday's call (Andrew Mike, Chris and John ) have proposed alternative SC for support personlization. 
 > The most important difference is they have downgraded it to AAA from AA.
 > 
 > 
 > The COGA task force are torn. On the one hand without this SC many people can not use most web content at all - that should make it level AA or level A. On the other hand, AAA is a better then nothing. 
 > 
 > 
 > The resolution from COGA's end is to ask WCAG if there is a way we can make a personlization AA SC, which encourages marking the context of some elements.  We would prefer requiring less at AA, even having loopholes at AA, then a requiring more but at  AAA. However if there is no way forward at AA we will go with the new proposal. (Ways to move forward could include: further  limit the scope; remove  level of importance for page comprehension; and use and add exceptions or anything else for that matter...)
 > 
 > 
 >  All the other changes in the proposal are  fine from  COGA's perspectives if WCAG prefers them. (Other differences between the proposals include: the new proposal has a broader scope  and; the new proposal  has an exception where the technologies being used do not support personalization metadata. The problem with this is something can conform and then not conform as technologies change. So in the old wording we had give people a different way to conform in case metadata is not supported.)
 > 
 > 
 > Please could you read the alternative wording bellow and let us know if, in your opinion, there is any way forward at AA. 
 > 
 > 
 > 
 > 
 > Option 1  (New AAA proposal)
 >   Personalization Metadata (AAA)
 > For pages that contain user interface components, personalization metadata is used to provide contextual information for content, except where the technologies being used do not support personalization metadata.
 > 
 > 
 >  
 > Contextual information (definition):
 > Information which provides additional meaning for an object, such as the object’s purpose, level of importance for page comprehension and use, position in a process, relationship to other objects and processes, etc.
 > 
 > 
 > 
 > 
 > Option 2 (the existing proposal - AA)
 > For pages that contain interactive controls, one of the following is true: 
 >     a mechanism is available for personalization of content that      enables the user to add symbols to common      form elements, common      navigation elements and common      interactive controls OR
 >   contextual      information is available for common form elements, common      navigation elements and common interactive controls is programmatically      available. 
 >   
 > 
 > 
 > 
 > -------------
 > For both case we will also want to: 
 > 
 >       Review existing SC for new techniques and/or add COGA-impacting examples to existing techniques to clarify the extent that existing semantics provide benefits to COGA users.
 >       Add clarifications to the Understanding document for existing SC,if that can help COGA SC to move to A or AA in the upcoming rounds of WCAG development.
 >       Develop the supplemental document
 > 
 >       
 > 
 > All the best
 > 
 > Lisa Seeman
 > 
 > LinkedIn, Twitter
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > -- 
 > John Foliot
 > 
 > 
 > Principal Accessibility Strategist
 > 
 > Deque Systems Inc.
 > 
 > john.foliot@deque.com
 > 
 > 
 > 
 > Advancing the mission of digital accessibility and inclusion
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 >  
 >  
 >

Received on Tuesday, 18 July 2017 14:05:38 UTC