Re: Extension conflict/compatibility requirement

+1 to changes

Cheers,

David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn <http://www.linkedin.com/in/davidmacdonald100>

www.Can-Adapt.com



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Tue, Nov 10, 2015 at 10:12 AM, Andrew Kirkpatrick <akirkpat@adobe.com>
wrote:

> Group,
> We have a new version of the extension framework/requirements document
> with edits made as a result of discussion on last week’s call.
>
> The main changes can be seen in the diff version:
>
> https://www.w3.org/WAI/GL/wiki/index.php?title=WCAG_Extensions_Framework&diff=5872&oldid=5867
>
>
> Or you can view the new version only:
> https://www.w3.org/WAI/GL/wiki/WCAG_Extensions_Framework
>
> We will discuss this on the call today, but also on the list, so please
> take some time to review this and share comments as we would like to
> provide this for public review soon.
>
> Thanks,
> AWK
>
> Andrew Kirkpatrick
> Group Product Manager, Accessibility
> Adobe
>
> akirkpat@adobe.com
> http://twitter.com/awkawk
> http://blogs.adobe.com/accessibility
>
>
> On Fri, Oct 16, 2015 at 5:28 AM, 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
>>
>>
>>
>