Meeting minutes
Announcements
PhilDay: No announcements from me
… We will get through a few items today, there are other that are mainly editorial
… The problematic for close appendix requires more work, Daniel will take it
… Then a couple more editorials, and read through the whole document, and then AGWG review
SC 2.1.1 'Problematic for Closed' suggests ways of meeting SC 2.1.1 Keyboard that don't align with the SC.
<PhilDay> Link to issue: w3c/
<PhilDay> Proposal 1 - 2.1.1 Keyboard — Assumes operation via a keyboard interface which also allows for alternate input devices. In a closed environment where a keyboard interface is not available, it may not be possible to meet this criterion, and some other non-WCAG requirements would be needed to ensure that content is operable by persons with
<PhilDay> disabilities.
<PhilDay> Proposal 2 2.1.1 Keyboard — Assumes operation via a keyboard interface which also allows for alternate input devices.
<PhilDay> Proposal 3 - 2.1.1 Keyboard — Assumes access to a keyboard interface by AT which then allows for alternate input devices.
<PhilDay> Proposal 4 (which is Proposal 3 with some of Proposal 1) - 2.1.1 Keyboard — Assumes access to a keyboard interface by AT is not true for closed functionality. This access allows for alternate input devices. Therefore some other non-WCAG requirements would be needed to ensure that content is operable by persons with disabilities.
<PhilDay> Proposal 5 - Phil possible reword of proposal 1
<PhilDay> 2.1.1 Keyboard — Assumes operation via a keyboard interface which also allows for alternate input devices to be used. In a closed environment where external access to a keyboard interface is not allowed, it may not be possible to meet this criterion, and some other non-WCAG requirements would be needed to ensure that content is operable by
<PhilDay> persons with some disabilities including limited mobility and persons without vision.
<PhilDay> Proposal 6 - Gregg's latest
<PhilDay> 2.1.1 Keyboard — is based on the assumption that assistive technologies have access to the keyboard interface and can thus provide alternate ways to provide "keyboard" input alongside any other mechanism (internal or external) provided for keyboard input. In products that do not accept input from a keyboard interface or where access to the
<PhilDay> keyboard interface is closed off for assistive technologies, some other non-WCAG requirements would be needed to ensure that content is operable by persons with disabilities that require them to use alternate keyboard input.
PhilDay: Six proposals, with some updates put into the issue, plus a comment by Bruce on the issue some minutes ago
<Zakim> bbailey, you wanted to ask that they seem very close to each other?
bbailey: I think we could reduce this to two-three proposals instead of six
… And then go one sentence at a time
Laura: I just have an issue with EZ
GreggVan: It's a technique, not a brand, but still it's a name of a specific solution
Laura: Accessible keypad maybe
bbailey: I don't have these worddsin what I proposed
GreggVan: Also don't use keypad, there are solutions that do not necessarily involve keypads
… Have a look at my otheer comment
bbailey: Proposals 4 and 5
PhilDay: I think proposals 4, 5 and 6 were all built on 1, 2, 3. Should we just focus on 4, 5, and 6?
GreggVan: I think we should go with 6 which is longer ,but there is so much confusion about this
<bbailey> I am all for longer explanation myself!
<PhilDay> This is what we currently have in the editor's draft for reference.
<PhilDay> We are just discussing a change to NOTE 6
<PhilDay> 2.1.1 Keyboard — Assumes operation via a keyboard interface which also allows for alternative input devices. It may not be possible to satisfy this success criterion when the ICT does not have a built-in keyboard, and it also does not support an alternative input method (hardware or software) that provides keyboard-like access to all
<PhilDay> functionality.
<PhilDay> NOTE 6
<PhilDay> A keypad that provides full access to functionality might be considered a keyboard.
Daniel: +1 for expanding and explaining
GreggVan: There's duplication around not accepting input from a keyboard interface and having closed keyboard interfaces
bbailey: Agree, just to follow your second sentences
<loicmn> +1 to explanatory text.
PhilDay: Looks like everybody is in agreement about proposing some level of elaboration
… We are just talking about the replacement for note 6, the bullet above will remain
… Does anyone prefer something other than proposal 6?
PhilDay: Let's work on proposal 6
<PhilDay> Proposal 6a - Gregg's original
<PhilDay> 2.1.1 Keyboard — is based on the assumption that assistive technologies have access to the keyboard interface and can thus provide alternate ways to provide "keyboard" input alongside any other mechanism (internal or external) provided for keyboard input. In products that do not accept input from a keyboard interface or where access to the
<PhilDay> keyboard interface is closed off for assistive technologies, some other non-WCAG requirements would be needed to ensure that content is operable by persons with disabilities that require them to use alternate keyboard input.
<PhilDay> Proposal 6b - Bruce's edit
<PhilDay> 2.1.1 Keyboard — is based on the assumption that assistive technologies have access to the keyboard interface and can thus provide alternate ways to provide "keyboard" input alongside any other mechanism (internal or external) provided for keyboard input. In products that do not accept input from a keyboard interface or where access to the
<PhilDay> keyboard interface is closed to assistive technologies, other requirements would be needed to ensure accessibility.
bbailey: I don't want it to be specific about alternativekeyboard input, unless we want to say that supporting easy keys would meet that
GreggVan: Easy keys is a solution, not the problem
<PhilDay> Proposal 6c - Gregg's latest
<PhilDay> 2.1.1 Keyboard — is based on the assumption that assistive technologies have access to the keyboard interface and can thus provide alternate ways to provide "keyboard" input alongside any other mechanism (internal or external) provided for keyboard input. In products that do not accept input from a keyboard interface and are therefore closed for
<PhilDay> assistive that involve alternate keyboards technologies, some requirements beyond WCAG's would be needed to ensure that content is operable by persons with disabilities that require them to use alternate keyboard input.
<bbailey> closed FOR assisistive technology - or - closed TO assistive technology ?
<PhilDay> Proposal 6c - Gregg's latest
<PhilDay> 2.1.1 Keyboard — is based on the assumption that assistive technologies have access to the keyboard interface and can thus provide alternate ways to provide "keyboard" input alongside any other mechanism (internal or external) provided for keyboard input. In products that do not accept input from a keyboard interface and are therefore closed to
<PhilDay> assistive technologies that involve alternate keyboards, some requirements beyond WCAG's would be needed to ensure that content is operable by persons with disabilities that require them to use alternate keyboard input.
Laura: Should be closed to
GreggVan: Yes
<loicmn> +1 to the last proposal
<bbailey> i like 6c
GreggVan: We should stop at how you solve the problem. Anything we say is going to codify that we think you should solve it this or the other way
… Easy Keys is codified in ISO 9241171
<PhilDay> Daniel: Like proposal 6c
Daniel: There's two instances of provide
GreggVan: I think they should stay, if you say a different word it means it is implying something else
Daniel: Not going to object to this one
Daniel: "provide alternative ways to provide" I really meant these two
<PhilDay> Daniel: Should substitute for the first "provide"
<PhilDay> Proposal 6c - Gregg's latest
<PhilDay> 2.1.1 Keyboard — is based on the assumption that assistive technologies have access to the keyboard interface and can thus provide alternate ways to provide "keyboard" input alongside any other mechanism (internal or external) provided for keyboard input. In products that do not accept input from a keyboard interface and are therefore closed to
<PhilDay> assistive technologies that involve alternate keyboards, some requirements beyond WCAG's would be needed to ensure that content is operable by persons with disabilities that require them to use alternate keyboard input.
GreggVan: Still think these are good as they are
PhilDay: Enable?
GreggVan: Enable means it's there and you just have to enable it
<PhilDay> Copy of latest proposal: w3c/
Laura: What about "beyond"? We are talking about the software and not go into the harddware space, we should be cautions
… Also, requirements beyond WCAG is really requirements beyond software, which would be out of scope
GreggVan: You cannot get to harware from within WCAG, if you go beyond WCAG you can then get into software
Laura: But that'd be out of scope for WCAG2ICT anyways
PhilDay: Laura, are you concerned with the phrase "requirements beyond WCAG"?
Laura: Yes. Also with the way we are talking about keyboard
… We are talking about the keyboard functionality, not about a physical keyboard
PhilDay: I've checked the current Editor's Note and we've used the phrase "other non-WCAG requirements in other SCs already"
bbailey: Agree with consistency, we should take the edit here and apply to the others
<Zakim> bbailey, you wanted to say i think proposal 6c is okay scope wise
bbailey: I think we are hitting the right amountof detail
<PhilDay> Latest version with offer instead of provide:
<PhilDay> Proposal 6c - Gregg's latest
<PhilDay> 2.1.1 Keyboard — is based on the assumption that assistive technologies have access to the keyboard interface and can thus provide alternate ways for "keyboard" input alongside any other mechanism (internal or external) provided for keyboard input. In products that do not accept input from a keyboard interface and are therefore closed to
<PhilDay> assistive technologies that involve alternate keyboards, some requirements beyond WCAG's would be needed to ensure that content is operable by persons with disabilities that require them to use alternate keyboard input.
<PhilDay> Latest edits from Gregg on proposal 6c: 2.1.1 Keyboard — is based on the assumption that assistive technologies have access to the keyboard interface and can thus provide alternate ways FOR "keyboard" input alongside any other mechanism (internal or external) provided for keyboard input. In products that do not accept input from a keyboard
<PhilDay> interface and are therefore closed to assistive technologies that involve alternate KEYBOARD INPUT, some requirements beyond WCAG's would be needed to ensure that content is operable by persons with disabilities that require them to use alternate keyboard input.
PhilDay: Methods rather than techniques?
<PhilDay> 2.1.1 Keyboard — is based on the assumption that assistive technologies have access to the keyboard interface and can thus provide alternate ways FOR "keyboard" input alongside any other mechanism (internal or external) provided for keyboard input. In products that do not accept input from a keyboard interface and are therefore closed to
<PhilDay> assistive technologies that involve alternate KEYBOARD INPUT METHODS, some requirements beyond WCAG's would be needed to ensure that content is operable by persons with disabilities that require them to use alternate keyboard input.
<PhilDay> Daniel: Resolves my concern
Daniel: That would resolve my comment
Laura: Mine too, that's fine
<PhilDay> DRAFT RESOLUTION: For SC problematic for 2.1.1 Keyboard on incorporate proposal 6c into the editor’s draft, with edits shown in the meeting minutes above
<loicmn> +1
<PhilDay> +1
<Daniel> +1
<GreggVan> +1
<bbailey> +1
Laura: +1
RESOLUTION: For SC problematic for 2.1.1 Keyboard on incorporate proposal 6c into the editor’s draft, with edits shown in the meeting minutes above
Daniel: We should use "people" instead of "persons with disabilities"
bbailey: Necessary?
PhilDay: Yes.
GreggVan: Yes
<PhilDay> Final edit: 2.1.1 Keyboard — is based on the assumption that assistive technologies have access to the keyboard interface and can thus provide alternate ways for "keyboard" input alongside any other mechanism (internal or external) provided for keyboard input. In products that do not accept input from a keyboard interface and are therefore closed
<PhilDay> to assistive technologies that involve alternate keyboard input methods, some requirements beyond WCAG's would be needed to ensure that content is operable by people with disabilities for whom it is necessary to use alternate keyboard input.
<PhilDay> Final edit: 2.1.1 Keyboard — is based on the assumption that assistive technologies have access to the keyboard interface and can thus provide alternate ways for "keyboard" input alongside any other mechanism (internal or external) provided for keyboard input. In products that do not accept input from a keyboard interface and are therefore closed
<PhilDay> to assistive technologies that involve alternate keyboard input methods, some requirements beyond WCAG's would be needed to ensure that content is operable by people with disabilities for whom it is necessary to use alternate keyboard input methods.
Laura: Only concern is how long it is, but we don't seem to have another alternative
PhilDay: I think that's good, as we are reading it people will be able to put it in context
ACTION: Editors to check SC problematic for closed for use of the phrase "other non-WCAG requirements" and substitute with "requirements beyond WCAG's"
SC 1.4.11 Non-text Contrast 'Problematic for Closed' needs improvement.
<PhilDay> Link to issue: w3c/
<PhilDay> Proposal 0 - current version
<PhilDay> 1.4.11 Non-text Contrast — There are cases where applying this success criterion to non-web software on ICT with closed functionality is problematic:
<PhilDay> When the contrast of the content is determined by the hardware and not modifiable by the software author, it may not be possible to meet this success criterion.
<PhilDay> Note 4 Contrast requirements for hardware are out of scope for WCAG2ICT (and this success criterion).
<PhilDay> When the color contrast ratio cannot be programmatically measured due to system limitations (e.g. lockdown), precise quantifiable testing of color contrast cannot be performed by a third party. In such cases, the software author would need to confirm that the color combinations used meet the contrast requirement.
<PhilDay> Note 5 Photographs are not sufficient for testing that content meets this success criterion. This is because the quality of the lighting, camera, and physical aspects of the hardware display can dramatically affect the ability to capture the content for testing purposes.
<PhilDay> Proposal 1 - Mitch's edit
<PhilDay> 1.4.11 Non-text Contrast — There are cases where applying this success criterion to non-web software on ICT with closed functionality is problematic:
<PhilDay> When software authors can modify the appearance of content, but only within a limited contrast range determined by hardware, it may not be possible to meet this success criterion.
<PhilDay> [Following notes are unchanged]
PhilDay: I am happy with the edit
<loicmn> +1 to Mitch's proposal
GreggVan: I don't understand why that's different from software as a whole
… Authors are only responsible for the specified content
… If your software specifies a valid contrast even if the hardwaare doesn't render it, you comply
<bbailey> +1 to moving some of these comments out of closed and make them notes to the SC
PhilDay: If your hardware limits you you may not have the same freedom
GreggVan: It's just the reality of life problem, doesn't have to do with the limits of the hardware
GreggVan: If we talk about the contrast of the label or control that are inked that is a different topic
PhilDay: We are talking about onscreen, not labels affixed to the hardware
Daniel: The product wouldn't be meeting the contrast ratio regardless of whether the author can specify the contrast
GreggVan: What I am saying is that it is a problem, but ont only for closed functionality, it would be for all software
<PhilDay> https://
<PhilDay> 1.4.3 and 1.4.11 need to be consistent
GreggVan: 1.4.3 and 1.4.11 would have to be the same, whether it's hardware or all software
bbailey: I wonder if we should have a section on how to use WCAG in the context of hardware
PhilDay: I do see Gregg's point. We give guidance about harwdare and later we say hardware is out of scope
<bbailey> +1 that there is value in keeping these hardware-oriented notes!
Daniel: I think these are good to stay, we are acknowledging that these things can happen but we are notproviding guidance for hardware because as you said it's out of scope
loicmn: Two issues. I think it's good to keep it in to acknowledge that sometimes it won't be possible to meet, and also, whatever we do we should do for 1.4.3 and 1.4.11
<bbailey> +1 that what we do here for 1.4.11 be replicated in 1.4.3
loicmn: Mitch's issue -- sometimes you have a limited number of colors to choose from. Interesting thing, but should probably come in the form of a note and also not only for closed
… If we're taking it, I'd suggest we put it outside closed
PhilDay: Mitch's proposed new edit is raising a new thing that we hadn't cover before, right?
loicmn: Yes, it's a different issue
… My suggestion would be to keep what we have for closed but then if we think this proposal is interesting I would add it as a new note in 1.4.3 and 1.4.11 main sections
GreggVan: I don't think either one of these things belong in closed functionality at all. Whether the system limits the colors is not a function of the software being closed, it would apply whether the software is closed or open
… If you are limited in colors you just have to limit your creativity, but you could still do for example black and white
… AT don't change contrast
… If you use zoom text in zoom mode you still have the ability to do black and white, which means you can override the author intent and introduce your own
GreggVan: But that doesn't have to do with the author
PhilDay: I think the notes 4 and 5 are specific to closed systems
GreggVan: That would be a testing problem
<Zakim> PhilDay, you wanted to say this is an issue with AT
bbailey: Note 5 about photograph in the screen is a bit older
PhilDay: We've been having them since we wrote this
GreggVan: We should say is problematic for testing
GreggVan: Flashing would be also difficult to test and we are not saying anything about it now
PhilDay: We'll need to have a think about it, and solve it next week
… For now I agree with loicmn that what we have is better
… We've had similar discussions when something is not clear on whether it affects closed alone or all software
<bbailey> +1 for keeping what we have , and being open to adding something additional
<bbailey> w3c/
GreggVan: Two angles: whether or not it's for closed alone or for all software: whether or not it is difficult to test
<Zakim> bbailey, you wanted to mention filed issued
bbailey: Please make sure about the "non-WCAG requirement"