15:29:28 RRSAgent has joined #ag 15:29:28 logging to http://www.w3.org/2017/08/03-ag-irc 15:29:30 RRSAgent, make logs public 15:29:30 Zakim has joined #ag 15:29:32 Zakim, this will be WAI_WCAG 15:29:32 ok, trackbot 15:29:33 Meeting: Accessibility Guidelines Working Group Teleconference 15:29:33 Date: 03 August 2017 15:29:36 Chair: AWK 15:29:45 +AWK 15:29:57 RRSAgent, set logs public 15:30:09 agenda+ Plain Language: https://www.w3.org/2002/09/wbs/35422/sc_august2017 (only item 2) 15:30:22 agenda+ Concurrent Input Methods:https://www.w3.org/2002/09/wbs/35422/MATFSC_june/results (item 3 only) 15:30:34 agenda+ Personalization: https://www.w3.org/2002/09/wbs/35422/LatestPersonalization/results 15:30:40 Rachael has joined #ag 15:31:05 agenda+ keeping comments brief 15:31:16 Zakim, agenda order is 4, 1,2,3 15:31:16 ok, AWK 15:33:47 present+ Rachael 15:34:39 Kathy has joined #ag 15:35:36 present+ 15:35:37 present+ Joshue108 15:35:48 present+ JF 15:36:49 scribe: Kathy 15:37:04 Zakim, next item 15:37:04 agendum 4. "keeping comments brief" taken up [from AWK] 15:37:13 present+ 15:37:31 Andrew: please keep comments brief 15:37:47 zakim, next item 15:37:47 agendum 4 was just opened, AWK 15:37:48 zakim, next item 15:37:49 agendum 4 was just opened, Kathy 15:37:53 zakim, close this item 15:37:53 agendum 4 closed 15:37:54 I see 3 items remaining on the agenda; the next one is 15:37:54 1. Plain Language: https://www.w3.org/2002/09/wbs/35422/sc_august2017 (only item 2) [from AWK] 15:37:56 Zakim, close item 4 15:37:56 agendum 4, keeping comments brief, closed 15:37:57 I see 3 items remaining on the agenda; the next one is 15:37:57 1. Plain Language: https://www.w3.org/2002/09/wbs/35422/sc_august2017 (only item 2) [from AWK] 15:38:01 zakim, next item 15:38:01 agendum 1. "Plain Language: https://www.w3.org/2002/09/wbs/35422/sc_august2017 (only item 2)" taken up [from AWK] 15:38:02 Alex has joined #ag 15:38:09 q+ 15:38:32 Andrew - we have discussed this one before 15:39:06 Lisa - some things that changed, we removed double negatives, we addressed the international concerns and concrete language 15:39:23 ack li 15:39:26 q+ 15:39:27 ... we could reduce scope but for AAA feel that it is ok 15:39:43 Q+ 15:39:43 https://www.google.co.il/search?client=firefox-b-ab&q=core+vocabulary+french&spell=1&sa=X&ved=0ahUKEwj_3uqysrvVAhXKAMAKHXMuAM4QvwUIISgA&biw=1366&bih=657 15:39:46 .... common words are core vocabularies and exists in all languages 15:40:10 ... these are public 15:40:35 https://github.com/w3c/wcag21/issues/30 15:40:57 ... issue 30 for single A we have some scripts to generate a core vocabularity 15:41:11 ... there will be a place to generate if it is not available 15:41:22 ack AWK 15:41:34 I heard AAA mentioned, but the text shows A - is this still being proposed for A or AAA now? (Or are there two proposals) 15:41:36 gowerm has joined #ag 15:41:39 present+ MikeGower 15:41:42 should be AAA 15:41:47 Thanks 15:41:54 Andrew - while I did change the survey to say AAA, the github version still says A but it is AAA 15:41:55 ack JF 15:42:18 JF - there is a strong linkage between this SC and controls personalization 15:42:27 ... we are looking at fixed taxonomy 15:43:07 ... not clear how this would be provided to the site. We need a linkage of that list to the SC. Just because it is out there is not enough 15:43:23 AWK updated in Github to AAA 15:43:31 q? 15:43:45 ... we need the word list to be programmatically linked to the site 15:43:56 ... this may be just wordsmithing 15:44:07 KimD has joined #ag 15:44:29 Lisa - do you think this needs to in the SC 15:44:34 q? 15:44:34 JF - yes 15:44:40 q+ 15:45:02 ack ala 15:45:36 Alastair - was going to suggest the opposite to remove the latter part. At AAA we can have some subjectivity 15:45:52 ... do we really need it 15:45:55 q+ 15:45:57 Lisa - happy with either way 15:46:17 david-macdonald has joined #ag 15:46:18 ack gower 15:46:19 Q+ 15:46:29 q+ 15:46:31 Kim has joined #ag 15:46:32 present+ david-macdonald 15:47:03 Present+ KimD 15:47:05 Mike - echo that, there is no clear correlation between common word list and simple and clear terminology 15:47:15 present+ alastairc 15:47:38 Lisa - people don't always know the clearest word 15:47:44 ack JF 15:47:45 q+ 15:48:05 John - if we water this down too much we will not have anything 15:48:22 ... what we want is a linked definition of those words and phrases 15:48:47 Lisa - it is complicated going in that direction 15:49:07 ... the definitions are not always in the lit 15:49:19 ... it is a word that people have learned 15:50:05 ... if you have the definition then people will be using it in the correct way. It is for the author not the user 15:50:18 ... that the author is using it in the right context 15:50:58 ... we said provide words then we can have a plug in that will replace the words 15:51:10 q? 15:51:20 JF - what is the difference in this to personalization 15:51:48 Lisa - this is one way to satisfy personalization 15:52:09 ack AWK 15:52:09 q+ 15:52:13 ... we have limited scope in personalization 15:52:23 @JF - personalisation is different in scope of what it's on (controls etc), and intent of the change (visible text). 15:52:35 Q+ 15:52:37 AWK - we saying all we need is a list of the words. The definitions are not needed 15:53:08 ... what we should have is a explicit link to the term 15:53:22 Lisa - could go either way 15:53:32 JF - how do we know what public list 15:53:36 ack alex 15:53:55 Lisa - we need to identify it and put in conformance statement 15:54:24 Alex - remind WCAG 2.0 needs to be testable for all levels 15:54:34 +1 to Alex 15:54:50 Lisa - then that is an argument to have a linked list 15:54:58 ack gower 15:55:19 Mike - look at 2.4.6, how is that tested 15:55:38 Alex - doesn't say how descriptive it needs to be 15:56:00 Clear Instructions: Instructions describe the topic or purpose. 15:56:11 q+ 15:56:48 q+ 15:57:05 Mike - clear instructions is an ok way to test; so go with the same language for this SC 15:57:06 ack JF 15:57:13 ack l 15:57:21 q+ 15:57:32 JF - Alex is right, this needs to be testable. Introducing "common" and it is ambigous 15:58:07 ... for heading and labels we are not talking about what is descriptive. We cannot fail if a heading or label is there 15:58:23 ... there are multiple common lists there. How do we know which one it is 15:58:36 ... how do I test based on the public list 15:58:43 Use the most common 1500 words or phrases or, provide words, phrases or abbreviations that are the most-common form to refer to the concept in the identified context. 15:58:56 Lisa - we have gone through a number of iterations 15:58:59 Perhaps "Provide common words, phrases, or abbreviations that are identified on a linked public word frequency list when possible" 15:59:36 ... if that is the only issue, then we should reword the bullet point to make it testable 15:59:53 ... are there other issues 16:00:08 Perhaps "Provide common words, phrases, or abbreviations that are identified on a linked public word frequency list unless terms needed for comprehension are not available on a list" 16:00:22 ack jas 16:00:24 Q+ 16:01:39 Jason - frequency list means a list of words and phrases based on frequency in a sample of text and then order them 16:01:48 deffinition is at https://rawgit.com/w3c/wcag21/plain-language-minimum_ISSUE-30/guidelines/terms/21/identified-context.html 16:02:08 ... there will be common words for each language because they are part of the grammar but it is dependent on the sample 16:02:11 Word lists by frequency are lists of a language's words grouped by frequency of occurrence within some given text corpus from the same context. Examples of a context include a dialect, subject matter or profession. A word frequency list has to be generated from at least 1000 sources from the same context although 50,000 sources is recommended . the word frequency list and he context should... 16:02:11 ...be identified in the sites meta data, or in an accessibility statement or by some other known technique. 16:02:33 ... the list doesn't have to meet any requirements 16:02:42 ... that is an essential part 16:02:50 scribe: Rachael 16:02:57 Lisa: Jason, did you see the definition? 16:02:59 Jason: yes 16:03:18 Lisa: The definition of what the corpus needs to be. 16:03:30 +1 to Jason 16:03:49 Jason: There may not be a strong correlation between being on the list and what users area likely to know. Its a complicated problem and I don't think we'll solve it in a hurry. 16:03:54 ack lisa 16:04:56 Lisa: We've been working on it for three years, so not in a hurry. The evidence that this will have impact is hard to dispute but what I'd like to do is try to bring Jason, John and others who are unhappy with this together on a call to reach consensus on wording. \ 16:05:01 ack JF 16:05:17 thanks John\ 16:05:39 +1 "word frequency" not helpful 16:06:39 John: I'm happy to help with this. I don't think we are solving the problem with a word frequency list. You give an example of the word mode. I argue that mode will be on frequency lists because it is used frequency. It was unclear how it was being used. It isn't about frequency of use. Its about making sure users understand what the words used mean. 16:07:11 John: I think we want to make sure users understand how to interact with controls. I don't think common words will solve that problem. 16:07:34 AWK: If you would like to participate in that conversation, contact Lisa. 16:07:43 RESOLUTION: No consensus yet. 16:07:49 Zakim, next item 16:07:49 agendum 2. "Concurrent Input Methods:https://www.w3.org/2002/09/wbs/35422/MATFSC_june/results (item 3 only)" taken up [from AWK] 16:08:37 AWK: Number 2 in this survey. Very mixed responses. Core issue: question around whether this was specific to users with disabilities and what use cases highlight that 16:08:46 Issue: https://github.com/w3c/wcag21/issues/64 16:08:47 Created ISSUE-50 - Https://github.com/w3c/wcag21/issues/64. Please complete additional details at . 16:09:03 https://github.com/w3c/wcag21/issues/64 16:09:13 current text: https://rawgit.com/w3c/wcag21/concurrent-input-mechanisms_ISSUE-64/guidelines/sc/21/concurrent-input-mechanisms.html 16:09:22 Kim: I think there were 3 things. There are three use cases in the link provided. There are two other issues. 16:09:39 Kim: One was scope, so we fixed that. See current language. And testability was the final issue. 16:10:59 Chris: Testability issue: We have concurrent input mechanisms. We want to be able to suppor input mechansim A-C but how do we support a combination? I think if you support the individual mechanisms then the user agent should adderss the switch. 16:11:49 Chris: The content author would support the individual input mechanisms only. If a failure occurs in combination,then its a user agent or operating system failure. 16:12:31 Kim: We switched the wording back based on previous conversation. We are not restricting it. We do have the security exception included. 16:12:38 AWK: What are a couple of use cases? 16:12:51 q+ 16:13:24 Kim: 2.1.1 covers keyboard access.So we can switch to keyboard access but we may not be able to switch to touch. This use case should allow user to switch to touch or go from mouse to touch and touch to keyboard. 16:13:56 Kim: You can restrict to touch only in mobile. This does happen, I hit it on a client site yesterday. 16:15:15 Chris: There are two other use cases. I use speach to interact and if I run into a situation where I can't use speech and touch its an issue (There is a known issue in MACs that isn't web but exists). 16:16:01 The third use case is when you can't get keyboard focus, you can use the mouse so one use case is the need to fallback on the mouse. 16:16:38 ack david 16:16:41 Sometimes we need to fall back when something fails, so adding another restriction on the fallbacks creates an issue. 16:17:36 q+ 16:17:48 David: I agree people switch modalities. I do myself all the time. We've narrowed the scope but I don't understand how we reconcile what the failure techniques? What are the dumb things authors do to cause this? 16:18:17 q+ 16:18:39 q+ 16:18:46 Kim: This is anything you can do in keyboard but not in touch. 16:18:54 q+ to say that if adopting this we would want to change "action" to functionality and allow for slightly different processes to achieve a common end point 16:19:15 ack gower 16:19:19 David: Are we saying the author has to actively ensure it works with keyboard and touch? 16:19:22 q+ 16:19:58 MikeG: How is someone supposed to test this? I unplug my headset and it stops playing. How does the tester know if its a hardware, OS, or site issue? 16:20:28 MikeG: If you put in a headset, its not smooth. When does it stop supporting? Is this even relevant? 16:21:23 Kim: We aren't saying you have to test it with all combinations. We are just saying you haven't restricted it by for example, using only touch or using only keyboard 16:21:39 MikeG: You are going to fail things if they are only can be done by keyboard? 16:21:45 Kim: yes, that would fail. 16:21:58 John: How do I know? 16:22:51 "Web pages do not restrict user input modalities available on a platform. Exception for security or essential nature of activity" 16:22:52 John: I don't know what the users using. How do I know? WE have a long standing requirements that at a minimum you must be able to use the keyboard. Its one of our first tests. Now you say that if they can get through with hte keyboard, you're going to fail it? 16:23:34 I agree we need to support additional modes but failing something because only a keyboard can be used seems problematic. 16:24:32 Alex: Is there a reason why there is no essential exception here? If the particular functionality of a page is to record audio, you need a microphone. 16:24:39 Kim: WE added that exception from the last call. 16:24:47 Alex: Looking at wrong text. 16:25:27 AWK: WE will link ot the text to ensure it is only in one place. Its caused more issues than solving. 16:25:58 Alex: #2 Can you put in IRC a link of a website with a gregious violation of this and tell us how it fails? 16:26:19 Kim: Nothing I can share publicly 16:26:25 q+ 16:26:29 ack alex 16:26:41 Kim: We can provide a list or create examples. We didn't link to exact code. 16:26:57 Alex: I think you should at least create one. 16:27:46 "support multiple forms of input / do not block alternative forms of input" (???) 16:27:58 I think the use of "is not restricted by the content" provides the language we need to constrain this. 16:28:09 +1 Mike 16:28:13 Kim: Keyboard is not the primary input anymore. Saying that all we require is keyboard I find problematic. There is a lot of concern around touch so we created an SC that says you need to support multiple modalities to address this. 16:28:37 ack jason 16:28:37 Kim: This is an attempt to integrate a fix 16:28:41 q- 16:31:18 Jason: I'm looking at this and probably should rewrite the survey comments. IT says nonrestricted - is that meant to be more than preventive? Just looking at the clauses, it seems hard to find a really serious issue that this addresses which is not a user agent or operating system issue 16:31:59 q+ 16:32:06 Jason: It isn't clear what it is trying to resolve. Its tightly written and specified which is good but hte lack of clarity is challenging. 16:32:20 Web pages do not restrict user input modalities available on a platform. Exception for security or essential nature of activity 16:33:09 AWK: I had put in some language that may solve hte problem or take us back. Would it help to say "Web pages do not restrict user input modalities available on a platform. Exception for security or essential nature of activity" ad then add restrictions or exceptions. 16:33:23 +1 to Andrew 16:33:33 I think we still have the issue of having good examples. 16:33:35 ack AWK 16:33:35 AWK, you wanted to say that if adopting this we would want to change "action" to functionality and allow for slightly different processes to achieve a common end point and to 16:34:23 ack david 16:34:26 AWK: Is it endless? How would you undermine this goal using scripting on web/mobile, how many modalities can you shut down? 16:35:45 David: I think you language is more in keeping in whether the author has done a dumb thing. The other thing is do we want to have a success criteria requiring pointer? We decided not to pursue this but I think you are saying everything should work with pointer and with voice. 16:35:49 Web pages do not restrict user input modalities available on a platform unless it would jeopardize the security of the content or invalidate the action. 16:36:14 I don't think we have time to address the pointer issue. 16:36:21 q+ 16:36:27 +1 16:36:33 JF: Agree with Kathy's suggestoin "Web pages do not restrict user input modalities available on a platform unless it would jeopardize the security of the content or invalidate the action." 16:36:38 David: Yes 16:36:42 +1 16:36:48 +1 16:37:13 still need to see an example 16:37:17 Web pages do not ACTIVELY restrict... 16:37:18 AWK: I would want to look at it more but yeah. I think the advantage is that we are thinking about current modalities but this has a certain amount of future proofing as well. 16:37:55 david: add actively "Web pages do not actively restrict user input modalities available on a platform unless it would jeopardize the security of the content or invalidate the action." 16:38:18 will thins include blaocking web extentions? 16:38:25 AWK: Lets play with the language a little on the list. We are close. People are already dropping off. 16:39:30 AWK: I can stay to wordsmith but we can't decide to CFC after call is closed. 16:39:47 zakim, list attendees 16:39:47 As of this point the attendees have been AWK, Rachael, Kathy, Joshue108, JF, shadi, MikeGower, david-macdonald, KimD, alastairc 16:39:53 Kathy: Wording has been updated. 16:42:14 Web content does not restrict user input modalities available on a platform unless it would jeopardize the security of the content or invalidate the action. 16:42:19 Web pages do not prevent use of any user input modalities available on a platform. Exception ... 16:42:49 Web content does not prevent ... 16:43:03 chriscm has joined #ag 16:44:41 Web content instead of web page could help 16:45:32 The page is the evaluation unit though 16:45:44 "Web pages do not prevent use of any user input modalities available on a platform" 16:47:26 Web content does not restrict user input modalities available on a platform unless it would jeopardize the security of the content, invalidate the action, or override a user setting 16:47:56 Web content does not restrict user input modalities available on a platform unless it would jeopardize the security of the content, invalidate an activity, or override a user setting. 16:48:05 q? 16:48:27 ack li 16:48:36 q+ 16:49:09 how about "Web pages do not prevent user input modalities available on a platform" 16:49:57 -q 16:50:16 Sorry, I see Kathy has made a change like that.. 16:51:11 Q+ 16:54:22 As a User with comprehension issues associated to language (terms and usage), I require the ability to: a) easily determine or get the definion of terms and words used on 'critical' (conventional?) controls and inputs (AA) b) easily find or access extended help explanations for inputs, controls and error messages (AAA) c) convert common terms and instructions to other modes of expression (eg. convert form control labels to symbols) (AAA) Techniques: All techni 16:57:15 All functionality requiring specific device sensor information can be operated with pointer, unless the device sensor is essential for the function and not using it would invalidate the activity. 16:57:47 trackbot, end meeting 16:57:47 Zakim, list attendees 16:57:47 As of this point the attendees have been AWK, Rachael, Kathy, Joshue108, JF, shadi, MikeGower, david-macdonald, KimD, alastairc 16:57:55 RRSAgent, please draft minutes 16:57:55 I have made the request to generate http://www.w3.org/2017/08/03-ag-minutes.html trackbot 16:57:56 RRSAgent, bye 16:57:56 I see no action items