Assigned to Jan McSorley - https://www.w3.org/WAI/GL/wiki/SC_Managers_Phase1

As a goal, I am all for supporting personalization. As noted here,

Technology holds the promise of being extremely flexible

But my concerns are also tied up in that same statement; "holding promise" is a difficult future vision to build a current SC upon. My perception is that authors have no existing standardized semantics to cover this that aren't already requirements for other SC. Until such semantics are developed and adopted, it's pretty tough to implement this, especially as a level A requirement.

My gut feeling on this is that in the near term personalization could comprise a series of techniques or methods that can be used to meet more targeted success criteria. That could mean working to create new Personalization scenarios under the Sufficient Techniques section of existing SC. For example, Timing Adjustable could have a new scenario "Where personalization is supported" that outlines what techniques can be used to support adjusting timing on a user preference basis.

Once the ecosystem better supports it (specification in place, adoption of personalization techniques by WCAG and UAAG) then I think we may approach a time when there could be value in a generic Support Personalization SC to catch failures. But we also might find that this need will be best expressed as one or more failure techniques which can be applied to any of those situations where personalization can be used to satisfy other SCs.

Mike we have semantics that are freely available at https://github.com/w3c/personalization-semantics/
we have an open implementation at https://github.com/ayelet-seeman/coga.personalisation
Both Pearson and IBM are saying they will be implementing it once it is in a working draft so by the time we get to CR we should have everything

https://w3c.github.io/personalization-semantics/

Hi Mike,

Thank you for your comment. This SC has been assigned to me to manage. It would be very helpful to learn from you what you think this still needs in order to be moved on to CR. Specifically, I was hoping that you could provide some additional details about the following statement you made: "My gut feeling on this is that in the near term personalization could comprise a series of techniques or methods that can be used to meet more targeted success criteria."

In the education industry and in assessment, personalization is becoming increasingly important and there is a need for the W3C to bring clarity and stability to how to implement this. As more and more instructional and assessment resources are moving to digital and online formats, there are design principles moving through schools and education publishing companies, such as Universal Design for Learning, that are falling short of the kinds of detail needed to truly provide for the personalization needs of students with disabilities. I believe we need to seriously consider how to effectively address the issue of personalization in the next working draft, so I would like to have more dialog about why you and others may think this SC could compromise techniques or methods of other SCs. Could you please provide an example so that I can better understand your concerns? Thanks again for your help!

Thanks!

I would like to have more dialog about why you and others may think this SC could compromise techniques or methods of other SCs. Could you please provide an example so that I can better understand your concerns?

Adoption of WAI-ARIA would be an example of what I'm discussion. There was no "Support ARIA" SC introduced. Instead, 21 ARIA success techniques have been written and incorporated into existing SCs. They were added to:

• Success Criterion 1.3.1 (Info and Relationships)
• Success Criterion 3.3.2 (Labels or Instructions)
• Success Criterion 3.3.3 (Error Suggestion)
• Success Criterion 4.1.2 (Name, Role, Value)
• Success Criterion 1.1.1 (Non-text Content)
• Success Criterion 2.4.4 (Link Purpose (In Context))
• Success Criterion 2.4.1 (Bypass Blocks)
• Success Criterion 3.3.1 (Error Identification)

That sounds like a good starting list for Personalization techniques in exisiting SCs. There are others, including some 2.1 candidates, which could take advantage of Personalization techniques.

WAI-ARIA 1.0 also serves as an example of adoption time lines. The first public draft came out in 2006. It went through two years of working drafts before a last call. Then another year of drafting before a second last call. I believe between these two last calls is when the first draft WCAG ARIA techniques and the first fledgling browser support appeared. It became a candidate recommendation in 2011, and a proposed recommendation three years after that. An eight year journey, with a progressive adoption of ARIA into browsers, techniques and ATs along the way.

I'd be curious why you don't feel such a model could be used for Personalization, which is likely facing a similar timeline.

A big difference between Name, Role, Value and what you are proposing is in the note for 4.1.2:

Note: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.

So Name, Role, Value is concerned with ensuring that authors who create custom widgets meet expected behaviour. If authors use HTML properly, there is no additional work.

As it reads now, Personalization would seem to require every author to use the author-settable properties and attributes in the draft COGA semanatics proposal or fail WCAG. That list at the moment includes about 2 dozen attributes, of which just a couple represent significant additional work. (Further, the list doesn't include Personalization outside the COGA realm that would support solutions for any number of other SCs, such as keyboard assignments, persistence/timing and location of tool tips and other non-persistent information, Audio Control, Pause-Stop-Hide, Abbreviations, etc.)

Focusing on techniques, which let authors choose to address various issues through a personalization solution, is a more easily adopted and incremental method. Contrast that with an implementation that seems to compel authors to begin adding Personalization to all pertinent content.

You would only add the ones that apply. Most have default values as well.

Thanks for that clarification. Can I get more details on that, please? The draft doc mentions a few defaults, but it's not exhaustive. I edited out my initial list of your attributes, but if we're going to tackle this, I think we need them, especially considering your demo site uses different ones:

• coga-simplification
• coga-action
• coga-destination
• coga-field
• coga-context
• coga-concept
• coga-numberfree
• coga-literal
• coga-feedback
• coga-explain
• coga-moreinfo
• coga-extrahelp
• coga-helptype
• coga-hidden
• coga-alternative
• coga-easylang
• coga-messageimportance
• coga-messagefrom
• coga-messagecontext
• coga-messagetime
• coga-distraction
• coga-trigger

On your demo page, I'm seeing endemic use of aria-importance (on pretty much all content) and common usage of aria-function. I'm not sure what aria-importance maps to on the above list. I'm assuming aria-function maps to coga-action?

If we are going to assess the impact of this SC, I think there needs to be a lot more clarity on what attributes have defaults (and I'm assuming therefore no authoring requirement) and what require effort and how much.

If it does not make it into WCAG then non of this happens and people will continue to be left out, as they are now.

There are a number of existing and proposed SCs that either specifically mention personalization or could obviously be achieved with it. ARIA was incorporated into WCAG without a specific SC requiring its use; why can't personalization make it in without being an SC? I continue to have concerns about including an SC that at the moment is extremely hard to quantify for effort or scope -- even the demo site you point to uses completely different attributes. It makes for a shaky case for successful adoption, particularly for a level A.

Mike, are you okay with this, or do you need Lisa to specify which attributes have defaults, including nonvalid, or are you comfortable taking her word that there will be sufficient defaults in the specification by the time it gets to working draft in a few months? If you want the defaults defined, we would prefer to make the edits in the specification. Please let me know if you have any additional thoughts or concerns related to this.

@jmcsorle, yes, I agree the edits should be in the spec.

are you comfortable taking her word that there will be sufficient defaults in the specification by the time it gets to working draft in a few months?

If the spec working draft does not contain sufficient information by the time WCAG 2.1 goes to draft in a month, I think it's going to be tough to get support on this as it is. That's obviously just my opinion. It would be nice to get some others weighing in on this SC, which may prove <span coga-literal="most people disagree with my opinion"> I'm out in left field! </span>

I realize I am likely viewed as adversarial in this thread, but my approach to all the candidates has been to put on my critical hat and figure out what could keep the idea from being adopted. If there are scope problems, they need to be fixed; if there are language problems, they need to be rewritten; if it isn't really an author responsibility, it needs to be reconsidered, etc.

My concern with Support Personalization is that it seems both overly ambitious for the current circumstances (lack of user agent and AT support, and immaturity of supporting materials) and overly constrained (from the perspective that personalization could contain a great deal more than just cognitive, and be used to successfully address a number of other significant existing issues).

Ironically, I just got off a call where I was arguing on the other side of a similar discussion (this one around keyboard usage) about how authoring practices need to be in place to justify the need to get UAAG and AT buy-in. So why don't I leave this one alone for now and wait and see what someone else offers?

maybe we should split this into two
at level A have a limited scope of critical features and a have the orignal one as AA
critical features and is already defined in # 39

the new sc would read:
Support personalization: Contextual information and author settable properties of regions and critical features and important information are programatically determinable so that personalization is available.

Where the number of steps in a process can be reduced, the user can control the trade off between function and simplification.

Exception: Information does not need to be exposed when there is not a standardized way of exposing it in the technology or the platform.

Notes are the same as the original

@lseeman I don't see a GH username for Jan here. Is there a PR ready for this one or do you need more time?

on the phone with mike G

mike and me discussed the following
the new sc would read:

1. Support personalization: Contextual information and author settable properties of regions, critical features and important information are programatically determinable so that personalization is available.

Exception: Information does not need to be exposed when there is not a standardized technique of exposing it in the technology or the platform.

note that critical features and important information and standardized technique are already defined terms at https://rawgit.com/w3c/coga/master/extension/index.html

we then have another sc (level A or AA)

Where the number of steps in a process can be reduced, and easily available mechanism exists to alow the user to control the trade off between function and simplification.

(techneques inlude marking things with aria-required, providing a less options button and using personlization etc)

at AAA we have
Support personalization (all content): Contextual information and author settable properties of regions and elements are programatically determinable so that personalization is available.

I see there are three separate success criteria here: Reduce the number of steps, provide contextual information, and provide customizable user preferences. This proposal is a little rough, but I would recommend:

1. Reduce Steps: Provide settings, shortcuts or other methods for return users so they can reduce the number of steps needed to perform a task. Example: A shopping cart that saves and pre-fills the address and credit card information.
2. Contextual Information: Provide explanatory text, simplified instructions, or descriptive images to improve clarity and provide multiple means of representation of a concept.
   Definition of Contextual Information is unclear whether it is needed or provided. Recommend: Contextual Information: Information necessary to the understanding of the text or term. (Beck, Isabel 2009 Robust Vocabulary Instruction)
3. Customizable User Preferences: Provide programmatically determinable semantics that allows the user (or their assistive technology) to make changes to their experience to meet their individual needs. This includes: number types (e.g. phone, dates, currency), interruptions (e.g. aria live regions), abbreviations, definitions or accordions with additional instructions or expanded information,

the following wording went to survey:
For pages that contains interactive controls or content that is not core, one of the following is true:

-a mechanism is available for personalization of content that removes non-core functionality and content, and enables the user to add symbols to interactive controls for core functionality, or
-core functionality and content, and contextual information for core functionality and content, is programmatically determined.

Note: the main issue was is "core" clear and testable

new wording that is hopefuly closer is:
For pages that contains interactive controls or with more then one regions, one of the following is true:

• a mechanism is available for personalization of content that enables the user to add symbols to interactive controls OR
• contextual information or context sensitive help is availible for regions, form elements, main navigation elements and interactive controls is programmatically determined

.

to discuss on the call today

the link to the simple demo is
https://rawgit.com/ayelet-seeman/coga.personalisation/demo/conactUs.html

Hi
The link to the simple demo is https://rawgit.com/ayelet-seeman/coga.personalisation/demo/conactUs.html

I am also forwarding the email from User1st who integrated it into their platform in about 3 hours. Note this was for old wording so it would need to be changed to conform to the current version.

all the best
Lisa

---- On Mon, 26 Jun 2017 09:49:10 +0300 Amihai Mironamihai@user1st.com wrote ----
Hey Lisa,
A. Enables the user to add symbols to interactive controls for core functionality:

A. Go to :http://www.imss.gob.mx/transparencia/normatividad-fp
B. Select "asistencia" (help) profile
C. an ICON will appears near each download link (this is a customized icon, that a user could have created)

Inline image 1

Please find the script to make this function work:
Script:
var image = "image url for download";
if($("._u1st_uniqueDownloadHelp").length &lt; $(".glyphicon-download-alt").length)
{
$(".glyphicon-download-alt").after($("")
.setAttr("src", image)
.css("margin-left","10px")
.css("width","50px")
.addClass("_u1st_uniqueDownloadHelp")
.setAttr("alt", "download")
);
}
(Note: The image base 64)

B: a mechanism is available for personalization of content that removes non-core functionality and content:

Hide specific section in help profile

A. Go to http://www.imss.gob.mx/
B. Select "asistencia" (help) profile
C. The section on the bottom will disapear

Script:
$(".pane-v-imss-numeros").closest(".inside.panels-flexible-row-inside.panels-flexible-row-2-2-inside").hide();

תמונה מוטבעת 1

Summary - The entire process of creating such a script takes 15-60 minutes including testing.
Please let me know if that works for you.

Thank you,
Amihai

On Sun, Jun 25, 2017 at 3:59 PM, lisa.seeman lisa.seeman@zoho.com wrote:
Hi

On Tuesday the WCAG group will debate a proposal for personlization for wcag 2.1. We will have a week and a half to get it though.

the proposal is:

For pages that contains interactive controls or content that is not core, one of the following is true:

a mechanism is available for personalization of content that removes non-core functionality and content, and enables the user to add symbols to interactive controls for core functionality, or
core functionality and content, and contextual information for essential functionality and content, is programmatically determined.

The proposal is at #6

Core is defined as:
the mimimum functionality and content that is needed for users to identify the topic and fulfill the purpose of the content

For example, core content is generally identified by the page title. Core functionality is that which is needed to fulfill the purpose described by the page title

contextual information is currently defined as :
semantics and tags that give meaning to the content such as context of elements; concept and role; relevance and information for simplification; position in a process

Supporting semantics is proposed at https://w3c.github.io/personalization-semantics/

We need an example to show it as doable / useful including approximations how long it would take for authors to add the semantics.

Thanks for all your help
All the best

Lisa Seeman

LinkedIn, Twitter

--

Amihai Miron
CEO User1st

All the best

Lisa Seeman

LinkedIn, Twitter

When considering the software developmental implications of a Success Criterion like this, my thoughts are not, how does this demo that you created work? Or, how were 30 (or 1000) companies able to incorporate this open source project. My thought goes to, how is every website in the world going to do this, on every platform, for every device.

You have shown how thirty websites can implement this. How about a million?

You have a Chrome Extension. What about mobile?

I am browsing the Android Open Source Project Source Code (which includes the Chrome WebView implementation) and I can't find a reference to ANY Coga attributes. This does not bode well for general support for techniques around these properties on Android. I don't have the iOS source code, but I promise the support there is scant as well. This line of thinking leads me to the following two conclusions:

1: Push this out into a pre-mature ecosystem, allowing developers to come up with their own solutions on a website per website basis. Certainly some open source solutions for this would emerge as leaders, but across the broad spectrum of websites and devices there would be MANY MANY different approaches to this. From the point of view of a user, they would be unlikely to run into the same solution for this frequently in their day to day web browsing.

2: Hold off until the ecosystem matures, allow the Coga Specification to stabilize, perhaps consider UAAG guidelines around these thoughts, so that the Success Criterion leads developers to providing contextual information via coga attributes. Browsers then supply the actual customization automatically. Internally, this would be done via javascript injection, but it would be done so with a User Interface that is determined by the Browser, NOT independently, by every website in the world. The benefits of this approach from a user perspective are obvious and significant.

My concern is that, in conclusion 1, what have we really accomplished? Does a world of websites full of widely fractured personalization solutions really achieve the bigger goals of this Success Criterion? In the real world of millions of websites where EVERY site could potentially implement this differently, have we really helped users with cognitive disabilities or have we just required developers to do extra work for nothing?

In conclusion 2 we have embraced the power of a standard and used it to create a much better user experience. It just takes a little longer.

I, personally, would prefer the course of action that slowly leads to the ideal solution, over instant gratification with so many unanswered questions.

@chriscm2006 Chris - you have joined the conversation late. We have addressed the issue of does it support all platfroms by giving an option to conform of the first bullet point. we have a chicken and egg situation here and we need some type of requirment

@lseeman, I don't think comments about joining "late" are pertinent. We should anticipate (and encourage) additional people getting engaged as more information is added to 2.1.

@chriscm2006 is providing a similar perspective to concerns that have been raised since January. I don't see the crux of his argument being invalidated by the prescriptive first bullet point.

By the way, the second bullet point ends with "is programmatically determined", which doesn't tie in with the information before it. I'm not sure if you mean that everything needs to be determinable or if this phrase is only referring to the interactive controls. Either way, it needs to be rewritten. Is this what you mean?

contextual information or context sensitive help is programmatically determinable and available for regions, form elements, main navigation elements and interactive controls

@mbgower we have tried to adress these issues with the new wording and it's itteerations on the list

The first bullet can gives a loop whole in some cases and can be more work then the second bullet in other cases - but it serves two purposes. Firstly it means there is no requirement to add more semantics. The last time this issue was discussed some members felt strongly that we can not expect people to add semantics reliably. So if you can not do it, you can copy and paist a script or have an alternative version. Secondly, every platform will support it. So overall, between the two bullet points it is possible for everyone to conform - even if it is easier to do so in html/xml based languages. Thirdly, even though we have found other supporting techniques, it is easier to do the second bullet point using the coga -semantics. However people are uncomfortable depending on it. SO the first bullet point clarifies to everyone that there is no dependency on coga semantics to conform to the SC.

But in a summary, the point here is to get something in here, and build it up more in the supplement. We are trying to be innovative how we can get something in here on this issue. I am happy to here other directions that address all the comments.

the current wording on the list is
For pages that contains interactive controls or with more then one regions, one of the following is true:

-a mechanism is available for personalization of content that enables the user to add symbols to interactive controls OR
-contextual information is available for regions, common form elements, common navigation elements and common interactive controls is programmatically determined.

We would then specify what is included in common form elements, common navigation elements and common interactive controls in the definitions and make sure we have good supporting techniques for each one. I see the definition of common elements listing some of the values of coga-action, coga-field and coga-destination, so it should be very well defined what you need to include.

"We need some type of requirement." I would like you to consider rephrasing that: "We need to do something to help." Saying we "Need some type of requirement" precludes the possibility of an even better solution and assumes that this requirement will help and not hurt.

I read through the conversations above, my comments involve a unique point of view and additional concerns that were not addressed, particularly pertaining to the following statements:

If a user can identify and utilize the multitude (seriously, thousands) of personalization solutions that would appear as a result of bullet point 1, then such a user is not in the target group of users this Success Criterion is attempting to serve.

General support for bullet point 2 (contextual information through meta-data) is low enough, such that the inclusion of bullet point one guarantees that bullet point one will be the method programmers use to fulfill this success criterion an OVERWHELMING majority of the time.

This leads me to the following conclusion: Including this success criterion pre-maturely will not drive the industry toward the a solution that is going to serve the users needs. In fact, the inclusion of bullet point 1 ensures that this would NOT be the case.

We have a parallel conversation going on, I made some similar points here:
https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JulSep/0011.html

However people are uncomfortable depending on it [the meta-data]. SO the first bullet point clarifies to everyone that there is no dependency on coga semantics to conform to the SC.

The problem is that without coga-personalisation, there is no agreed scope for either bullet. I.e. there is nothing to say which controls should have icons. That means there is no testability. You’d either have to specify them in the SC (a terrible idea) or have an external reference.

But in a summary, the point here is to get something in here, and build it up more in the supplement.

I agree, I have the same goal in mind but I’m trying to steer towards an approach that has worked before in the WCAG/W3C context.

Starting with a core of the most useful meta-data which is the most straightforward to apply would be that first step.

Even with that approach, without some known external technology (user agent) to do something with the meta-data means it will be a struggle. (You didn’t answer that point.)

Hi, We have tried to address this in the new version. please let me know if it is now suffiently scoped

ADDED NOTE: This link is an error (wrote while somone was asking me to find it in a call - see EA's answere bellow) @https://openassistive.github.io/OATSoft/2016/06/21/WWAACWebBrowser/ is a symbol browser\

using their concpt codes is a supporting technique

Ok, I think it helps to have consistency through it, I think we can cut down the verbosity though:

Common navigation elements, form elements and interactive controls can be personalised by:

• a mechanism that enables the user to add symbols OR
• contextual information that can be programmatically determined.

Also, I followed the link, it goes to a dating site (once you click through to download or for the browser itself).

Both in the case of WWAAC http://acecentre.org.uk/wwaac but now days it is possible to have a plug in that works with a text editor such as TinyMCE linked to a database of symbols so it works in the same way as a word processor, rather like language translation. See Widgit 'Insite' and the technology behind it - demo provides a separate edit box that creates the symbol supported sentence https://www.widgit.com/products/insite/tinymce/edit.php Widgit have 'Point' as well that allows symbols to appear with hover and kindly provide a technical support page. https://www.widgit.com/support/insite/index.htm

Thanks EA.

another techneque from John http://microformats.org/wiki/h-event

huge thread on wcag. with Chris John and myself and jan we have new wording.
In content implemented using markup languages, the purpose of conventional controls can be consistently, programmatically determined across a set of web pages. (AA)

With new thread on wcag I am changing purpose to function, but we may yet need some more wordsmithing

Another thing I might add to this good list is the default button. Sometimes it’s not clear what the default button is in a form. Often the default button will be triggered by pressing enter – but knowing the default button could also be helpful for people who want to accept the default choice because they are not sure. This might go beyond buttons to other choices as well.

Also we need to harmonize with https://www.w3.org/TR/html5/forms.html#attr-fe-autocomplete and aria epub module.
Both can be ways to conform

@lseeman there are broken links in the initial comment description. Can you fix the 404's?

I'm also trying to get to the comment description links, @lseeman. I'm new to submitting comments. Do we need to create a new issue for recommended changes to the September 12 draft or is it fine to add them here?

@KristinaEngland Please create a new issue for comments on the September 12 draft.