W3C

– DRAFT –
WCAG2ICT Task Force Teleconference

23 March 2023

Attendees

Present
BryanTrogdon, Chuck, Daniel, Devanshu, FernandaBonnin, LauraBMiller, maryjom, Mike_Pluke, olivia-hs, PhilDay, Sam, shadi, ShawnT
Regrets
-
Chair
Mary Jo Mueller
Scribe
FernandaBonnin

Meeting minutes

scribe, FernandaBonnin

Announcements

maryjom: the AGWG met on Tuesday and review the survey content (4 S.C., new guideline and background) everything was approved. Editors need to approve the PR

maryjom: changes are mostly editorial stuff

<maryjom> https://github.com/w3c/wcag2ict/pulls?q=is%3Apr+Changes+due+to+AG

chuck: that went really smooth. Sometimes in this group, will try to go outside of scope and try to alter the normative content and its a natural thing to try to do and it takes a little bit to get used to. thank you MaryJo for the preparation and thanks all

maryjom: maybe someone on the AGWG group will come with something, maybe best practicesto cover those cases

Project standup (status of your assigned issues)

maryjom: 1.4.12, 1.4.11 and 4.1.3 we will talk about today as they are ready for review

maryjom: the only S.C left are 1.4.10, MaryJo is working on a proposal. Bruce said he would be happy if someone else can take 2.5.1. anyone wants to take this on?

Sam: I'll take that

maryjom: there are some initial thoughts on the issue and would recommend looking at 2.5.2 issue too

maryjom: there is some work on editorial, and how the colors want. Michael Cooper was doing the includes before CSUN. Daniel, I think we should catch up

daniel-montalvo: agree

maryjom: if we approve 2 more, we will be able to open a new survey for AGWG

GreggVan: the change where we said that long press don't meet the definition of keyboard shortcut, is that our lang or per WCAG? worried about posing an a11y problem. if the only way of doing something is a long press on the keyboard that violates everything being operable from a keyboard

PhilDay: the intent was that this was specific to closed systems that have limited keys of the keyboard, e.g. a photocopier. if we haven't capture that in the notes, then we could maybe look at clarifying that

GreggVan: I thought we hadn't cover keyboard closed systems, is this restricted to closed systems?

maryjom: this was in the context of the requirement of single character key press. I don' think we restricted it to closed systems

<Sam> w3c/wcag2ict#76 for refference

<PhilDay> Thanks Sam -I was just looking for the relevant issue!

Chuck: we shouldnt be making any new rules.

maryjom: for now, if we want to re-address this, then we need to open an issue and address it as an issue so that we can continue with today's agenda

SC 1.4.11 Non-text Contrast readiness to incorporate into editor’s draft

maryjom: 5 can be incorporated as-is, 2 with changes. Sam was worried because wanted to remove second bullet the mention of screen capture that can mean anything. Mithchell suggested further edit, Fernanda agreed with Sam and noticed that no similar comment on 1.4.3 for closed functionality

<maryjom> w3c/wcag2ict#82 (comment)

maryjom: I made some changes to those functionality bullets based on the comments

<Sam> +1 to MJ changes

+1

<PhilDay> +1

GreggVan: it seems to me that the success criteria is problematic for closed functionality

maryjom: yes, we have a section for that and that's what we are proposing

<Sam> The change is only to the Appendix A area not the SC text in the WCAG2ICT part

GreggVan: the people who are making the product can know what the content is, the fact that is hard for a third party to test makes it hard but the individual creating it knows the content, so I don't think that is an exception

Sam: I want to point out this is part of the appendix; the concern is that if there is no way to test it then what is the point? also, there are some cases where you cannot change the colors. if discerning the color is not possible how do you test?

GreggVan: how is it not possible for the person who programmed the content not to know what they programmed?

GreggVan: the second part on if you cannot change colors, then its still unnaccessible

maryjom: its not a stated exception, its a stated issue, it makes it difficult to test

Sam: its not saying that you shouldn't do this, the appendix is "problematic criteria for closed functionality"

Sam: there are cases where you cannot specify the values. its not a get out of jail, the modification was around not using a camera to determine the colors

Mike_Pluke: Greggs point is certainly not possible for a 3rd party test to test, but its possible for the creator to do this. its a fundamental issue here, a 3rd party tester cannot test this ,but the creator of the software can determine this

GreggVan: we ran into this with hardware displays where it was impossible to have the right contrast because the display had poor contrast, and thus the display was innaccessible

GreggVan: it may be hard / impossible to test but its still not accessible, and that is not a problem of the S.C.

maryjom: this is a requirement for content authors, if they have no control over the hardware then they can't overcome that so they can't be responsbile for fixing contrast issues, there needs to be a hardware requirement.

<Zakim> Chuck, you wanted to ask the intent of this addition

FernandaBonnin: we are not giving a get out of jail card, its just saying this is problematic to test in closed functionality

<Zakim> GreggVan, you wanted to say -- for WCAG2ICT we are not talking about authors -- we are talking about mfgrs of ICT.

Chuck: is the note of this just to say that third party will have a hard problem to test and not to provide an exception?

GreggVan: in WCAG we are talking about the content author, WCAG2ICT we are talking about the manufacturer of the product. if we are talking aboutclosed products then we are in a whole other category. I like the framing of problem for third party but not for author

Sam: 1, I am not sure I agree with the content author applies all the way to manufacturer. But that is beside the point on this specific bullet, we want to avoid having false-positives or incorrectly measuring the contrast with a photo. We need consistent results and that is the point of the bullet here. It doesn't exempt the content authors, its about making sure there is a determinable way to test

LauraBMiller: I would just refer this back to whichever bullet we used to talked about pixelation and height of the font. so in that scenario, w talked about how the font is presented depends on the screen size. This is the exact same situation

<Zakim> GreggVan, you wanted to correct my comment -- we are talking about SOFTWARE and DOC not the hardware display. So if the SOFTWARE has the contrast specified -- the di

GreggVan: I wanted to correct my comment, we are not writting specs for manufacturers, we are writing specs for software. The software has no control of how good the display is

GreggVan: if the software specifies a color and the display uses another one then that is a hardware problem, but I will say Chuck has the right solution for this. Remove both bullets

GreggVan: the programmer should just test for contrast and then its on the hardware to display correctly

<Zakim> Chuck, you wanted to say I was just asking a question, not proposing a solution :-)

<PhilDay> Chuck, plain language is always brilliant!

Chuck: thank you for the accredditation but I was not proposing a solution, I was asking a question and trying to understand what I was trying to say

Chuck: my question was: are we ack that its going to be hard to third party testers to test and authors need to do the validation?

maryjom: this is not an exemption, its not written as an exemption, it just says its problematic to test. and testers need to know how to handle this situation, it will not show up as not applicable, it will need a comment that its up to the hardware as there is no capability, I still think that these bullets are needed, and maybe we can add to the bullet to mention the author needs to do the testing

Sam: I think we need to ack here that checking the color on the finished product is difficult and I don't agree with Gregg's that it should be on the manufacturer. For closed products and manufacturers, this is to help differentiate and remove testing that doesn't make sense and focus on adapting these s.c. as much as its possible

<Zakim> GreggVan, you wanted to Proposal kill both notes -- and replace with "For closed products confirmation of the contrast by 3rd parties may be difficult to do precisely but this would not be a problem for the author. and to Proposal kill both notes -- and replace with "For closed products confirmation of the contrast by 3rd parties may be difficult to do precisely -- or to determine what the contrast specified in the software was but this would not be a problem for the author of the document or software writer.

Sam: this is not a 'dont do anything' or an exemption, its just talking about examples to bring clarification here. I think it should be kept

GreggVan: the first bullet is innapropoate to have in the appendix: the first bullet point is just about read the exception. I suggested a text below on how to approach the bullet

GreggVan: the author is responsible for what they program

GreggVan: there is nothing that can be done after the software specifies poor contrast, that is not something thehardware can solve

<GreggVan> q to say that the note is NOT covered by the exception above. That is misread

FernandaBonnin: I propose keeping the two notes and adding authors need to do testing in the second bullet point

<Zakim> Chuck, you wanted to say that Laura also made a proposal

GreggVan: the first bullet point is not covered by the exception above, the S.C. exeption is when the author doesn't modify the appearance of the component, not same as the bullet points below. I don't think we should keeping the two bullet points

Chuck: we are having a robust conversation on this which I appreciate, but we have a proposal from Gregg and Laura. Maybe we put together the 3 proposals and we do a survey?

<Zakim> PhilDay, you wanted to say authors or content creators

PhilDay: broadly supporting on Fernanda's addition, so we keep the 2 bullets and add more on the responsibility with the person who creates the content. Question: do we always use the word author, or is there a more encompassing term?

PhilDay: testing with a camera or something like that that fudges the testing is no body's best interests

<maryjom> Poll: 1) Keep as-is 2) Remove both bullets 3) Fernanda's addition 4) Something else

<GreggVan> 2 - and replace with text provided avove

<Zakim> FernandaBonnin, you wanted to say we should also have Laura's suggestion in the options

<PhilDay> 3

<Sam> 3

<ShawnT> 3

<olivia-hs> 3

<maryjom> 3

<GreggVan> 2 kill both notes -- and replace with "For closed products confirmation of the contrast by 3rd parties may be difficult to do precisely -- or to determine what the contrast specified in the software was but this would not be a problem for the author of the document or software writer. 4

maryjom: will put out a survey with the different options, if everyone can provide me with the exact text

Chuck: I am seeing some momentum behind 3, so maybe's 2 options (Greggs and Fernanda's)

maryjom: and Laura's too, we need to look into what this was

<Chuck> I have a hard stop.

<PhilDay> w3c/wcag2ict#80 was the target size discussion

LauraBMiller: when we were talking about pixels, but it was just comment if someone remembers how we handle that

PhilDay: target size but I am not sure we had a resolution, it was an interesting discussion

Minutes manually created (not a transcript), formatted by scribe.perl version 210 (Wed Jan 11 19:21:32 2023 UTC).

Diagnostics

Maybe present: daniel-montalvo, GreggVan

All speakers: chuck, daniel-montalvo, FernandaBonnin, GreggVan, LauraBMiller, maryjom, Mike_Pluke, PhilDay, Sam

Active on IRC: BryanTrogdon, Chuck, daniel-montalvo, Devanshu, FernandaBonnin, GreggVan, LauraBMiller, maryjom, Mike_Pluke, olivia-hs, PhilDay, Sam, shadi, ShawnT