Re: Extension conflict/compatibility requirement

Hi Gregg,

Now that's another perspective that we haven't thought of. Thank you!

So far we have 3 Task Forces working on extensions. I am a member of
the Low Vision TF and know that we have not yet written any SC. I
don't know if other TFs have written any SC. Perhaps members of the
Mobile and Cognitive TFs can let us know.

Do you think the group should halt work on the Framework document [1]
all together?

[1] https://www.w3.org/WAI/GL/wiki/WCAG_Extensions_Framework

Kindest Regards,
Laura
"A good principle, not rightly understood, may prove as hurtful as a
bad." Milton.

On 10/21/15, Gregg Vanderheiden <gregg@raisingthefloor.org> wrote:
> 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
>
>


-- 
Laura L. Carlson

Received on Thursday, 22 October 2015 11:45:57 UTC