Re: Do SCs need to be testable?

Hi 

In our GPII work, we have defined 5 levels at which accessibility personalization might occur.

OS/Platform
AT installed on platform
Browser
Cloud Accessibility services
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> 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