Re: Summary of 2.1 discussion an attempt at consensus

I think this is a good idea

and to put it on a page somewhere  - so everything is in one organized place — where comments can be added and cleared - so people don’t have to read a whole email train - and people can join late or be added to the discussion without having to do it all over again.   Maybe a google doc where comments are easy and history can be tracked too? 

gregg

> On Jul 16, 2016, at 5:32 AM, David MacDonald <david100@sympatico.ca> wrote:
> 
> 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 <https://bugs.chromium.org/p/chromium/issues/list>
> 
> Cheers,
> David MacDonald
>  
> CanAdapt Solutions Inc.
> Tel:  613.235.4902
> LinkedIn 
>  <http://www.linkedin.com/in/davidmacdonald100>
> twitter.com/davidmacd <http://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 <mailto: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
>  
> CanAdapt Solutions Inc.
> Tel:  613.235.4902 <tel:613.235.4902>
> LinkedIn 
>  <http://www.linkedin.com/in/davidmacdonald100>
> twitter.com/davidmacd <http://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 <mailto: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 <http://www.splintered.co.uk/> | https://github.com/patrickhlauke <https://github.com/patrickhlauke>
> http://flickr.com/photos/redux/ <http://flickr.com/photos/redux/> | http://redux.deviantart.com <http://redux.deviantart.com/>
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> 
> 
> 
>