– DRAFT –
WCAG2ICT Task Force Teleconference

https://w3c.github.io/wcag2ict/

Announcements

<Chuck> present

MJ: Still a lot of work to be done
… Public comments, accessible authentication, cleanup, issues with parsing brought during the AGWG review, and other things
… I have gotten feedback that sometimes it is confusing to figure out where we are on something
… We can have pointers but prpobably we should put more focus on what the current proposal is

MJ: Anything that you can help with, please contribute, especially if you are assigned in the GitHub issue
… We have the Friday calls for at least a couple of weeks, we may extend these based on our progress
… Each week I am going to pick up a few things for us to discuss

Mj: At the Friday meeting we talked about some of the closed functionality SCs. We opened a new discussion

<maryjom> Discussion: https://github.com/w3c/wcag2ict/discussions/302 for Name, Role, Value SC

SC Problematic for Closed functionality

2.1.4 Character Key Shortcuts (proposal from Friday sub-group)

MJ: We have a proposal from the sub group

MJ: Maybe there is a bullet needed in the main guidance because it is not just closed functionality which needs the notes
… The proposal adds at in the closed functionality section as well as on the main guidance

<maryjom> Option 1: Add the following notes

<maryjom> Note: Where there is no keyboard interface that provides character key input or keyboard shortcuts, this success criterion is satisfied.

Bruce: What is the difference between these two?

Mitch: AFter the thing you copied there was a concern of mine in the minutes
… We edited for when keys are present but still there were no keyboard shortcuts

MJ: It seemed there was only one bullet added to the general guidance. I have it on my own word document

<bruce_bailey> https://www.w3.org/2024/01/12-wcag2ict-minutes#t01

Gregg: "is satisfied" is a normative comment, you can't put it in that form

Gregg: According to WCAG, when something does not exist, the success criteria would be [...]. I am trying to stay away from should and shall

Sam: I think this is great. We should not get into WCAG's definition of keyboard interface

Mitch: I was mistaken before because I hadn't scrolled down on this page. I'm with Sam

Gregg: It's good, it just needs some tweaking. There is no keyboard interface available to the software
… "Character key input or keyboard shortcuts" -- We are switching back and forth between the platform and the software
… The sentence is talking about these two things but it's not telling which is which

Phil: Waht if we eliminate "keyboard input"

<PhilDay> suggest "keyboard interface that provides character key shortcuts" instead of "keyboard interface that provides character key input or keyboard shortcuts"

Gregg: That does not work. For example with a product with keyboard that does not provide keyboard shortcuts

MJ: Character key shortcuts is about having a single character shortcut where you also have the potential to interfere with keyboard entry for text
… It does not matter who provides this

<mitch11> proposal responding to Greggg's and Phil's comments: Where software does not use a keyboard interface, there is no possibility of keyboard shortcuts and this success criterion would be satisfied.

<bruce_bailey> > Note: Where there is no keyboard interface that provides keyboard shortcuts, this success criterion is satisfied.

<Sam> for reference https://w3c.github.io/wcag2ict/#character-key-shortcuts

Gregg: This provision starts with "If a keyboard shorcut is implemented in content".
… That is already clear from the SC language, no need to add it here

<bruce_bailey> > If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true...

Sam: I think it gives clarity to the note, it makes it more clear to general ICT
… I'd change the wor to "supportive" though, but still think we should keep it

MJ: This note will go on the main SC guidance

Mitch: I've been convinced about the note. It was overly confusing not to say something. I would agree with Gregg

<bruce_bailey> > Where software does not use a keyboard interface, there is no possibility of keyboard shortcuts and this success criterion would be satisfied.

Mitch: Proposed tweak to the second part of the sentence

<bruce_bailey> at 10:27

<Zakim> bruce_bailey, you wanted to try and channel phil

Bruce: Agree, it's helpful to have the note
… The difficulty is that the literal qualifier on the SC is hard to parse in the context of software

Gregg: The keyboard interface is not the software, that's the OS, it's either there or not there
… Where the app does not accept keyboard input or does not have any keyboard shortcuts, these item is met

<PhilDay> Proposal from Gregg: Where software either does not accept keyboard input, or accept keyboard shortcuts, this success criteria would be satisfied.

Gregg: Also we could say "If the underlying paltform does not have keyboard interface"

MJ: It's not just the app, it may mean specific functionality type of device

Gregg: Does not matter

Mitch: I'm confused about what you are critiquing. I think I addressed that in my proposal
… I think we don't need the "or" anymore

Gregg: What about if the device provides this? The purpose of this one is to not interfere with AT
… IF keys are designed so that each mean their own thing, that sounds like buttons in an app. Can you explain this?

Sam: That's how it is defined in the SC

<bruce_bailey> https://www.w3.org/TR/WCAG22/#character-key-shortcuts

<bruce_bailey> https://www.w3.org/TR/WCAG22/#dfn-keyboard-shortcuts

<bruce_bailey> > alternative means of triggering an action by the pressing of one or more keys

Mitch: Maybe it only belongs in the main guidance. Those wouldn't be keyboard shortcuts according to the definition. I don't think they are very common, only game controlers, or numeric keypads as interfaces to the computers
… Or maybe in option one the two paragraphs need to be "and".

<Zakim> PhilDay, you wanted to suggest we focus on note in main SC first, then have separate discussion on problematic for closed...

<bruce_bailey> +1 to main SC first

Phil: I wonder if we should just focus on the text for the main SC first and then come back to the closed functionality section

Sam: Here it also defines keyboard interface. This would bring more clarity because it links to the definition and explains if it belongs to the software or the platform

<Sam> https://www.w3.org/WAI/WCAG21/Understanding/keyboard.html#dfn-keyboard-interface

Gregg: We have a requirement that software be operable from the keyboard
… Then we have a requirement that says if you don't take input from the keyboard, the SC is met
… If there is a keyboard, you have to take input from it
… We would be saying that if something is a WCAG violation you are still passing this other one
… IF you have menu-like interfaces they would meet the keyboard operability but still it will interfere with the AT
… The AT uses to get the keystroke first, therer is always going to be conflicts

MJ: The problem is with voice control. It needs to be possible to type and to activate the shortcut

Gregg: In the menu-like interface, if the only purpose of the key is that one function and it's not used somewhere else, you can't interfere

Mitch: I think screen reader could be a use case. Dexterity is another use case. Voice control was the primary one
… Passing an SC while failing others is not unique to this. It's common in other parts of WCAG

<Zakim> bruce_bailey, you wanted to ask if we already tried focusing on the "shortcut" aspect?

MJ: Ther is ICT with no keyboard interface (even no onscreen keyboard), I wouldn't say that's not accessible. There might be specific keys assigned to specific functions and other approaches

Gregg: WCAG only talks about open. It would be difficult for us to try to solve this in other closed functionality provisions as well

<maryjom> Poll: do we need a note in the general guidance for sc 2.1.4? Yes or no?

<PhilDay> yes

<GreggVan> no -- if it is open it is clear from text

<mitch11> yes preferred; also okay with no

<bruce_bailey> no -- but I want to double check where we are with 2.1.1

<Bryan_Trogdon> no

<FernandaBonnin> no

<Sam> yes

<bruce_bailey> https://w3c.github.io/wcag2ict/#applying-sc-2-1-1-keyboard-to-non-web-documents-and-software

<GreggVan> +1 to only in closed

Phil: I think it's helpful as it clarifies what happens where there is no keyboard interface. I'm fine with putting this only in closed functionality if people agree

Mitch: If other people think it adds clarity, but I can go with the majority

<Zakim> bruce_bailey, you wanted to ask if we are done with 2.1.1 ?

Bruce: I'd double check if we are done with 2.1.1. It seems we are

MJ: We didn't even touch it in the main guidance

Sam: Agree with Phil

<maryjom> 4 said no, 2 yes, 1 yes preferred but could go with no

<PhilDay> General note is helpful for clarity (and could be removed if majority rule), but note in closed functionality is a must from my perspective

Phil: I am still a "yes" but I would be happy to go with the majority if we still have it in closed

Sam: Same here

<maryjom> DRAFT RESOLUTION: Don't add a note to 2.1.4 Character Key Shortcuts general guidance.

<mitch11> +1

<bruce_bailey> +1

<ShawnT> +1

<FernandaBonnin> +1

<Bryan_Trogdon> +1

<Sam> +1 but will add note in Closed Function

<mitch11> Thanks all, dropping

RESOLUTION: Don't add a note to 2.1.4 Character Key Shortcuts general guidance.

<PhilDay> +1