Re: Extension conflict/compatibility requirement

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

Received on Monday, 19 October 2015 18:05:06 UTC