Re: Extension conflict/compatibility requirement

Hi Mike,

Your thoughts (1 and 2) on the results of being prescriptive are right
on target. Thank you very much for your great articulation. As Gregg
pointed out only SC can conflict. Techniques never conflict as they
are all optional. No one has yet brought forth an example of a SC
conflict between extensions. Wayne brought up 1.4.3 but that was in
relation to WGAG 2.0 core, which our new charter already addresses.

Changing the "MUST" to a "SHOULD" and then qualifying the "SHOULD"
requirement in the framework document by adding "whenever possible" is
pretty wishy-washy. It seems to almost reduce it to a "MAY." Such
ambiguous language in a framework nullifies. I would suggest TFs try
VERY hard not to produce conflicts. But it is realistic to recognize a
possibility exists for conflicts.

So using definitions in accordance with RFC 2119 [1], could anyone not
live with changing:

"Extensions must not conflict with each other."

to

"Extensions should not conflict with each other."

In IETF Terms:

MUST NOT = "absolute requirement"
SHOULD NOT = "there may exist valid reasons in particular
circumstances to ignore a particular item, but the full implications
must be understood and carefully weighed before choosing a different
course."
MAY = "an item is truly optional."
[1] https://www.ietf.org/rfc/rfc2119.txt

Thanks.

Kindest Regards,
Laura

On 10/21/15, Mike Elledge <melledge@yahoo.com> wrote:
> I think we have a conundrum, unless we qualify the requirement. That is
> because:
>
> 1) As soon as we are prescriptive there will be conflicts because different
> users have different needs (as Wayne has pointed out wrt contrast. I never
> would have realized 1.4.3 would be an issue for some users; thank you Wayne
> for the insight); and
>
> 2) The more prescriptive we can be the more helpful we will be to designers,
> developers and evaluators who have to apply the criteria.
> Also, although we can (fingers crossed) anticipate increased flexibility in
> website presentation, it is not true today.
>
> What to do?
>
> It seems to me that we can either add some wiggle room by 1) saying,
> "whenever possible" extensions should not conflict with one another, and
> when they do, describe why, and if possible, how best to proceed, or 2)
> remove the sentence entirely because there will inevitably be conflicts.
> Mike
>
>
>
>      On Wednesday, October 21, 2015 9:50 AM, Laura Carlson
> <laura.lee.carlson@gmail.com> wrote:
>
>
>  Hi Lisa,
>
> Ah. Thank you very much for the clarification.
>
> Can you perhaps give an example of a SC conflict between extensions
> based on your definition?
>
> And suggest example language for the compatibility section that you
> could live with?
> https://www.w3.org/WAI/GL/wiki/WCAG_Extensions_Framework#Ensure_that_all_WCAG_extensions_are_compatible_with_each_other
>
> Thank you.
>
> Kindest Regards,
> Laura
>
> On 10/21/15, lisa.seeman <lisa.seeman@zoho.com> wrote:
>> &gt;But we diverge from the main topic of the thread: "Extension
>> conflict/compatibility requirement"
>>
>> Not really. If we are basing the discussion (as per Wayne's email) on our
>> definition of accessibility, then we would need to agree on that
>> definition.
>> (With my definition user conflicts are inevitable. ) I am not saying we
>> should agree on the definition, but we definitely should not be deciding
>> these issues based on a definition that does not have consensuses, or is
>> only part of the picture.
>
>> All the best
>> Lisa

-- 
Laura L. Carlson

Received on Thursday, 22 October 2015 11:36:18 UTC