14:24:22 RRSAgent has joined #ag 14:24:22 logging to http://www.w3.org/2017/03/21-ag-irc 14:24:24 RRSAgent, make logs public 14:24:27 Zakim, this will be WAI_WCAG 14:24:27 ok, trackbot 14:24:27 Meeting: Accessibility Guidelines Working Group Teleconference 14:24:27 Date: 21 March 2017 14:25:28 Scribe: Rachel 14:25:32 Chair: AWK 14:25:35 zakim, agenda? 14:25:35 I see 1 item remaining on the agenda: 14:25:36 1. personalization [from AWK] 14:25:43 Zakim, clear agenda 14:25:43 agenda cleared 14:28:58 agenda+ ACTF: https://www.w3.org/2002/09/wbs/93339/ACTFrameworkFPWD/ 14:29:07 agenda+ Reminder about GitHub issue updating for SC managers 14:29:34 agenda+ Survey of SC Proposals: https://www.w3.org/2002/09/wbs/35422/March14SCReviews/results (15 minutes each maximum) 14:29:46 agenda+ Thursday call agenda items 14:31:21 regrets+ EA_Draffan, Shawn_Lauriat, Kathy_Wahlbin, Mike_Elledge, Neil_Milliken, Mark_Hakkinen, Jim_Smith 14:45:11 Wayne has joined #ag 14:46:05 present+ jasonjgw 14:55:31 laura has joined #ag 14:56:27 Rachael has joined #ag 14:56:34 scribe: Rachael 14:56:38 Wilco has joined #ag 14:56:41 present+ Rachael 14:57:18 MelanieP has joined #ag 14:58:24 regrets+ Jeanne_Spellman 14:58:24 Lisa_Seeman has joined #ag 14:59:36 present+ 14:59:53 present+ Wayne 14:59:56 present+ 15:00:00 alastairc has joined #ag 15:01:05 Greg has joined #ag 15:01:16 bruce_bailey has joined #ag 15:01:28 Jim_S has joined #ag 15:01:32 marcjohlic has joined #ag 15:01:45 adam_lund has joined #ag 15:01:45 present+ bruce-bailey 15:01:53 present+ Jim_S 15:02:32 present+ AdamLund 15:02:39 present+ marcjohlic 15:02:43 present+ Greg_Lowney 15:02:55 david-macdonald has joined #ag 15:02:56 JF has joined #ag 15:03:04 Present+ JF 15:03:08 present+ alastairc 15:03:16 agenda? 15:03:30 dboudreau has joined #ag 15:03:44 Glenda has joined #ag 15:03:59 present+ dboudreau 15:04:18 present+ MelaniePhilipp 15:04:29 present +Glenda 15:04:50 Jan has joined #ag 15:04:54 present+ Laura 15:05:01 KimD has joined #ag 15:05:09 present+ JanMcSorley 15:05:21 Present+ KimD 15:06:24 zakim, take up item 1 15:06:24 agendum 1. "ACTF: https://www.w3.org/2002/09/wbs/93339/ACTFrameworkFPWD/" taken up [from AWK] 15:07:09 Makoto has joined #ag 15:07:29 q+ 15:07:49 Q+ 15:07:56 AWK: Reminder that we are looking to put the ACT framework out as a first public working draft. We have had 6 people respond, all yes or yes with comments. We need comments back next week. We will discuss next week. Please take a look at the survey, read the editors draft and register your thoughts. 15:08:26 present+ Makoto 15:08:39 AWK: Evaluate for consensus on March 28th (ignore type in email) 15:10:00 Wilco: We've addressed the feedback that has come in and will continue to do so. The survey closes on Friday so get your comments in. We want to get some thoughts on the name of the document itself. We've had concern about the use of the word Framework becuase it implies something but we don't have a better word. 15:10:08 Wilco: IF you have suggestions, please include them. 15:10:16 allanj has joined #ag 15:10:33 JF: The survey shows 6 people have responded, 11 have not. Where is everyone else? 15:11:11 AWK: Because everyone is not part of the taskforce, the survey has been made public so the WG can respond. The 11 is the taskforce members. 15:11:20 JF: So anyone can respond, not just the taskforce? 15:11:23 AWK: Correct. 15:11:27 ack jf 15:11:28 ack wi 15:11:49 agenda+ COGA FPWD 15:11:50 q+ to ask about new items 15:11:51 zakim, take up item 2 15:11:51 agendum 2. "Reminder about GitHub issue updating for SC managers" taken up [from AWK] 15:11:56 zakim, take up item 5 15:11:56 agendum 5. "COGA FPWD" taken up [from AWK] 15:12:04 ack b 15:12:04 bruce_bailey, you wanted to ask about new items 15:12:33 bruce_bailey: Will we discuss the question at the top of the call? 15:12:39 AWK: We will get to it but later. 15:13:30 steverep has joined #ag 15:13:37 present+steverep 15:14:26 AWK: The COGA FPWD is also a reminder of an email you received about an hour ago. There are some COGA documents that we want to get out. They will not be normative. They are WG notes, but please take a look at the email. The goal is to get public feedback as it was with the 2.1 document. We will try to make a decision in conjunction with the platform architecture APA. Both groups have to agree its ready for FPWD. We will make a decision the week of April 10th. 15:14:41 zakim, take up item 2 15:14:41 agendum 2. "Reminder about GitHub issue updating for SC managers" taken up [from AWK] 15:15:10 Pietro has joined #ag 15:15:37 AWK: Github issue updating. I sent emails out last week. There are two parts, one in each email. If you are a SC manager, you need to go take a look at those steps. The best thing to do is to look at Issue #2. That is done and the model for what you need to do. 15:15:42 Thursday call agenda items 15:15:52 https://github.com/w3c/wcag21/issues/2 15:15:59 Present+ Pietro 15:16:02 s/Thursday call agenda items/ 15:16:09 Kirkwood_ has joined #AG 15:16:45 q+ 15:16:50 78 and 18 are also updated with the new links. 15:17:01 https://github.com/w3c/wcag21/issues/78 15:17:02 https://github.com/w3c/wcag21/issues/18 15:17:29 q- 15:17:36 AWK: Notice at the top, there are links (SC for viewing, etc) This will allow us to link directly to the places in GitHub where the issues are edited and viewed. When viewing, you will hopefully see a page that will scale as needed. I have a list of all the Success Criteria that still need this added. I will send that out. Thank you to those who took this on already to get it done. 15:17:38 Q+ 15:17:58 SC managers needed for: 6, 7, 20, 27, 34, 37, 40, 44, 46, 52, 61, 64 15:18:01 AWK: This is related to Lisa's question at the beginning. 15:19:02 Two emails: Subject: "Task for SC manager" second email: "Second task for SC managers" 15:19:11 Lisa_Seeman: Instructions are in the email? Can those be put in a single email with a very clear heading to make it easier to find? 15:19:17 Sent on March 15th 15:19:27 AWK: The first one is quite long and I think people need it broken into two emails. 15:19:29 Andrew’s instructions: https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JanMar/1200.html 15:19:52 https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JanMar/1202.html 15:21:09 Lisa: I recommend a wiki page somewhere. People will need to refer back. Something with all the instructions. Or you may need to do most of the COGA ones. 15:21:12 AW 15:21:30 AWK: I expect people to look at it and hope people can do it. 15:21:40 ack lisa 15:22:16 AWK: Has anyone tried and had difficulty with the instructions? 15:22:49 I am doing it right now, just by using Issue #2 as a guide 15:22:55 AWK: For many people, using Issue 2 as a model will be sufficient. If that is not the case, I tried to provide very detailed instructions. 15:23:08 zakim, take up item 3 15:23:08 agendum 3. "Survey of SC Proposals: https://www.w3.org/2002/09/wbs/35422/March14SCReviews/results (15 minutes each maximum)" taken up [from AWK] 15:23:30 q+ to ask about A vs AA vs AAA 15:23:51 https://www.w3.org/WAI/GL/wiki/WCAG_2.1_SC_status 15:24:14 AWK: We talked about #1 and 2 last week. I have put together a status section for the success criteria 15:24:18 topic: adapting text 15:24:35 s/topic:/TOPIC: 15:25:12 bruce_bailey: one of the themes is A vs AA. Do we have it written down what the A, AA, and AAA characteristics are. I feel like these are done by gut. 15:25:22 this is the page I would like updated: 15:25:23 https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Success_Criteria 15:25:44 AWK: I don't think we have that written as clearly as we woudl like. I think that there was not as clear a distinction between A and AA in WCAG 2.0. I think that is something that we should look at. 15:26:16 AWK: Does anyone volunteer to pull together what we have? I think we can defer that because we are discussing consensus at all vs what level they are at. 15:26:33 AWK: I think its a good point. One we need a better answer for. 15:26:37 I have to duck out in a minute, but for 3. Adapting Text - we need the people who think it should be general talk to the people who think it should be specific (testable on the face of the SC). 15:27:06 Bruce: Taking an action item to create a draft of this. 15:27:15 ACTION: Bruce to work on a definition of the a/aa/aaa levels 15:27:15 Created ACTION-337 - Work on a definition of the a/aa/aaa levels [on Bruce Bailey - due 2017-03-28]. 15:27:32 q+ 15:27:46 AWK: On the status page, adapting text is row #9. 15:28:43 ack b 15:28:43 bruce_bailey, you wanted to ask about A vs AA vs AAA 15:28:48 ack ala 15:28:49 AWK: The questions that are in here are mainly around testability and implementability. I would like us to update the status page as we work on them. 15:29:00 dboudreau has left #ag 15:29:03 +q 15:29:16 jamesn has joined #ag 15:29:21 dboudreau has joined #ag 15:30:02 rrsagent, make minutes 15:30:02 I have made the request to generate http://www.w3.org/2017/03/21-ag-minutes.html jamesn 15:30:02 q+ 15:30:06 Alastairc: The question is around specificity. The way we were coming at this, if you as an author tested changing the font then you should find the issues that would appear to anyone changing to any font other than the one you specified. 15:30:35 .me James, on https://www.w3.org/2002/09/wbs/35422/March14SCReviews/results#xq10 15:31:02 q+ 15:31:03 s/.me / 15:31:16 Laura: The rational for the hard coded metrics was that it cant be tested from true or false, it won't be successful as a test critera. If one person tests with one font and color and another tests with another font and different color, they will get different results. 15:31:40 ack la 15:32:36 ack mich 15:32:38 Laura: Wayne summed up the concern in the low vision community of having a hard metric value. Low vision people need flexibility. Ideally we need both flexibility and testability. The point of the SC is to avoid providing a mechanism. Low vision users need to apply their own style sheet without introducing barriers. 15:33:28 q+ 15:33:53 Michael: I get the reasoning behind wanting to specify a font but I don't fully agree with it. Understanding materials should recommend testing with a common font. If different fonts yield different results, then the SC is not accomplishing what it wants anyway. I would like to put the precision in the supporting materials. 15:33:55 ack wayne 15:34:39 +1 to NOT specifying a specific font as well 15:35:21 wayne: I do think it should be stated in more general terms. You should be able to change font, font family and colors to what you need. I think it would be easier to sell to developers that way - they can see what the need is. As far as testability, you can pick any two colors with sufficient color contrast, any wide text font and it will work. 15:35:49 I agree. I think we can solve this with a sufficient technique. So the SC is more general…but we have a technique that gives us consistency in testing results. 15:36:08 wayne: The problem that can occur is seen in high contrast settings in operating systems in the last few years. They are inserting a lot of decorative images. That is the kind of thing authors can do to get in the way. 15:36:11 ack awk 15:36:42 q+ 15:36:49 q+ to say Verdana is a vendor product 15:37:43 q+ to say I wasn´t concerned about the other hard metrics 15:37:50 Wayne and James: Discussion of picking 2 colors as test vs testing all colors. 15:39:02 AWK: I can see developers where they would create a widget that would let them change the font to verdana. Not a great way to do this but if the font is specified, they would say they that they met the standard. Also, with internationalization, we want this to function for languages other than english so specifiying font. 15:39:03 ack mi 15:39:03 MichaelC, you wanted to say Verdana is a vendor product and to say I wasn´t concerned about the other hard metrics 15:39:22 +1 to Michael C. 15:39:58 Michael: Verdana is also a vendor specific product though widespread. I wasn't concerned about the other metrics but I can agree with the need to make it as soft as possible. Normally we ask people to make it more testable but we are asking people to make it fuzzier. 15:40:12 Michael: I suggest dropping the last part and stick with font family. 15:40:34 q+ 15:40:49 q+ to ask if change to a sans-serif font? 15:40:55 +1 to don't be stupid in understanding 15:40:58 ack way 15:41:07 Discussion about what happens when change to a font family that isn't supported by teh language. Need to add some language about that. 15:41:29 Q+ 15:41:35 Wayne: I will start working on some tests that come out true or false. 15:41:37 ack bru 15:41:37 bruce_bailey, you wanted to ask if change to a sans-serif font? 15:42:15 Bruce: can we just specify a san serif or serif font but I don't know in the Arabic languages if that is a thing. 15:42:27 ack lisa 15:43:04 White on black was chosen because if that combination works, 99% of all other combinations should be able to be overridden. 15:43:05 q+ to say It sounds like people still disagree on whether this SC should require web pages to ensure their text can be customized, or merely to remain usable when and if text customization is applied. 15:43:05 Lisa: I think we've lost track of the wording on this one. With the current testability additions, we've lost the COGA use cases and we are relying on this. 15:43:42 q+ 15:43:43 q+ 15:44:11 Lisa: We need line spacing. I want to send this one to the COGA task force. If we go with the specifics, we need a font family that works for COGA as well as the line height and foreground and background. We may need a space between graphs as well. 15:44:12 ack greg 15:44:12 Greg, you wanted to say It sounds like people still disagree on whether this SC should require web pages to ensure their text can be customized, or merely to remain usable when and 15:44:15 ... if text customization is applied. 15:44:20 Lisa, Andrew, have made comments that make it sound like they think this SC requires web pages to support the specific configuration listed, but in reality the configuration(s) listed is merely testing instructions to verify that the page has the flexibility to accommodate a wide range of configurations. 15:44:26 q+ to remind this is about *these changes* don´t cause problems, but other SC may be at play 15:45:00 q+ 15:45:01 q+ to say I get what GL says but the SC will read otherwise to most users 15:45:15 q+ 15:45:29 Greg: This SC is not about a specific set of fonts, etc. Those are test instructions that ensure that more flexibility is provided. Do we have consensus that those are just test instructions? 15:45:48 ack me 15:45:48 MichaelC, you wanted to remind this is about *these changes* don´t cause problems, but other SC may be at play and to say I get what GL says but the SC will read otherwise to most 15:45:49 Greg: Is there anyone who is not interpreting the SC that way? 15:45:51 ... users 15:46:43 Michael: I think most readers will interpret it that way. Most of us know what you are trying to do. I agree with Lisa that the specifics themselves need to be accessible. I'm expecting this SC to interrelate with other SC. The more specific this is, the more tricky. 15:46:59 +q 15:47:05 Wayne: Should the SC be reworded to make that clearer to readers? 15:47:05 kirkwood has joined #AG 15:47:11 ack AWK 15:47:26 https://github.com/w3c/wcag21/issues/78#issuecomment-286442673 15:48:40 AWK: I was trying to reword it, when you create a webpage there is a mechanism that allows the user to adjust the technology. Either it works with an exisiting technology or build in a widget (not ideal but allowed). 15:49:12 AWK: My suggested rewrite is about making this SC about adapting text vs. specifying parameters. 15:49:21 q+ 15:49:28 Not about creating mechanisms. It is about personalization. 15:49:28 Agreed, but also explicitly requiring the web page to still be fully functional when the configuration is changed. 15:49:29 AWK: I think line and letter spacing is better than the other two. 15:49:39 q+ 15:49:45 q+ 15:49:46 q+ to say to say some of AWK wording works better, but should be not ¨a mechanism exists...¨ but ¨there is not loss of functionality when...¨ 15:49:52 q+ 15:49:56 +1 15:50:02 s/Agreed,/Andrew, I agree/ 15:50:28 ack wa 15:50:34 Laura: We had it more general to begin with and got pushback that developers would have to create widgets. 15:51:06 Authors only need to add widgets if they're using totally non-standard UI such as presenting their text as an image of text. 15:51:10 ack lisa 15:51:15 Wayne: I want to see this to be about allowing users to choose. We can work out tests that will be pretty accurate. Not 100% but we don't have that level agreement on every WCAG 2.0 item. We can write good tests. 15:51:46 Lisa: The way its worded now, if we have a white foreground and black text, they will not think they need to test. 15:52:01 AWK: Do you prefer the way I had worded it better? Last link in IRC. 15:53:13 Lisa: We are making this framework and offered to the Low Vision Taskforce to make it into a browser extension so that will exist. So if the concern is mechanism, we can do that. There will be a free download. That would be a way to make it testable. 15:53:19 ack lau 15:53:55 I like andrews wording better 15:53:57 ack mich 15:53:57 MichaelC, you wanted to say to say some of AWK wording works better, but should be not ¨a mechanism exists...¨ but ¨there is not loss of functionality when...¨ 15:53:58 Laura: White on black was chosen because it is easily overidden. The plan was to test with a bookmarklet which Alistair has already made. 15:54:06 Results of Bookmarklet Tests for Issue 78: https://www.w3.org/WAI/GL/wiki/Results_of_Bookmarklet_Tests_for_Issue_78 15:54:19 Michael: I think Andrew's wording comes up with the flexibility we are looking for. 15:54:41 Michael: I want to reword that if the users avail themselves of a mechanism it doesn't break. 15:54:45 Q+ 15:54:47 (iOS for example() 15:54:51 Laura, that's why as I said in my response that we should test with at least two different configurations, rather than one, to ensure that any one configuration is not hard-coded in. 15:54:57 AWK: If you have a tool that doesn't support changes? 15:55:03 q? 15:55:08 ack james 15:55:09 +1 to Michael 15:55:15 kirkwood_ has joined #AG 15:55:23 Michael: I thought this was that things don't break when you customize things vs. that you provide a way to customize. 15:55:51 James: I also read it as if the platform supports changes, the content needs to not that the platform must support changes. 15:55:55 +1 to michael 15:56:02 ack jas 15:56:33 Current SC text: https://rawgit.com/w3c/wcag21/adapting-text_ISSUE-74-78-79/guidelines/sc/21/adapting-text.html 15:57:31 interaccess has joined #ag 15:57:39 +1 15:57:40 JF: Andrew is leading this discussion in the right direction. I'm concerned about current wording. I object to defining a narrow test condition and including it in the SC. The SC should reflect the reasoning, the purpose that it serves. This helps with cases where the SC can't directly apply. I think the right approach is to push back against the objections that led to the current wording. 15:57:41 trackbot, start meeting 15:57:43 +1 to Michael's interpretation and the direction of AWK's suggested lang 15:57:44 RRSAgent, make logs public 15:57:47 Zakim, this will be WAI_WCAG 15:57:47 Meeting: Accessibility Guidelines Working Group Teleconference 15:57:47 Date: 21 March 2017 15:57:47 ok, trackbot 15:57:59 zakim, agenda? 15:57:59 I see 5 items remaining on the agenda: 15:58:00 1. ACTF: https://www.w3.org/2002/09/wbs/93339/ACTFrameworkFPWD/ [from AWK] 15:58:00 2. Reminder about GitHub issue updating for SC managers [from AWK] 15:58:00 3. Survey of SC Proposals: https://www.w3.org/2002/09/wbs/35422/March14SCReviews/results (15 minutes each maximum) [from AWK] 15:58:01 4. Thursday call agenda items [from AWK] 15:58:01 5. COGA FPWD [from AWK] 15:58:06 s/JF: Andrew/JF: Andrew 15:58:57 ack jf 15:59:03 JF: I think some people are misinterpretting it. I don't think the testability objection is viable. I have problems with current wording and objections. 15:59:28 +1 to Michael and to the direction of AWK's rewording of the SC 15:59:43 not what i said 16:00:09 jf: I am concerned that once we have the SC, we can build the widgets. I understand we have a chicken and egg problem. We need to get the tools circulated and in the hands of people before we standardize the tools. 16:00:37 It is just one way to make it ready, lots of solutions can be made by anyone 16:00:42 mainly the browser 16:01:13 the bigger concern should be meeting the user need 16:01:58 AWK: Laura, it seems there are more questions on this. Are we looking at this as a requirement that these have to be possible but if you are working with a platform that this doesn't exist there is an exception or that the customization has to be supported in some way. Do you have enough feedback to work on this going forward? 16:02:10 Laura: We will discuss it at the low vision task force meeting. 16:02:13 I think it's useful to talk about use cases. One is a pretty standard HTML page, which doesn't need to do anything. A second is a web page that includes graphical buttons, so it needs to make sure those are visible even when the colors and sizes are changed by browser settings. Third is a page that displays its text by drawing graphics into a live region that cannot be affected by browser... 16:02:14 ...settings, and it needs to provide its own settings to adjust the colors, etc. 16:02:26 RESOLUTION: No consensus yet 16:02:32 @Lisa, I agree, but just because we make a SC does not mean that browsers will all agree and make changes to their tools - WCAG cannot mandate software vendors to do *anything* (sadly) 16:02:50 TOPIC: User Interface Component Contrast (#6) 16:03:45 Current text for this SC: https://cdn.rawgit.com/w3c/wcag21/change-of-content_ISSUE-2/guidelines/sc/21/user-interface-component-contrast-minimum.html 16:03:46 AWK: We have 12 ready to go, 2 has significant issues. Michael and I both had concerns about the readability of the SC. Michael did you have specific questions that you want to bring up? 16:03:54 https://www.w3.org/2002/09/wbs/35422/March14SCReviews/results#xq9 16:04:26 Michael: I don't have anything specific besides not being able to understand. Too many subclauses to make sense of. 16:04:45 AWKL Glenda, with this one, can you in people speak say what this is accomplishing. 16:05:02 s/AWKL/AWK: 16:05:13 +1 to what MC says about needing a “thereof” in the SC text! 16:05:28 Glenda: Its complex. We are trying to make sure that anything that is essential for understanding that is visual but not text, has sufficient color contrast. 16:06:51 Glenda: We have one applying to graphics, and split this off. This is anything graphical that relates to the user interface. Examples: focus indicator, radio button selected/not selected, can you see the radio button? With apologies, in Gmail when I want to star an item, I have dificulty seeing the star outline. 16:06:59 q+ 16:07:16 AWK: To solve the problemm for the star in gmail, this SC would have you making it... 16:07:25 Glenda: Thicker or darker. 16:07:30 trackbot, draft minutes 16:07:30 Sorry, Joshue108, I don't understand 'trackbot, draft minutes'. Please refer to for help. 16:07:35 contrast on star is 1.4:1 16:07:38 zakim, draft minutes 16:07:38 I don't understand 'draft minutes', Joshue108 16:07:48 AWK: If it is thicker, it can ge away with a lower contrast ratio? 16:08:05 rrsagent, make minutes 16:08:05 I have made the request to generate http://www.w3.org/2017/03/21-ag-minutes.html laura 16:08:17 kirkwood has joined #AG 16:08:20 s/problemm/problem 16:08:25 q+ 16:08:42 Glenda: yes. Large text is difficult to define. WCAG 2.0 went with 14 pt bold and 18tpt. Research shows these are approximately 3 pixels wide. We went with how WCAG 2.0 handleed text. 16:09:52 Glenda talking about comment on GitHub: https://github.com/w3c/wcag21/issues/10#issuecomment-287120439 16:10:03 q+ to offer a rephrasing "All _important visual elements_ have a contrast ratio of at least x:y against their immediate surrounding colors(s), with the following exceptions:" 16:10:14 ack michael 16:10:24 Glenda: The question brought up on borders still needs discussion. What is essential is also a great question but something we struggle with in WCAG 2.0. 16:10:52 Michael: I've worked on some possible wording. 16:11:04 proposed: The visual presentation of essential graphical objects, border line, focus indicators, and selection indicators for user interface components has a contrast ratio of at least 4.5:1 against the immediate surrounding color(s), except for the situations listed below: 16:11:13 q+ 16:11:16 ack james 16:11:22 Glenda: It will take me sitting down with a few other people and make sure nothign got lost but I appreciate you doing that. 16:12:07 q+ 16:12:37 +1 It would simolify the SC a lot too 16:12:45 James: I have trouble justifying the ratio as 4.5:1. In text, you have to be able to read the text. In a border, you don't need the same level of readability. Using 4.5 ratio, limits designers. I think using a 3:1 ratio and removing the sizing requirements will better support designers and the needed support. 16:12:56 zakim, q? 16:12:56 I see Greg, Lisa_Seeman, Wayne on the speaker queue 16:12:58 +1 totally agree, 4.5:1 is too restrictive to designers 16:13:30 q+ to ask if we make exception for elements conform to 2.4.7 Focus Visible? 16:13:38 James: We need something. Determining a border, is a lower requirement. For example, a border around a text field. 16:14:09 James: I know there are a lot of terrible stuff out on the web, but usually its in the 1-2 range. 16:14:11 I disagree that 4.5 to 1 is too restrictive for designers… it’s just a matter of working around some constraints 16:14:25 the star I think is 1.4:1 16:14:26 In gmail the ratio is 1.67:1 for the star 16:14:47 Glenda: If you go to Gmail and look at the star, I can't see it. Its large. 16:14:51 it's 1pixel wide, too 16:15:03 The star is 1 px wide and 1.67:1 16:15:11 ack greg 16:15:11 Greg, you wanted to offer a rephrasing "All _important visual elements_ have a contrast ratio of at least x:y against their immediate surrounding colors(s), with the following 16:15:14 ... exceptions:" 16:15:56 Worth noting that we have a definition of "essential" 16:16:09 kirkwood has joined #AG 16:16:27 The issues with this proposal can be broken down into (a) readability, (b) specific contrast ratios, (c) specific list of what those ratios should apply to. 16:16:50 Greg: I also added a proposed rewrite for clarity. Moving the list of things to glossary entry. I think its useful to summarize criticism: Readability, specific contrast ratio, what are the specific list of things the ratio should be applied to. It would be useful to break these out into seperate threads. 16:17:03 Greg: It would help us see when we have consensus on any category. 16:17:03 q+ to speak to getting to consensus on an SC 16:17:07 “including when the page is scrolled” is ambiguous. 16:17:24 s/The rational for the hard coded metrics was that it cant be tested from true or false, it won't be successful as a test critera./rationale of the hard-coded metrics was if it can't be tested true or false from the SC text, it won't meet the SC testability criteria./ 16:17:25 ack lisa 16:17:29 Greg: Phrase: "including when the page is scrolled" is confusing and I'd like to see that reworked. 16:18:55 rrsagent, make minutes 16:18:55 I have made the request to generate http://www.w3.org/2017/03/21-ag-minutes.html laura 16:19:23 Lisa: There is a common thread through many of the COGA criteria where we are defining what the most important information is. "critical features", "important information", etc. Should we get a subgroup together to come up with clear definitions of three different scopes. Level 1: High contrast, personalization, etc. I think we don't want to address the same thing in different ways across success criteria. 16:20:12 Lisa: Once you've got scope A, you know that includes critical features. You can define them once and apply them to the guidelines. Define scope and then SC managers can apply them. 16:20:30 s/without introducing barriers./without authors introducing barriers./ 16:21:11 Glenda: I think the right approach right now is to use a term that works for low vision right now and then work the issue. I feel more comfortable with essential right now. 16:21:49 Lisa: I think its helpful to create a definition. 16:22:11 Glenda: I'm concerned about it slowing down. 16:22:57 q+ 16:22:58 AWK: I'm concerned that this is a change from WCAG 2.0 where there is essential and non-essential. May be better for Silver. Lisa - consider working with Bruce on A, AA, AAA 16:23:28 ack way 16:23:33 AWK: We had fairly extensive testing done around color contrast. It can get dicey. Note: find earlier research. 16:24:46 ack bruc 16:24:46 bruce_bailey, you wanted to ask if we make exception for elements conform to 2.4.7 Focus Visible? 16:24:56 Wayne: The ability to find essential information (It is defined in WCAG), is important. I think designers have decided that a certain look is needed but I think as a group we need to push back. Its like wheelchair ramps. People use to think buildings didn't look right with ramps. From time to time we should push back on developers. 16:25:04 Quick test, This button has 3.2:1 contrast about http://davidmacd.com/test/button.html 16:25:30 not everybody uses AT 16:25:38 Bruce: Does anyone disagree that the default cursor and focus indicator will be excepted? 16:26:40 Oreo selection inspired by Apple http://www.glendathegood.com/a11y/lvtf/textinputborder.html 16:26:40 +1 to Glenda - a default focus indication of black marching ants against a dark-blue background fails pretty much everyone... 16:26:43 is Chrome/Safari's one ok? 16:27:16 kirkwood_ has joined #AG 16:28:04 ack david 16:28:33 Glenda: The browsers need to better support focus. The focus indicator passes. 16:28:58 I set the following config preferences in FF (browser.display.focus_ring_on_anything;true and browser.display.focus_ring_width;5) 16:29:09 David: If we can simplify the contrast ratio, we should do so. 16:29:10 makes a really big focus indicator on anything 16:29:10 zakim, agenda? 16:29:10 I see 5 items remaining on the agenda: 16:29:12 1. ACTF: https://www.w3.org/2002/09/wbs/93339/ACTFrameworkFPWD/ [from AWK] 16:29:12 2. Reminder about GitHub issue updating for SC managers [from AWK] 16:29:12 3. Survey of SC Proposals: https://www.w3.org/2002/09/wbs/35422/March14SCReviews/results (15 minutes each maximum) [from AWK] 16:29:12 4. Thursday call agenda items [from AWK] 16:29:13 5. COGA FPWD [from AWK] 16:29:19 authors can can change focus indicator in the browser. They can make it worse than the default (as in no indicator), or they can make it better. They have control. the Cursor for input fields is not in author control 16:29:55 Personalization 16:30:15 AWK: Does anything to need to be discussed at the Thursday meeting? 16:30:35 q+ 16:30:36 thursday topic: User agent support - where to draw the line 16:30:46 Lisa: Personalization needs to be discussed but was discussed last week. 16:31:16 Luminosity Brightness of Enabled/Disabled Form Controls using default browser styling http://w3c.github.io/low-vision-SC/luminosity-form-controls.html 16:31:37 Glenda: Quick item for future agenda: the clause about when the page scrolls, applies to all success criteria. Does the success criteria apply to all states of the page. 16:32:18 It would be good to define customisation vs personalisation, e.g. point 4 in here: https://alastairc.ac/2017/02/four-levels-of-accessibility-customisation/ 16:32:23 kirkwood has joined #AG 16:32:29 bye 16:32:36 trackbot, end meeting 16:32:36 Zakim, list attendees 16:32:36 As of this point the attendees have been AWK, jasonjgw, Rachael, Wilco, Wayne, MichaelC, bruce-bailey, Jim_S, AdamLund, marcjohlic, Greg_Lowney, JF, alastairc, dboudreau, 16:32:39 ... MelaniePhilipp, Laura, JanMcSorley, KimD, Makoto, steverep, Pietro 16:32:44 RRSAgent, please draft minutes 16:32:44 I have made the request to generate http://www.w3.org/2017/03/21-ag-minutes.html trackbot 16:32:45 RRSAgent, bye 16:32:45 I see 1 open action item saved in http://www.w3.org/2017/03/21-ag-actions.rdf : 16:32:45 ACTION: Bruce to work on a definition of the a/aa/aaa levels [1] 16:32:45 recorded in http://www.w3.org/2017/03/21-ag-irc#T15-27-15