Re: Extension conflict/compatibility requirement

can someone help me here?
Which extensions are we talking about that would conflict?
and how would they conflict?   (or are we talking hypothetical) 
only SC can conflict - and we have never seen this in the past.   
techniques never conflict per se because they are all optional and can be used where they apply
(but I’m having a hard time thinking of conflicting techniques too - that are not alternatives) 



Also - we were talking about levels - but last time I reviewed all of this - we seemed to have lots of guidelines and techniques but I only saw one thing that looked like it could be a success criterion. 

Which SC do we actually have?
 (testable criteria that would apply to all types of content that are not specifically scoped out) 





Thanks much. 

gregg

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




> On Oct 19, 2015, at 7:12 AM, Laura Carlson <laura.lee.carlson@gmail.com> wrote:
> 
> 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- minutes.html
> [2] http://gpii.net/
> 
> 
> On 10/16/15, Joshue O Connor <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
>> [2] https://www.w3.org/WAI/GL/wiki/WCAG_Extensions_Framework
> 
> -- 
> Laura L. Carlson