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

Hi all,

Re: Option 2 @ AA - please see Issue #305
<https://github.com/w3c/wcag21/issues/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 <https://www.w3.org/TR/wai-aria/roles>, 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
>    <https://rawgit.com/w3c/wcag21/support-personalization_ISSUE-6/guidelines/#dfn-common-form-elements>
>    , common navigation elements
>    <https://rawgit.com/w3c/wcag21/support-personalization_ISSUE-6/guidelines/#dfn-common-navigation-elements>
>     and common interactive controls
>    <https://rawgit.com/w3c/wcag21/support-personalization_ISSUE-6/guidelines/#dfn-common-interactive-controls>
>     OR
>    - contextual information
>    <https://rawgit.com/w3c/wcag21/support-personalization_ISSUE-6/guidelines/#dfn-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 <http://il.linkedin.com/in/lisaseeman/>, Twitter
> <https://twitter.com/SeemanLisa>
>
>
>


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

Advancing the mission of digital accessibility and inclusion