Re: Extension conflict/compatibility requirement

I completely agree. I think personalization would address several yet to
answered problems and helpful to specially those users who are mostly be
left as afterthought.

Thanks,
Srini

Best regards,

*Srinivasu Chakravarthula*
Sr. Accessibility Consultant, *Deque* <http://deque.com>
Hand phone: +91 709 380 3855

Deque University <http://dequeuniversity.com> | Follow me on Twitter
<http://twitter.com/CSrinivasu> | Connect on LinkedIn
<http://linkedin.com/in/srinivasuc> | About Me <http://about.me/srinivasuc>

Technology is a gift to everyone; let's create inclusive digital experience

On Mon, Oct 19, 2015 at 8:58 PM, Michael Pluke <
Mike.Pluke@castle-consult.com> wrote:

> Hi All
>
>
>
> I full agree with Lisa – personalization is the only way to resolve these
> conflicts.
>
>
>
> How that personalization is delivered is not such an easy question to
> answer. In practice it is likely that there will never be just one way in
> which it can be achieved. Those working on GPII are doing great work to
> identify one, hopefully widely supported and available way to provide
> personalization. Other, narrower, ways of providing personalization already
> exist within various websites and services.
>
>
>
> The main thing we can do at this stage is to identify where conflicts can
> exist and ensure that methods for delivering alternative solutions are
> defined. When and where personalization methods exist, these can then
> deliver the right solution to the right individual based on their needs and
> preferences.
>
>
>
> Best regards
>
>
>
> Mike
>
>
>
> *From:* lisa.seeman [mailto:lisa.seeman@zoho.com]
> *Sent:* 19 October 2015 15:55
> *To:* Hoffman <allen.hoffman@hq.dhs.gov>
> *Cc:* Laura Carlson <laura.lee.carlson@gmail.com>; Joshue O Connor <
> josh@interaccess.ie>; WCAG <w3c-wai-gl@w3.org>; Gregg Vanderheiden <
> gregg@raisingthefloor.org>
> *Subject:* RE: Extension conflict/compatibility requirement
>
>
>
> Hi All
>
> Without personlisation or allowing for alternative renderings for
> accessibility for cognitive will always be half baked and we will be
>  sacrificing the less vocal, but not less in need, groups  for the sake of
> the groups that have better representation.
>
>
>
> I think any SC should be reachable via personlisation so long as the group
> in question has easy usable access to the personlization process.
>
> All the best
>
> Lisa Seeman
>
> Athena ICT Accessibility Projects <http://accessibility.athena-ict.com>
> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter
> <https://twitter.com/SeemanLisa>
>
>
>
>
>
>
>
>
>
> ---- On Mon, 19 Oct 2015 17:08:56 +0300 *Hoffman<allen.hoffman@hq.dhs.gov
> <allen.hoffman@hq.dhs.gov>>* wrote ----
>
> See the raising the floor global initiative.
> Personalization with optional features is certainly no problem, but should
> not be promoted as the standard baseline solution. For example, one
> solution I know of offers ability to show graphs and tablular data that
> graphs are generated from, however, keyboard access and use of color are
> not addressed. Options for use of shading/patterns in graphs and more
> conforming tables are there, but should not be used as extensions, but
> should be there in baseline with optional extensions to add even more
> functionality.
>
>
> Allen Hoffman
> Deputy Executive Director
> The Office of Accessible Systems & Technology
> Department of Homeland Security
> 202-447-0503 (voice)
> allen.hoffman@hq.dhs.gov
>
> DHS Accessibility Helpdesk
> 202-447-0440 (voice)
> 202-447-0582 (fax)
> 202-447-5857 (TTY)
> accessibility@dhs.gov
>
> This communication, along with any attachments, is covered by federal and
> state law governing electronic communications and may contain sensitive and
> legally privileged information. If the reader of this message is not the
> intended recipient, you are hereby notified that any dissemination,
> distribution, use or copying of this message is strictly prohibited.  If
> you have received this message in error, please reply immediately to the
> sender and delete this message.  Thank you.
>
>
> -----Original Message-----
> From: Laura Carlson [mailto:laura.lee.carlson@gmail.com]
> Sent: Monday, October 19, 2015 8:13 AM
> To: Joshue O Connor
> Cc: WCAG; Gregg Vanderheiden; Lisa Seeman
> Subject: Re: Extension conflict/compatibility requirement
>
> 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
>
>
>
>
>