- From: <josh@interaccess.ie>
- Date: Wed, 21 Oct 2015 12:56:08 +0000
- To: "Laura Carlson" <laura.lee.carlson@gmail.com>, "lisa.seeman" <lisa.seeman@zoho.com>
- Cc: "Wayne Dick" <wayneedick@gmail.com>, "Gregg Vanderheiden" <gregg@raisingthefloor.org>, "GLWAI Guidelines WG org" <w3c-wai-gl@w3.org>
Hi all, Yes - we diverge :-) Do feel free to start new threads and thanks for all the interesting ideas and feedback so far. Labelling a thread [Subject: Extension conflict: Low Vision and Cognitive conflicts] (just as an example, I'm not saying this is the case) or similar - would be good. Josh ------ Original Message ------ From: "Laura Carlson" <laura.lee.carlson@gmail.com> To: "lisa.seeman" <lisa.seeman@zoho.com> Cc: "Wayne Dick" <wayneedick@gmail.com>; "Gregg Vanderheiden" <gregg@raisingthefloor.org>; "Joshue O Connor" <josh@interaccess.ie>; "GLWAI Guidelines WG org" <w3c-wai-gl@w3.org> Sent: 21/10/2015 13:34:41 Subject: Re: Extension conflict/compatibility requirement >Hi Lisa, > >Nice! IMHO choices by browser and tool vendors would also be of >importance too. > >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 >
Received on Wednesday, 21 October 2015 12:56:29 UTC