Meeting minutes
<LauraBMiller> Hello all! I just tried to log in to W3C to get to the zoom info but don’t have sufficient privileges?
Announcements
<LauraBMiller> Did I somehow get purged?
<LauraBMiller> If I am able to join, can someone paste the zoom info here.
Announcements. Don't forget to present+
US changes to daylight savings this coming Sunday, so timezone is different for 3 weeks compared with Europe. So just check calendars...
shadi: Are we meeting during week of CSUN? Week after next?
<Chuck> -1
<ShawnT> +1
<FernandaBonnin> -1
<LauraBMiller> -1
-1
<shadi> +1
<mitch11> -1
Chuck: AGWG are hosting a working session to review content @ CSUN.
… So people can join if able, but it is optional - so people can attend CSUN if they are there.
maryjom: Sounds like a plan - we could also do a working session.
<maryjom> Thurs 21 March and Friday 22 March will be working sessions due to CSUN. No TF decisions will be made that week.
We will minute the working sessions so others can catchup after the fact.
Tomorrow (extra TF working session) - we will be working on remaining SC problematic for closed functionality items.
… 2 were ready for survey, 2 need content
If we have time, we will then work on public comments
<maryjom> https://
We have made good progress on SC problematic section -work left page on wiki is up to date
Survey results - SC Problematic for Closed Functionality - 1.4.5 Images of Text
<maryjom> • https://
<maryjom> Google doc link: https://
Only 4 respondents, split results between 7 & 8
Copied from google doc for ref.
Option 7: Similar to Mary Jo’s option 4; edited for brevity 1.4.5 Images of Text—Requires text for high-quality modification of displayed text (e.g. high contrast, increase of font size). Where other mechanisms achieve equivalent results, the intent of this success criterion would be met.
Option 8: defer discussion Defer discussion on 1.4.5 Images of Text until we have first decided on 4.1.2 Name, Role, Value. Both criteria normatively rely on programmatic information.
GreggVan: Agrees with Mike Pluke's comments
mitch11: Tend to agree with GreggVan on not going beyond our remit
Q from Mitch on what the content of option 8 should be
maryjom: We will be talking about name role value and info & relationships (both are similar programmatically determined), so we could do this one as well
<maryjom> Poll: Should we defer to tomorrow's discussion along with Name, Roll, Value and Info and Relationships?
GreggVan: To simplify discussion tomorrow, whole bundle that are programmatically determined. This is meant to be open to AT, AT can be diverse, we can't solve it here to give equivalents
<mitch11> +1 to the poll
<maryjom> Poll: Should we defer to tomorrow's discussion along with Name, Roll, Value and Info and Relationships?
<mitch11> +1
+1
<GreggVan> +1
<Mike_Pluke> +1
<loicmn> +1
Survey results - SC Problematic for Closed Functionality - Keyboard SCs
Survey results - SC Problematic for Closed Functionality - 1.4.5 Images of Text
SC problematic for closed / 1.4.5, images of text - deferred to tomorrow
SC Problematic for Closed Functionality - 2.1.2 No Keyboard Trap
<maryjom> https://
Survey results - SC Problematic for Closed Functionality - Keyboard SCs
SC Problematic for Closed Functionality - 2.1.2 No Keyboard Trap
All said incorporate as is
<maryjom> Proposal in Issue 272: w3c/
One minor comment change "in" to "on" - but Mary Jo didn't see this in the content.
mitch11: It is note 1 that was from WCAG (originally said on the web page, now says on the software)
SC 2.1.2, Note 1, change "on the [non-web document or software]" to "in the ..."
Added to issue 255
<maryjom> Latest proposed content for SC problematic for Closed functionality section 2.1.2 No Keyboard Trap This criterion applies when focus can be moved using a keyboard interface. In some closed systems, tactile input like numeric keypads or other functional groups of keys may be available, but there is no mechanism for onscreen focus; for example, the keys are mapped directly to functions without moving focus between on-screen controls. In this c[CUT]
<maryjom> of focus, and therefore keyboard traps cannot exist and this success criterion would be satisfied.
<maryjom> DRAFT RESOLUTION: Incorporate the proposal for SC 2.1.2 No Keyboard Trap (linked above from the comment in issue 272) into the SC Problematic for Closed Functionality section, as-is, as well as the new note 3 for the general "Applying SC 2.1.2 No Keyboard Trap to Non-Web Documents and Software" section.
<mitch11> +1
<Sam> +1
+1
<loicmn> +1
<ChrisLoiselle> +1
<GreggVan> +1
<Devanshu> +1
<Mike_Pluke> +1
<ShawnT> +1
RESOLUTION: Incorporate the proposal for SC 2.1.2 No Keyboard Trap (linked above from the comment in issue 272) into the SC Problematic for Closed Functionality section, as-is, as well as the new note 3 for the general "Applying SC 2.1.2 No Keyboard Trap to Non-Web Documents and Software" section..
<LauraBMiller> +1
SC Problematic for Closed Functionality - 2.1.4 Character Key Shortcuts
<maryjom> https://
3 said incorporate as is, 3 incorporate with edits
<maryjom> Proposal in Issue 273: w3c/
mitch11: proposed a minor change to replace the phrase keyboard interface.
Proposed content:
<maryjom> Note 1: Certain closed systems use input mechanisms with fewer keys than a typical desktop keyboard, such as numeric keypads or other functional groups of keys, such as numeric keypads or other functional groups of keys, and lack a mechanism for keyboard shortcuts because their mode of operation revolves around a single key performing a single function. For such systems, this success criterion is satisfied.
Latest proposed content for SC problematic for Closed functionality section 2.1.4 Character Key Shortcuts --
Above is Mitch's proposed change to note 1
Original Note 1: Note 1: Certain closed systems use input mechanisms that are not a full keyboard interface, such as numeric keypads or other functional groups of keys, and lack a mechanism for keyboard shortcuts because their mode of operation revolves around a single key performing a single function. For such systems, this success criterion is satisfied.
Mitch's edit for Note 1: Note 1: Certain closed systems use input mechanisms with fewer keys than a typical desktop keyboard, such as numeric keypads or other functional groups of keys, and lack a mechanism for keyboard shortcuts because their mode of operation revolves around a single key performing a single function. For such systems, this success criterion is satisfied.
This SC is about single character key shortcuts
<mitch11> +1 "fewer keys than a full keyboard"
<dmontalvo> What about full-sized keyboard?
Sam: Could we say "fewer keys than a typical desktop keyboard"? There are laptop keyboards, onscreen keyboards, which are full keyboards - 60/75% keyboards as well
GreggVan: Trying to understand why the number of keys is relevant
mitch11: Fair question. This note is more of a clarification than solving the problem. Hinges on the definition of a keyboard shortcut - an alternative means of triggering an action.
… So with systems with only a small number of keys, understanding this SC is difficult - this is what the note is trying to do
LauraBMiller: We are talking about tactile input devices - but we are talking about combinations of keys, rather than just a keyboard?
maryjom: This is about single character keys that are a shortcut to trigger a function. (sometimes used for text input, sometimes used as a shortcut key). SC says that it should not trigger a function when you want to input text
GreggVan: Problem we have is this came from WCAG - assumed there was always a keyboard. Might be a problem with the underlying WCAG language that we are trying to solve now
PhilDay: Intent is for systems that do not support single character shortcuts, this SC is met
mitch11: Agrees with PhilDay
LauraBMiller: The reason I have a problem with this is B651.1 (Canadian standard) you are not allowed to use keys for multiple purposes
<mitch11> Proposed edit in response to Gregg: Note 1: Certain closed systems lack a mechanism for keyboard shortcuts because their mode of operation revolves around a single key performing a single function. For such systems, this success criterion is satisfied.
Sam: There are lots of devices that use keys to do multiple things. Intent was to clarify where there are only a few keys to do everything (e.g. on a simple printer interface with just a few keys).
… In that case, this is not applicable there as it is met
<maryjom> Mitch's edit: Proposed edit in response to Gregg: Note 1: Certain closed systems lack a mechanism for keyboard shortcuts because their mode of operation revolves around a single key performing a single function. For such systems, this success criterion is satisfied.
<GreggVan> +1
+1 to Mitch's proposal
<loicmn> +1
<Mike_Pluke> +1
<shadi> +1
<LauraBMiller> +1
<Sam> +1
<mitch11> +1
Note 2: Where there is no keyboard interface that provides character key input or keyboard shortcuts, this success criterion is satisfied.
<Zakim> GreggVan, you wanted to suggest that we just delete note 2
<Sam> alpha numeric and punctuation
For reference, Mitch's last update to Note 1 is:
<Sam> or non modiferier
Note 1: Certain closed systems lack a mechanism for keyboard shortcuts because their mode of operation revolves around a single key performing a single function. For such systems, this success criterion is satisfied.
Current note 2: Note 2: Where there is no keyboard interface that provides character key input or keyboard shortcuts, this success criterion is satisfied.
Sam: in definition, punctuation not included as characters.
… Sam's previous comment referred to 2.1.4 Level A
<maryjom> Poll: Do we need Note 2?
<Sam> n
<FernandaBonnin> no
<loicmn> n
<Mike_Pluke> no
<GreggVan> n
<ShawnT> no
Consensus: remove Note 2, use revised edits from Mitch of note 1
<mitch11> happy with or without note 2, happy with majority
Final edit of Note 1: Note 1: Certain closed systems lack a mechanism for keyboard shortcuts because their mode of operation revolves around a single key performing a single function. For such systems, this success criterion is satisfied.
<Sam> +1
<maryjom> • DRAFT RESOLUTION: Incorporate the proposal for SC 2.1.4 Character Key Shortcuts into the SC Problematic for Closed Functionality section, as edited by Mitch (above).
<GreggVan> cheers for mitch the wordsmith
<Sam> +1
<Devanshu> +1
+1
<LauraBMiller> +1
<GreggVan> +1
<Mike_Pluke> +1
<ShawnT> +1
<mitch11> +1
<loicmn> +1
<FernandaBonnin> +1
RESOLUTION: Incorporate the proposal for SC 2.1.4 Character Key Shortcuts into the SC Problematic for Closed Functionality section, as edited by Mitch (above).
SC problematic for closed / 2.4.7 Focus Visible
SC Problematic for Closed Functionality - 2.4.7 Focus Visible
3 incorporate as is, 4 with edits
<maryjom> Survey results: o https://
Sam: fine with option 4 if needed. Can't remember why he put Option 5 - may not have seen the short list
Option 4: Bruce’s edit of Option 1 with Phil minor edits
2.4.7 Focus Visible - Presumes that there is a mode of operation where focus can be moved and controlled by keyboard. Some closed systems may offer tactilely discernible input such as a numeric keypad or other functional groups of keys, but do not offer any mechanism for conveying focus because the user interface is designed not to need that. ...
… For example, the keys are used to select options from a spoken menu rather than to move an onscreen focus element between multiple options. In this case, there is no concept of focus, thus there is no need for a visible indicator and this Success Criterion would be satisfied.
<maryjom> DRAFT RESOLUTION: Incorporate the proposal for SC 2.4.7 Focus Visible into the SC Problematic for Closed Functionality section, as edited above.
<mitch11> +1
<Sam> +1
<shadi> +1
<GreggVan> +1
<loicmn> +1
+1
<ShawnT> +1
<Mike_Pluke> +1
<ChrisLoiselle> +1
<Devanshu> +1
<LauraBMiller> +1
RESOLUTION: Incorporate the proposal for SC 2.4.7 Focus Visible into the SC Problematic for Closed Functionality section, as edited above.
Next time work on 2.1.1 keyboard. Tomorrow look for comments on keyboard and work on it
Other items are in the wiki