- From: Laura Carlson <laura.lee.carlson@gmail.com>
- Date: Wed, 21 Oct 2015 07:34:41 -0500
- 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>
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:35:17 UTC