Re: Extension conflict/compatibility requirement

yes

in Cloud4all/GPII we define 5 layers of personalization

features/options built into platform (e.g. access features in OS)
installed features/options  (e.g. Assistive technologies installed on a computer)
user-agent features/options  (e.g. access features in browsers)
cloud based features/options  (e.g. cloud based AT) 
website based features/options  (e.g. features of the actual site) 

We are working in Cloud4all/GPII to create  "auto-personalization from preferences” (APfP) capability that can span all 5 layers - coordinating among them and allowing the user to determine which features at which levels work best in which situations. 



gregg

----------------------------------
Gregg Vanderheiden
gregg@raisingthefloor.org




> On Oct 19, 2015, at 10:57 AM, Michael Pluke <Mike.Pluke@castle-consult.com> wrote:
> 
> Yes, “user agent settings, assistive technologies, or through site controls/GPII preferences” was exactly the range of personalization options I had in mind. People may not immediately think of all of these options when considering personalization, but they are all valid if they deliver the desired effect.
>  
> I think that the rest of your message gives some very valuable warnings that we cannot rely on personalization always being available and that its existence is not an excuse for failing to deliver default solutions that meet as many non-conflicting accessibility requirements as possible.
>  
> Best regards
>  
> Mike
>   <>
> From: Jonathan Avila [mailto:jon.avila@ssbbartgroup.com] 
> Sent: 19 October 2015 16:50
> To: Michael Pluke <Mike.Pluke@castle-consult.com>; lisa.seeman <lisa.seeman@zoho.com>; Hoffman <allen.hoffman@hq.dhs.gov>
> Cc: Laura Carlson <laura.lee.carlson@gmail.com>; Joshue O Connor <josh@interaccess.ie>; WCAG <w3c-wai-gl@w3.org>; Gregg Vanderheiden <gregg@raisingthefloor.org>
> Subject: RE: Extension conflict/compatibility requirement
>  
> > How that personalization is delivered is not such an easy question to answer. In practice it is likely that there will never be just one way in which it can be achieved.
>  
> Yes, and this is the challenge as we have to find a common middle ground that is required but then also allow for adaptation in either direction.   The method of the adaption may be through user agent settings, assistive technologies, or through site controls/GPII preferences.
>  
> For example, under SC 1.4.8 there needs to be a mechanism to allow for line spacing to be set to 1.5 times.  This could be achieved by setting all content to line spacing of 1.5 the default size.  But this might be problematic for some users.  The user might be able to apply a custom style sheet to change this – but applying a custom style sheet might be difficult or impossible for some.  So site controls or user preferences (automated or not) are the best options.   However, do the challenges with user preferences and limitations such as mobile user agents authors may choose to adopt a one size fits all approach simply to meet the standards.
>  
> In regards to contrast – while contrast can be set via style sheets I’d continue to affirm that we need default contrast minimums because correctly setting sufficient foreground and background colors in stylesheets without blowing away visual affordances is very difficult or impossible IMO.  That is – I don’t want to be forced into losing the colors of a page just to get sufficient contrast – sites should continue to support minimum contrast while at the same time allowing for users to customize as needed.
>  
> Jonathan
>  
> -- 
> Jonathan Avila 
> Chief Accessibility Officer
> SSB BART Group 
> jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com>
> Phone 703.637.8957  
> Follow us: Facebook <http://www.facebook.com/#!/ssbbartgroup> | Twitter <http://twitter.com/#!/SSBBARTGroup> | LinkedIn <http://www.linkedin.com/company/355266?trk=tyah> | Blog <http://www.ssbbartgroup.com/blog> | Newsletter <http://eepurl.com/O5DP>
>  
> From: Michael Pluke [mailto:Mike.Pluke@castle-consult.com <mailto:Mike.Pluke@castle-consult.com>] 
> Sent: Monday, October 19, 2015 11:29 AM
> To: lisa.seeman; Hoffman
> Cc: Laura Carlson; Joshue O Connor; WCAG; Gregg Vanderheiden
> Subject: RE: Extension conflict/compatibility requirement
>  
> Hi All
>  
> I full agree with Lisa – personalization is the only way to resolve these conflicts.
>  
> How that personalization is delivered is not such an easy question to answer. In practice it is likely that there will never be just one way in which it can be achieved. Those working on GPII are doing great work to identify one, hopefully widely supported and available way to provide personalization. Other, narrower, ways of providing personalization already exist within various websites and services.
>  
> The main thing we can do at this stage is to identify where conflicts can exist and ensure that methods for delivering alternative solutions are defined. When and where personalization methods exist, these can then deliver the right solution to the right individual based on their needs and preferences.
>  
> Best regards
>  
> Mike
>  
> From: lisa.seeman [mailto:lisa.seeman@zoho.com <mailto:lisa.seeman@zoho.com>] 
> Sent: 19 October 2015 15:55
> To: Hoffman <allen.hoffman@hq.dhs.gov <mailto:allen.hoffman@hq.dhs.gov>>
> Cc: Laura Carlson <laura.lee.carlson@gmail.com <mailto:laura.lee.carlson@gmail.com>>; Joshue O Connor <josh@interaccess.ie <mailto:josh@interaccess.ie>>; WCAG <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>>; Gregg Vanderheiden <gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>>
> Subject: RE: Extension conflict/compatibility requirement
>  
> Hi All
> Without personlisation or allowing for alternative renderings for accessibility for cognitive will always be half baked and we will be  sacrificing the less vocal, but not less in need, groups  for the sake of the groups that have better representation.
>  
> I think any SC should be reachable via personlisation so long as the group in question has easy usable access to the personlization process. 
> 
> All the best
> Lisa Seeman
> Athena ICT Accessibility Projects  <http://accessibility.athena-ict.com/> <>LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter <https://twitter.com/SeemanLisa>
> 
> 
> 
> 
>  
> 
> ---- On Mon, 19 Oct 2015 17:08:56 +0300 Hoffman<allen.hoffman@hq.dhs.gov <mailto:allen.hoffman@hq.dhs.gov>> wrote ----
> See the raising the floor global initiative. 
> Personalization with optional features is certainly no problem, but should not be promoted as the standard baseline solution. For example, one solution I know of offers ability to show graphs and tablular data that graphs are generated from, however, keyboard access and use of color are not addressed. Options for use of shading/patterns in graphs and more conforming tables are there, but should not be used as extensions, but should be there in baseline with optional extensions to add even more functionality. 
> 
> 
> Allen Hoffman 
> Deputy Executive Director 
> The Office of Accessible Systems & Technology 
> Department of Homeland Security 
> 202-447-0503 (voice) 
> allen.hoffman@hq.dhs.gov <mailto:allen.hoffman@hq.dhs.gov> 
> 
> DHS Accessibility Helpdesk 
> 202-447-0440 (voice) 
> 202-447-0582 (fax) 
> 202-447-5857 (TTY) 
> accessibility@dhs.gov <mailto:accessibility@dhs.gov> 
>   
> This communication, along with any attachments, is covered by federal and state law governing electronic communications and may contain sensitive and legally privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, use or copying of this message is strictly prohibited.  If you have received this message in error, please reply immediately to the sender and delete this message.  Thank you. 
> 
> 
> -----Original Message----- 
> From: Laura Carlson [mailto:laura.lee.carlson@gmail.com <mailto:laura.lee.carlson@gmail.com>] 
> Sent: Monday, October 19, 2015 8:13 AM 
> To: Joshue O Connor 
> Cc: WCAG; Gregg Vanderheiden; Lisa Seeman 
> Subject: Re: Extension conflict/compatibility requirement 
> 
> Hi Josh and all, 
> 
> Kathy astutely pointed out in last week’s teleconference [1] that people with disabilities may have opposing needs. For example, high contrast isn't good for certain people with cognitive or learning disabilities. David perceptively talked about how developers will just throw up their hands if extensions conflict with each other. It was suggested that conforming alternatives could address most of the conflicts but James wisely said testing would be a nightmare. 
> 
> I agree with all of these observations. 
> 
> One size doesn't always fit all. However, to get extension acceptance and uptake from the individuals and organizations that implement and/or use WCAG such as Web designers and developers, policy makers, purchasing agents, teachers, and students, extension conflicts should not be allowed. Moreover, if conflicts are allowed between extensions, I suspect it will lead to turmoil in the accessibility community between the very user groups that the extensions are trying to help. 
> 
> So what can we do? Accessibility is essentially dealing with diversity. 
> 
> Josh, I wonder, what ways exist for technology to provide personalization and customization of content to deal with diversity of users needs while at the same time eliminating extension conflicts in order to get extension buy-in from the individuals and organizations that use WCAG? What schemes exist or can exist for technology to afford users a method to receive information in accordance to their needs and capabilities? 
> 
> GPII [2] is pioneering interoperable personalization schemes. Lisa and the Cognitive Task Force have been working on a proposal for an extension, where personalization is key. Could something such as these schemes help us avoid and eliminate conflicts? Is possible, say for in Kathy’s example, for users to receive whatever contrast they need via customization? Or is that wishful thinking? Perhaps Gregg V and Lisa could talk about feasibility. 
> 
> Kindest Regards, 
> Laura 
> 
> [1] http://www.w3.org/2015/10/13-wai-wcag- <http://www.w3.org/2015/10/13-wai-wcag-> minutes.html [2] http://gpii.net/ <http://gpii.net/> 
> 
> 
> On 10/16/15, Joshue O Connor <josh@interaccess.ie <mailto:josh@interaccess.ie>> wrote: 
> > Hi all, 
> > 
> > On the working group call this week there were a couple of interesting 
> > points raised regarding extensions that require further discussion. We 
> > also wish to engage other people on the list who were not on the call, 
> > and make sure that they are aware of some of the finer points and able 
> > to express an opinion here on the list. 
> > 
> > To sum up, two main 'themes' in our extension framework are extension 
> > compatibility, and the need to reduce, minimise or indeed remove any 
> > conflict between extensions. 
> > 
> > NOTE: As a thought experiment, one possible way to do that would be to 
> > have a 'MonoSpec' extension which combined the output from all TFs 
> > (Mobile/Cognitive/Low Vision) in a single spec. Potentially where care 
> > is taken to ensure that these extension SCs are fully compatible with 
> > each other there may be less 'conflict'. 
> > 
> > The 'PolySpec' extension approach would involve taking the SCs from 
> > each group and placing them in separate docs that conformance claims 
> > would be written against individually. 
> > 
> > While in principle, the contents of these docs would be more or less 
> > the same, the potential for conflict if there is only a 'MonoSpec' may 
> > be reduced. If only because a valid conformance claim would need to be 
> > written against it in toto. Also this approach would mean that devs 
> > would have to satisfy the success criteria in the MonoSpec fully, even 
> > if some are outside of the developers immediate area of interest. So 
> > in short could be a good way of conditioning developers to consider 
> > other user needs - rather than thinking "I need to make my content 
> > conform to just mobile, or low vision success criteria etc". 
> > 
> > Regarding extension conflict, in our current draft 'WCAG Extensions 
> > Framework' document it states: [2] 
> > 
> > "Ensure that all WCAG extensions are compatible with each other 
> > Extensions must not conflict with each other. This is important for 
> > the purpose of enabling content providers to implement support for 
> > more than one extension. For this reason will be critically important 
> > for group members working on different extensions to maintain good 
> > communication about extension work in progress." 
> > 
> > There are a couple of questions/points that arise: 
> > 
> > 1) Should we explicitly call out the need within the framework that 
> > there must NOT be conflict between extensions? It has been pointed out 
> > (rather practically) that it just may not be possible to avoid 
> > conflict with our extensions. 
> > 
> > 2) If we do explicitly call out this issue in our framework, it may 
> > help focus working group attention on carefully finding where there 
> > are conflicts in extensions (between there own group and others). 
> > 
> > 3) On a more granular level how do you think the framework should even 
> > define conflict? 
> > 
> > 4) Obviously while spec fragmentation is a concern inherent in the 
> > extensions discussion a final thought is the basic question; Is 
> > conflict always inherently bad? Can positive conflict or friction 
> > between various user requirements result in the end in better content, 
> > better user experience etc? 
> > 
> > What do you think? 
> > 
> > [1] http://www.w3.org/2015/10/13-wai-wcag-minutes.html <http://www.w3.org/2015/10/13-wai-wcag-minutes.html> 
> > [2] https://www.w3.org/WAI/GL/wiki/WCAG_Extensions_Framework <https://www.w3.org/WAI/GL/wiki/WCAG_Extensions_Framework> 
> 
> -- 
> Laura L. Carlson 
>