- From: Gregg Vanderheiden <gregg@raisingthefloor.org>
- Date: Wed, 21 Oct 2015 21:15:02 -0500
- To: Laura Carlson <laura.lee.carlson@gmail.com>
- Cc: Joshue O Connor <josh@interaccess.ie>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>, "lisa.seeman" <lisa.seeman@zoho.com>
- Message-Id: <DEB33C4C-6640-4965-81C3-25B547BED0C9@raisingthefloor.org>
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
Received on Thursday, 22 October 2015 02:15:05 UTC