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://
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/
<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/
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/
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