Re: Extension conflict/compatibility requirement

>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





---- On Wed, 21 Oct 2015 15:34:41 +0300 Laura Carlson<laura.lee.carlson@gmail.com> wrote ---- 


 
But we diverge from the main topic of the thread: "Extension 
conflict/compatibility requirement"

  
 
Kindest Regards, 
Laura 
 
On 10/21/15, lisa.seeman <lisa.seeman@zoho.com> wrote: 
> Hi 
> 
> I define accessibility as follows: When a user could theoretically, use 
> content, but can not because of the design and implementation choices of the 
> author, then that content is inaccessible for that user. 
> 
> 
> 
> 
> All the best 
> 
> Lisa Seeman 
> 
> Athena ICT Accessibility Projects 
> LinkedIn, Twitter 
> 
> 
> 
> 
> 
> ---- On Wed, 21 Oct 2015 14:36:20 +0300 Laura 
> Carlson<laura.lee.carlson@gmail.com> wrote ---- 
> 
> Hi Wayne, 
> 
> Thank you so very much for your thoughtful correspondence. Brilliant. 
> 
> SC 1.4.3 is already in WCAG 2.0 core. Per our charter, extensions "may 
> or may not redefine aspects of WCAG 2.0 within the context of the 
> extension." So the Low Vision Task Force may redefine 1.4.3 in order 
> to produce flexible content that works for people with low vision. 
> 
> The topic of this thread and that Josh wanted input on is conflicts 
> between extensions. As you said, "Creating an environment where 
> customization can occur is the goal for all accessibility. As such, 
> criteria that produce truly flexible content will never create cross 
> disability conflicts. We only run into conflicts when our criteria 
> specify particular accommodations instead of the flexibility to 
> produce them." 
> 
> So I don't see an issue with the current language in the compatibility 
> section if SC. 
> https://www.w3.org/WAI/GL/wiki/WCAG_Extensions_Framework#Ensure_that_all_WCAG_extensions_are_compatible_with_each_other 
> 
> 
> I wonder if it may be helpful to have some language in the document 
> regarding the goal of customization and that extension SCs should 
> produce flexible content so that Task Forces never create cross 
> disability conflicts. 
> 
> Thoughts? 
> 
> Thanks again. 
> 
> Best Regards, 
> Laura 
> 
> On 10/19/15, Wayne Dick <wayneedick@gmail.com> wrote: 
> > Josh, Laura, Micheal, Jon, ... WCAG, 
> > 
> > We seem to be missing a key point of accessibility. Accessibility 
> provides 
> > the ability to produce accommodations, not accommodations. SC 1.4.3 is 
> ill 
> > formed because it prescribes a specific accommodation, not the 
> flexibility 
> > to produce it. A person with light sensitivity would never choose high 
> 
> > contrast to improve legibility. Larger print would be preferable. 
> > 
> > Accommodations are by their nature incompatible. This is because 
> > accommodations are built to meet the special needs of minority 
> populations. 
> > I cannot read closed captions or Braille, but the ability to produce 
> these 
> > alternatives has no impact on me. 
> > 
> > Creating an environment where customization can occur is the goal for 
> all 
> > accessibility. As such, criteria that produce truly flexible content 
> will 
> > never create cross disability conflicts. We only run into conflicts 
> when 
> > our criteria specify particular accommodations instead of the 
> flexibility 
> > to produce them. 
> > 
> > That is why I don't understand this issue. 
> > 
> > The problem today for people with low vision is that no mechanism 
> exists 
> > for professionals to write assistive technologies that implement the 
> > diverse visual presentation requirements of all people with low vision. 
> 
> > Inflexible content is the reason for that. Criteria to help people with 
> low 
> > vision will need to create sufficient flexibility to restyle 
> presentation 
> > visually. This flexibility will not interfere with any other disability 
> 
> > group. 
> > 
> > 
> > 
> > On Mon, Oct 19, 2015 at 10:46 AM, 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