Re: Extension conflict/compatibility requirement

thanks laura

Hi all, 

I would suggest not wasting time on theoretical issues.   We have enough real ones…  grin

I wouldn’t worry about creating polices etc (like SC should not conflict with each other)  until we actually see a problem.    And even then, when we see one - we will probably just fix it without having to create policy on it.


I asked a couple times - but must have missed the answer.     Where is there  a list of the actual SC we have so far for any extensions?    I went though the docs and there were lots of places where there was a title that said Success criteria X  but then there was no SC below it.  Just general advice or techniques. 

How many do we have?   

thanks 


gregg

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




> On Oct 19, 2015, at 1:04 PM, Laura Carlson <laura.lee.carlson@gmail.com> wrote:
> 
> Hi Gregg,
> 
> At this point I believe we are talking about hypothetical conflicts.
> 
> Josh created a WCAG Extensions Framework document.
> https://www.w3.org/WAI/GL/wiki/WCAG_Extensions_Framework
> 
> We are working on language for the compatibility section.
> https://www.w3.org/WAI/GL/wiki/WCAG_Extensions_Framework#Ensure_that_all_WCAG_extensions_are_compatible_with_each_other
> 
> Your thoughts? Maybe change "Extensions must not conflict with each
> other. " to "SC must not conflict with each other. "
> 
> Thank you very much.
> 
> Kindest Regards,
> Laura
> 
> On 10/19/15, Gregg Vanderheiden <gregg@raisingthefloor.org> wrote:
>> 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
> 
> -- 
> Laura L. Carlson