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

Hi Lisa,

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

Ok, I'll try again.

What I am suggesting is that at AA level,

   - the content author MUST provide some *extra information* about the
   specific element(s) in question
   (the navigational elements, the form controls, the interactive widgets),

   - but that loosely speaking, "what" they tell us as the *extra
   information* is random - it is prose text provided by the author, and
   how it is provided is limited only by the fact that it must be
*programmatically
   associated*.

(So, for example it can be in any language, and it does not map to any kind
of look-up list, which would then NOT afford the transformation from
text-to-symbol, for example.)


Then, at AAA, we add on the additional requirement that when providing
that *extra
information*,

   - that it ALSO follows a very specific pattern and uses a list of
   'terms' taken from a fixed list,

...so that for example you can now make the text-to-symbol transformation
possible, because the taxonomy of the metadata is such that it can be
machine-referenced (of which Coga Semantics is the front-runner today).

BUT we also leave the door open to other metadata lists/taxonomies if they
can show that they achieve the "transformation" bit, which is the real goal
of the proposed AAA SC.

So if Dublin Core or schema.org also have equivalent taxonomies, the SC
would state that the end author can use those as well. This would
potentially also speed adoption, because both Dublin Core and schema.org
(the two examples I constantly point to) are already in use today, and
there is an existing process for adding new taxonomy terms with both of
those schemas already.

Does that make better sense?

(I'm really trying to make this workable for all)

JF

On Tue, Jul 18, 2017 at 9:04 AM, lisa.seeman <lisa.seeman@zoho.com> wrote:

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


-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion