Re: Discussiong for Updated Response to issue 650/655/695/711 on Content on Hover or Focus

Okay, so 650 is talking about a tab list in the sense that ARIA 1.0 
defined it (where moving left/right arrows changes the tab with focus as 
well as 'activating' it so that the tab panel content is also updated). 
I've always hated that implementation, and here it is causing another 
headache...

The language in the 1.1 Authoring Practices doc softens the requirement 
for this tab panel update, but it is still the encouraged behaviour. So 
yes, it does complicate things.

My concern is that your new wording is really difficult to parse. This 
could be addressed either by putting a qualifier in "Dismissable" or more 
revisions to the opening phrase. For the latter approach, how about:

> Where pointer hover or keyboard focus causes additional content to 
become temporarily visible, the following are true: 

 
Michael Gower
IBM Accessibility
Research

1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com
voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034



From:   "Repsher, Stephen J" <stephen.j.repsher@boeing.com>
To:     Michael Gower <michael.gower@ca.ibm.com>, Andrew Kirkpatrick 
<akirkpat@adobe.com>
Cc:     WCAG <w3c-wai-gl@w3.org>
Date:   2018-01-18 09:45 AM
Subject:        Discussiong for Updated Response to issue 650/655/695/711 
on Content on Hover  or  Focus



-1 Sorry, but the SC preliminary text is incomprehensible now. I tried 
taking a stab at correcting this, but I don't like my version. 
[Steve] Obviously I disagree, and the reviewers I was able to get gave a 
thumbs up as well.  I’ll try to explain more below, but your objection 
seems to be 100% editorial and we can adjust that after CR.  Bottom line 
is there was not enough time to wordsmith this perfectly.


> Where receiving pointer hover or keyboard focus triggers additional 
content to become visible, and removing hover or focus causes the 
additional content to be hidden, the following are true: 
[Steve] That’s fine too, just much less succinct.  It says the exact same 
thing though.


Perhaps if the additional content become the subject of the text?
[Steve] I’ve tried that too and it’s not better IMHO.


I don't understand why the accommodation was made for 650, since a tab 
panel's content is updated on activation, not on hover. What that comment 
may have exposed is that some things like tab items may be authored to 
include hover as well as selection as a means of updating the tabpanel. If 
that is the case, this SC needs to be revamped to clarify that it is the 
dependency on hover to expose information that needs to be addressed.
[Steve] Issue 650 has nothing to do with hover.  The accommodation was 
made because a tab list, at least in some designs, operates where 
left/right arrow focus/select the next tab.  Rather than arguing about the 
subtle differences between selection, activation, focus, etc., I made a 
simple change that reflects the true intention of the SC all along.  The 
SC was designed for content which appears and disappears onhover() and 
onmouseout(), respectively, or onfocus() and onblur*(, respectively.  A 
tab may appear onfocus(), but it does not disappear onblur(); it 
disappears if another tab gets focus.


Here's a revision that I think addresses both issues:

> When additional content is revealed or hidden based solely on a trigger 
item receiving keyboard focus or pointer hover, the following are true:
[Steve] Sorry, this does not address #650 at all and the introduction of 
“solely” may be the usual case but doesn’t cover everything the SC should.





Michael Gower
IBM Accessibility
Research

1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com
voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034



From:        Andrew Kirkpatrick <akirkpat@adobe.com>
To:        WCAG <w3c-wai-gl@w3.org>
Date:        2018-01-17 04:09 PM
Subject:        CFC - Updated Response to issue 650/655/695/711 on Content 
on Hover  or Focus

 
Call For Consensus — ends Friday January 19th at 7pm Boston time.
 
The Working Group has discussed responses to the following issues:
650: (https://github.com/w3c/wcag21/issues/650)
655: (https://github.com/w3c/wcag21/issues/655)
695: (https://github.com/w3c/wcag21/issues/695)
711: (https://github.com/w3c/wcag21/issues/711)
 
Response to Issue 650: 
https://www.w3.org/WAI/GL/wiki/Draft_Responses_to_Dec_WD_Issues#650

Response to Issue 655: 
https://www.w3.org/WAI/GL/wiki/Draft_Responses_to_Dec_WD_Issues#655

Response to Issue 695: 
https://www.w3.org/WAI/GL/wiki/Draft_Responses_to_Dec_WD_Issues#695

Response to Issue 711: 
https://www.w3.org/WAI/GL/wiki/Draft_Responses_to_Dec_WD_Issues#711

 
The changes to the SC are implemented in this pull request: 
https://github.com/w3c/wcag21/pull/739

The changed SC can be viewed here: 
http://rawgit.com/w3c/wcag21/hover-focus-edits/guidelines/#content-on-hover-or-focus

 
If you have concerns about this proposed consensus position that have not 
been discussed already and feel that those concerns result in you “not 
being able to live with” this decision, please let the group know before 
the CfC deadline.
 
Thanks,
AWK
 
Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe 
 
akirkpat@adobe.com
http://twitter.com/awkawk