RE: Extension conflict/compatibility requirement

> SC 1.4.3 is ill formed because it prescribes a specific accommodation

IMO SC 1.4.3 does not prescribe high contrast – requiring a luminosity of 4.5:1 and 3:1 out of 21 a total contrast ratio is definitely not prescribing an accommodation – it’s just setting a minimum.  People who require high contrast would not be able to effectively read with this minimum.  But we need a minimum so that a large segment of the population can read the text without a specialized adaptation.

> Accessibility provides the ability to produce accommodations

I agree that pages should be designed to be flexible to allow for accommodations.  I think we all agree on that.

> (paraphrased) Accessibility is not accommodations

There are some aspects of accessibility that need to be built in without requiring adaptation.  For example, visual indicator of keyboard focus, minimum contrast, keyboard accessibility etc.  Saying that content is flexible so you could apply a style sheet that would implement keyboard focus or add JavaScript that adds keyboard support for focusable controls is not reasonable to meet the needs of a large set of the population.  Most people accessing web content will not be changing stylesheets or using an add-on or an AT – at most they will be using zoom in the user agent.

We need to keep in mind these minimums while also requiring flexibility for adaptations.

Jonathan
--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>
Phone 703.637.8957
Follow us: Facebook<http://www.facebook.com/#!/ssbbartgroup> | Twitter<http://twitter.com/#!/SSBBARTGroup> | LinkedIn<http://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog> | Newsletter<http://eepurl.com/O5DP>

From: Wayne Dick [mailto:wayneedick@gmail.com]
Sent: Monday, October 19, 2015 9:28 PM
To: Gregg Vanderheiden
Cc: Laura Carlson; Joshue O Connor; GLWAI Guidelines WG org; lisa.seeman
Subject: Re: Extension conflict/compatibility requirement

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<mailto: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<mailto:gregg@raisingthefloor.org>



On Oct 19, 2015, at 7:12 AM, Laura Carlson <laura.lee.carlson@gmail.com<mailto: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<mailto: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