Re: Extension conflict/compatibility requirement

I think towards the end of the extension process, we should try to
integrate and harmonize them all into one. This may include personalization
settings in some specs etc..  but I think eventually we want to come up
with one extension and we won't have to worry about jurisdictions choosing
between one user group or another... However, this would happen at the end
(although throughout we would communicate to avoid conflicts at the end).

http://davidmacd.com/blog/WCAG-extension-proposed-integration-into-WCAG.html


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 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
>
>
>