Summary of 2.1 discussion an attempt at consensus

I'd like to try to come to a temporary resolution:

This thread and it's variations are over 65 emails long. Many of those are
substantive. This represents valuable resources from all parties, and this
is before the wider group and the public even see it.

I think Patrick has successfully communicated his vision so that we
understand what he is trying to accomplish. Also, I think Patrick has
explained that the main reason for the consolidation is to try to make the
standard more elegant, and shorter, rather than change what we are trying
to require.

Jeanne expressed concern that if the standard is perceived as too long, it
will not be accepted, citing UAAG as an example. Chrome has a bug list of
628,000 currently. (1)  I don't think consolidating UAAGs  (approx) 110 SCs
into, say, 60 more complex and obtuse requirements would have changed the
outcome. The UAAG team did a tremendous job and browsers manufacturers are
adopting its recommendations on their own terms.

We have been asked to come up with SCs that address the new reality of
touch screen and small devices. It was a good effort to try to work those
into the bigger picture, and try to solve a whole bunch of other WCAG
issues outside our scope, but I think the consolidation considerations are
super complex and can be handled by the larger group, after we address the
current outstanding comments from the group and get consensus among
ourselves and then the wider group about "what" to put into WCAG 2.1,
rather than "how" we present it.

Patrick, would it be OK if we break this up? We need you, and we appreciate
your expertise.

If our SC proposals are somewhat redundant with current SCs, the entire
group can look at that after we meet our deadline and deliver on our
mandate.

(1) https://bugs.chromium.org/p/chromium/issues/list

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*
Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Fri, Jul 15, 2016 at 2:56 PM, David MacDonald <david100@sympatico.ca>
wrote:

> >I’m struggling to understand where the proposal [1] doesn’t do this, at
> least in principle.
>
> >Slightly updated with ‘including’:
>
> >“All functionality of the content is operable through accessibility
> supported non-pointer input interfaces (*including* keyboards), without
> requiring specific timings for individual interactions, ​except…”
>
> This is my amendment, the proposal currently says "(such as Keyboards)".
> This would be my minimum starting point to get back on the fence.... but I
> have so many other concerns currently, given the loss of 2.5.1 that I just
> can't see an elegant way to get comfortable without something like the two
> notes that were also in my amendment.
>
> =NOTE: All functionality is still required to work with a keyboard as per WCAG 2
> =NOTE: All functions available by touch are still available by touch after platform assistive technology that remaps touch gestures is turned on.
>
> But the second note is a huge new requirement. It is 2.5.1 and the SC
> currently doesn't say what is in the note.
>
>
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
> Tel:  613.235.4902
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> twitter.com/davidmacd
>
> GitHub <https://github.com/DavidMacDonald>
>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>
>
>
> *  Adapting the web to all users*
> *            Including those with disabilities*
>
> If you are not the intended recipient, please review our privacy policy
> <http://www.davidmacd.com/disclaimer.html>
>
> On Fri, Jul 15, 2016 at 12:37 PM, Patrick H. Lauke <redux@splintered.co.uk
> > wrote:
>
>> On 15/07/2016 16:56, Alastair Campbell wrote:
>>
>> My reading is basically: Make sure you can do everything without a
>>> mouse, including using a keyboard. This seems good, minor point about
>>> the term “non-pointer input” aside.
>>>
>>> I don’t think it does impact the new 2.5.1, as that is tackling a
>>> different issue. (That of a touch interface changing with the AT
>>> applied.)
>>>
>>> Working to the new 2.1 should make 2.5.1 easier to meet, but there are
>>> issues (e.g. relying on touch-swiping) that are not covered by the
>>> current or proposed 2.1.
>>>
>>
>> David is correct that my proposed 2.1 changes would cover what's
>> currently 2.5.1
>>
>> If you have functionality implemented through swiping, it needs to also
>> work for non-pointer users (keyboard, touch interface when AT applied). So
>> the concepts touched (hah) on in 2.5.1 actually come back to "it needs to
>> work in touch+AT as well". Since the interface (to pass WCAG) that uses
>> swipes/gestures already today also needs to work with keyboard anyway, my
>> proposed 2.1 changes avoid having to use 2.5.1 (as if 2.1 is expanded to
>> include touch+AT, then it serves the same purpose as 2.5.1)
>>
>> An example might help, let’s take an image slider/carousel that lets you
>>> move through a set of images. (Patrick, you might need to correct the
>>> details, but I think the premise is valid?)
>>>
>>> For the next / previous functionality you could fail on all counts by
>>> using mouse-specific events attached to the left/right sides for
>>> previous/next, and swipe detection (touchstart, touchmove, touchend).
>>> This fails 2.1 current and proposed, and 2.5.1 I believe (because swipe
>>> is used for navigating with AT).
>>>
>>> You could pass current 2.1 by adding keyboard events, but fail 2.1
>>> proposed, and fail 2.5.1.
>>>
>>>
>>>
>>> You could pass current and proposed 2.1 by using keyboard and mouse
>>> event-handlers, but if a touch interface relies on detecting swipes that
>>> would still fail 2.5.1.
>>>
>>
>> No if the touch interface relied on detecting swipes, it would fail
>> proposed 2.1 since it can't be operated using all non-pointer interfaces
>> (adding keyboard events would allow traditional keyboard controls, but
>> wouldn't do anything for touch+AT scenario)
>>
>> Circling back to all the good work in 2.5.1 - ASSUMING that we do still
>> want to explore how 2.1 could be made more holistic, all the wording and
>> examples produced for 2.5.1 can/should be added to the relevant parts of
>> 2.1 (so the examples about how AT remaps gestures etc would be relevant in
>> explaining the proposed input-agnostic 2.1)
>>
>>
>> P
>> --
>> Patrick H. Lauke
>>
>> www.splintered.co.uk | https://github.com/patrickhlauke
>> http://flickr.com/photos/redux/ | http://redux.deviantart.com
>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>>
>>
>>
>