Re: Do SCs need to be testable?

> On Nov 6, 2015, at 8:18 PM, Michael Pluke <Mike.Pluke@castle-consult.com> wrote:
> 
> Hi Gregg
>  
> This certainly makes perfect sense to me.
>  
> I guess the challenge will be to get those who control the devices and services at each level to expose the settable features and the range of settings available in such a way that the Matchmaker can make sense of them.

That is what the Unified Listing  and its Solutions Registry do.  They provide the MM with  all of the access features for each product/device/site.   Sites can also serve it dynamically
>  
> I fear that there may be two related challenges to achieving this:
>  
> -          Those who control the services/devices may fear that by exposing the details of how their services/devices can be configured they will be revealing more to their competitors than they may be comfortable with.

Not sure I follow.  If they don’t have a personalization api - it doesn’t matter — and if they do have one - then there would be a description or it wouldnt make sense to provide an API. 

> -          The (very privacy invasive) practice of a service building its own profile of a user enables them to deliver a highly personalized service offering.

This isn’t about the site building a profile.   They can do that independently or not.  

> This very personalised user experience is an increasingly large factor in what makes a service attractive to its users. Service providers may feel that ceding even a small part of this ability to personalize to a third party

If they don’t want their site to be as accessible — then yes  - there is nothing that can be done.  

> (whoever runs the Matchmaker) diminishes their competitive advantage over rival services.

Not sure how that would be true.  I would think it would make their site MORE competitive since it would auto-personalize.     Having the MM work with their competitors site and not theirs would seem to be what they would like to avoid.  No?  

>  
> Best regards
>  
> Mike
>  
>   <>
> From: Gregg Vanderheiden RTF [mailto:gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>] 
> Sent: 06 November 2015 21:40
> To: Michael Pluke <Mike.Pluke@castle-consult.com <mailto:Mike.Pluke@castle-consult.com>>
> Cc: Jim Allan <jimallan@tsbvi.edu <mailto:jimallan@tsbvi.edu>>; Joshue O Connor <josh@interaccess.ie <mailto:josh@interaccess.ie>>; GLWAI Guidelines WG org <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>>; public-cognitive-a11y-tf@w3.org <mailto:public-cognitive-a11y-tf@w3.org>
> Subject: Re: Do SCs need to be testable?
>  
> Hi Mike,
>  
>             I can see you understand the concept very well.
>  
>             RE privacy — each of the 5 layers has the same ability to capture information about the user.   But at each level - no information about the user is shared.    The Matchmaker (our software) takes the information from the preference server — and the information about the accessibility features (at each level) —  and figures out what the settings should be.  The only thing that the site sees are commands to turn on particular features on their site — and the setting for each.      This is information they would have no matter how you turn the features on —   so personalization doesn’t reveal anything that the user turning the features on by hand wouldn’t.     And unfortunately - there isnt any way to use a feature on a site without the site knowing that you used their feature. 
>  
>             make sense?  
>  
> Thanks
>  
> Gregg
>  
>  
> On Nov 5, 2015, at 5:15 PM, Michael Pluke <Mike.Pluke@castle-consult.com <mailto:Mike.Pluke@castle-consult.com>> wrote:
>  
> Hi
>  
> I like this approach a lot! I spent some years looking into personalization and proposed a distributed solution that allowed different forms of personalization to take place at the appropriate level, so this approach appears to me to be exactly on the right path.
>  
> In your mail you identify the fifth level as “the Targe”. I’m assuming that this was meant to be “the Target”. I’d like to check my assumption that when a person is interacting with a web service the Target would be the operation of the service itself?
>  
> If this is the case, then I believe that this level is substantially different to all the others in that it allows the service to read the user’s preferences and, on the basis of what it discovers, significantly modify the substance of the content that it delivers to an individual user. At all the other levels it is only possible to modify the way that the standard content is delivered without changing its substance (which will be the same for all users).
>  
> When thinking about the ways in which personalization could support persons with cognitive disabilities, it would surely be at “the Target” level that the most powerful solutions could be implemented. A very beneficial option would be to supply users who have a preference for simplified language with an alternate simplified version of the content - if the service developers have produced such an alternative version of their standard content and provided it as a personalization option.
>  
> Best regards
>  
> Mike
>  
> From: Gregg Vanderheiden RTF [mailto:gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>] 
> Sent: 05 November 2015 04:37
> To: Jim Allan <jimallan@tsbvi.edu <mailto:jimallan@tsbvi.edu>>
> Cc: Joshue O Connor <josh@interaccess.ie <mailto:josh@interaccess.ie>>; GLWAI Guidelines WG org <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>>
> Subject: Re: Do SCs need to be testable?
>  
> Hi 
>  
> In our GPII work, we have defined 5 levels at which accessibility personalization might occur.
>  
> 1.      OS/Platform
> 2.      AT installed on platform
> 3.      Browser
> 4.      Cloud Accessibility services
> 5.      the Targe 
>  
>  
> And there are cases or types of information / interface where the optimum location for the adaptation would be at a different level — or even times where different parts should occur at different levels.
>  
> Structural changes for example  (dividing a task into a different number of pages) is one example of something that would be very hard to do at the browser level or below.
>  
> with the GPII we are working on the ability to not only set preferences at all 5 levels — but to determine what is best to do at which level — and to remember what the user prefers to be done at what level.
>  
>  
> Gregg
>  
>  
>  
>  
>  
>  
> On Nov 4, 2015, at 3:01 PM, Jim Allan <jimallan@tsbvi.edu <mailto:jimallan@tsbvi.edu>> wrote:
>  
> Also, this does not need to fall solely on the author/content developer. The browser has a huge role to play in the "auto personalization" area. I don't want thousands of content developers writing thousands of interfaces to personalize their website. Much of the personalization must come from the browser.
> 
> Jim
>  
> On Tue, Nov 3, 2015 at 9:20 AM, josh@interaccess.ie <mailto:josh@interaccess.ie> <josh@interaccess.ie <mailto:josh@interaccess.ie>> wrote:
>  
>  
> 
>  On Oct 29, 2015, at 11:08 AM, Joshue O Connor <josh@interaccess.ie <mailto:josh@interaccess.ie>> wrote:
>  This brings up a question …  What are via alternatives to creating SCs? Without the SC approach, would it merely result a tranche of new techniques, or is there some other new or unused mechanism that might be an alternative?
> 
> 
> 
> I think the alternative would be to have guidelines and examples.
> 
> The guidelines do not need to be testable — but set a goal.
> 
> The examples show how it can be done.
> 
> The idea would be to go beyond what you can require   because requiring something means it must be testable and apply everywhere.  And there are so many good ideas that don’t match these two requirements and therefore don’t get recorded.
> 
> Also - trying to get more things required will get much push back from industry.   And for some reason they are very against things that relate to what they view as ‘usability’ - which is much or all of cognitive disability.     The are very much FOR it in design — but not for it being required.   The way to ride that — is to create a great manual on how to do it — but avoid making SC or requirements because    a) it will then be resisted and diminished   b) you will have to leave out — or diminish yourself -  so many good ideas because they can’t be SC and if you have a few SC and mostly not— the mostly not (which will most of the great stuff) will be second class citizens in your own document.
> 
> Very useful info, thanks Gregg
> 
> Josh
>  
> 
> 
> 
> Gregg
> 
> 
> 
> 
> 
>  On Oct 29, 2015, at 11:08 AM, Joshue O Connor <josh@interaccess.ie <mailto:josh@interaccess.ie>> wrote:
> 
>  Hi all,
> 
>  TTBOMK, any new success criterion must be testable. If not, it’s a clear departure from the original WCAG requirements framework. If we do need to depart from the framework (for whatever reason) – then we cannot call these new SCs success criteria. We’d need to come up with something else. I’m only making an objective statement here, and not making any value judgement.
> 
>  This brings up a question relating to one of Greggs comments (and thanks Gregg for your very helpful input). What are via alternatives to creating SCs? Without the SC approach, would it merely result a tranche of new techniques, or is there some other new or unused mechanism that might be an alternative?
> 
>  Thanks
> 
>  Josh
> 
> 
> 
> 
> 
>  
>  
> 
> 
> 
> 
> -- 
> Jim Allan, Accessibility Coordinator
> Texas School for the Blind and Visually Impaired
> 1100 W. 45th St., Austin, Texas 78756
> voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/ <http://www.tsbvi.edu/>
> "We shape our tools and thereafter our tools shape us." McLuhan, 1964
>