- From: Gregg Vanderheiden <gregg@raisingthefloor.org>
- Date: Mon, 19 Oct 2015 12:46:35 -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: <F9E8EBD6-CEBC-41E8-ACED-DACF9ACB90E4@raisingthefloor.org>
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
Received on Monday, 19 October 2015 17:46:41 UTC