Re: Proposal: expanding/modifying Guideline 2.1 and its SCs (2.1.1, 2.1.2, 2.1.3) to cover Touch+AT

gregg

> On Jul 4, 2016, at 7:23 PM, Patrick H. Lauke <redux@splintered.co.uk> wrote:
> 
> On 04/07/2016 23:03, Gregg Vanderheiden RTF wrote:
> 
>> Patrick is proposing:
>> 
>>  * that authors support high-level device/input agnostic events
>>  * that these not replace the requirements of 2.1 for
>>    keyboard-interface support but rather supplement them
> 
> Doing the first covers the second for the majority of cases.

I think we must agree to disagree on this.   I think it is quite the opposite.    

But no matter


Perhaps there is perhaps a way down the middle


2.1 is a guideline - and it is not normative. 
 
Also the Short Names are not normative — so adding “interface” to the short name  Keyboard to make it Keyboard Interface,   to help avoid the continuing misunderstanding that these are about keyboards. 


Perhaps we should be talking about  extending 2.1 
 but not  2.1.1, 2.1.2, and 2.1.3


Guideline 2.1 Generic Input Device Compatible: Make all functionality available from a keyboard <interface and other standard device agnostic input commands.>

2.1.1 Keyboard Interface: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)
2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away. (Level A)
2.1.3 Keyboard Interface (No Exception): 
2.1.4 Agnostic Commands: All non-text command input of the content is operable through standard device agnostic commands, except where XXXXX. (Level A)
2.1.5 Agnostic Function: If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away. (Level A)
2.1.6 Agnostic Commands:(No Exception):  All non-text command input of the content is operable through standard device agnostic commands,



Don’t pay too much attention to the text of  2.1.4 ,5, and 6

I still don’t understand them — since I don’t know of any standard agnostic set of  commands — but I am just trying to suggest how   2.1 could be changed — but different SC be used rather than trying to edit the normative SC’s of  WCAG 2.0


Questions — and then I am going to have to leave this conversation for awhile as I am behind in other work. 

> you refer to agnostic input  — do you mean commands?   (I don’t know of any standard text input commands that are not the keyboard input) 
> you refer to agnostic input of some type.  If we are going to require them— we must say exactly which ones they need to support.   Is there a standard set we are requiring?
> I kind of get what you are thinking of  (I think) but I don’t understand exactly what you mean..    Do you have some working language for this? 

thx

g






> 
>> Things *FOR* putting the two *TOGETHER*.
>> 
>>  * they both look much the same - so why create a second SC that looks
>>    the same rather than add the high level device/input agnostic events
>>    to 2.1
> 
> Well, it would not be one SC, but replicating 1 whole Guideline (2.1), 3 SCs (2.1.1, 2.1.2, 2.1.3), and related documentation/understanding.
> 
>>  * <patrick - I looked for more but didnt see them.   add them here >
>> 
>> 
>> 
>> 
>> Things *FOR* having them be *SEPARATE*
>> 
>>  * they are two requirements — and we don’t put two requirements in one SC
> 
> Not two distinct requirements. Doing the high-level events covers keyboard in most cases (more stringently than doing custom keyboard handlers).

* in most cases - - is not relevant.  
If not all cases - then it does not cover it.   
And I am afraid that I do not think it covers it much at all - unless you think of keyboard interface input as non-device specific as I do. 

> 
>>  * they are similar - and will both be recognized and followed best if
>>    they each are their own SC so they can be compared and differences
>>    noticed
>>  * it makes it easier to tell which sufficient techniques go with which
>>    requirement  (SC)
> 
> Once generalised, the techniques would be the same.


Clearly they would not.  If they are at the same then there is no need for a new SC at all. 


> 
>>  * 2.1 can’t be changed — so creating another SC rather than talking
>>    about editing 2.1 will create less confusion
> 
> Ok, so I'm getting conflicting information here. I embarked on this whole exercise after being told that for WCAG 2.1 was open to having actual current guidelines/SCs rewritten. I would not have bothered with this whole thing otherwise. So which one is it? Can WCAG 2.1 only add, not modify/revise existing wording?
> 
>>  * a ream of email paper has been spent establishing that this new
>>    requirement is IN ADDITION TO rather than a change in 2.1.   Trying
>>    to combine them into one would mean re-doing this again. (and again,
>>    and )
> 
> I don't believe it's an addition, but a tightening (making the requirement the user of high-level device/input agnostic event handlers - but that this should not discourage authors, if they wish, to provide additional keyboard-specific handling, the same way that they're not discouraged to provide mouse-specific handling etc). But fair enough...since you're closing the book on this already with you previous point, expect incoming new guidelines/SCs which are essentially carbon copies of the current 2.1/2.1.1/2.1.2/2.1.3 but replacing the word "keyboard" with something generic to convey touch+AT and similar scenarios...
> 
> 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