- From: Laura Carlson <laura.lee.carlson@gmail.com>
- Date: Mon, 19 Oct 2015 13:04:38 -0500
- To: Gregg Vanderheiden <gregg@raisingthefloor.org>
- Cc: Joshue O Connor <josh@interaccess.ie>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>, "lisa.seeman" <lisa.seeman@zoho.com>
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 Monday, 19 October 2015 18:05:06 UTC