17:42:22 RRSAgent has joined #ua 17:42:22 logging to http://www.w3.org/2014/01/23-ua-irc 17:42:24 RRSAgent, make logs public 17:42:24 Zakim has joined #ua 17:42:26 Zakim, this will be WAI_UAWG 17:42:26 ok, trackbot; I see WAI_UAWG()1:00PM scheduled to start in 18 minutes 17:42:27 Meeting: User Agent Accessibility Guidelines Working Group Teleconference 17:42:28 Date: 23 January 2014 17:45:39 Agenda+ Longdesc review 17:45:41 agenda+ review comments - 17:45:42 Microsoft - http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0002.html 17:45:44 Silas - 1.4 comments http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0000.html 17:45:45 Chrome - http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0001.html 17:45:47 EO - http://www.w3.org/WAI/EO/wiki/UAAG_review 17:45:48 Wayne Comments - http://lists.w3.org/Archives/Public/public-uaag2-comments/2013Dec/0000.html 17:45:50 Main Comment Gateway - http://lists.w3.org/Archives/Public/public-uaag2-comments/2013Dec/ 17:46:24 allanj has joined #ua 17:46:41 rrsagent, set logs public 17:46:50 rrsagent, make minutes 17:46:50 I have made the request to generate http://www.w3.org/2014/01/23-ua-minutes.html allanj 17:47:27 regrets: Kim 17:47:36 chair: JimAllan, KellyFord 17:50:29 Agenda+ review comments 17:50:40 zakim, agenda: 17:50:40 I don't understand 'agenda:', allanj 17:50:44 zakim, agenda? 17:50:44 I see 3 items remaining on the agenda: 17:50:45 1. Longdesc review [from kford] 17:50:45 2. review comments - [from kford] 17:50:45 3. review comments [from allanj] 17:50:59 zakim, close item 3 17:50:59 agendum 3, review comments, closed 17:51:00 I see 2 items remaining on the agenda; the next one is 17:51:00 1. Longdesc review [from kford] 17:59:11 jeanne has joined #ua 17:59:46 WAI_UAWG()1:00PM has now started 17:59:53 +Jim_Allan 18:00:43 +[Microsoft] 18:01:04 Greg has joined #ua 18:01:06 zakim, Microsoft is really KellyFord 18:01:07 +KellyFord; got it 18:01:11 zakim, microsoft is kford 18:01:13 sorry, kford, I do not recognize a party named 'microsoft' 18:01:31 +Greg_Lowney 18:02:52 +Jeanne 18:03:06 Jan has joined #ua 18:03:15 zakim, code? 18:03:15 the conference code is 82941 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), Jan 18:03:41 +[IPcaller] 18:04:28 zakim, [IPcaller] is really Jan 18:04:28 +Jan; got it 18:04:44 zakim, agenda? 18:04:44 I see 2 items remaining on the agenda: 18:04:45 1. Longdesc review [from kford] 18:04:45 2. review comments - [from kford] 18:05:04 zakim, open item 1 18:05:04 agendum 1. "Longdesc review" taken up [from kford] 18:05:13 https://dvcs.w3.org/hg/html-proposals/raw-file/default/longdesc1/longdesc.html 18:05:37 greg preliminary comments - http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JanMar/0017.html 18:06:55 acribe: kford 18:06:59 Scribe: kford 18:07:16 JA: So we have the new longdesc proposal. 18:07:23 JA and JS talk briefly. 18:07:35 GL: Have people had a chance to read my draft? 18:07:44 JA: Yes, I read it and was going through it. 18:08:04 GL: Do you want me to read all or what? 18:08:27 JR: I've read but would be good to go one by one to hear if people have feedback. 18:08:39 GL goes over his items. 18:08:40 gl: comment1 18:08:44 *1. Use Case keywords seem random:* In the section on Use Cases, the Requires and Helped By keywords (which link to appropriate entries in "Requirements for an Image Description Functionality") are a nice touch. However, I can't understand the choices made as to which keywords are listed for each use case. For example, why would Discountability be important for "Identifying a well-known... 18:08:45 ...image", but not for "Describing a complex diagram", or why would Simple Return be useful for the latter but not the former? 18:09:21 GL: Neat idea in theory but in practice a challenge. 18:09:28 JA and JR agree as does kford. 18:09:41 gl comment: *2. Contrast with ARIA DescribedBy:* The use case "Referring to an existing description" sounds like exactly what ARIA DescribedBy is used for, so it might be good to clarify why longdesc is also needed, and whether you're recommending one or both be used. 18:10:20 JR explains that ARIADescribedBy has to be on the existing page. 18:11:03 JS: Keep in mind that ARIA applies to more than HTML. 18:11:40 JR: I know that CG has a activity looking at where ARIA should apply. 18:11:50 @@ comment 1 is mostly editorial 18:13:28 "Consider adding some acknowledgement that longdesc is functionally equivalent to ARIA DescribedBy (for in-page links) and the proposed ARIA DescribedAt (for interpage links)." ? 18:14:44 Group has concerns about some items missing. 18:15:05 JS: Given how late in the process this document is I think w4e need to focus our comments. 18:15:22 JS: We need to focus on items we are not able to live with. 18:16:55 Some discussion on how to structure comments back. 18:17:34 GL: I don't think it makes sense for this document not to explain why they are creating something that on the surface seems it is duplicating something that already exists. 18:18:16 GL: It is like if someone came and proposed something that seemed to duplicate ARIA. Wouldn't we ask what's up? 18:18:34 JA: This is a much-discussed topic. 18:18:57 JA: At onepoint longdesc was considered gone but has been recently revivied. 18:20:35 gl comment *3. Other image types:* I don't understand the decision to allow the new longdesc to apply only to img elements, as it seems to be just as appropriate for things like groups of images (which may make up one whole image as far as the user is concerned), svg elements, objects, and even tables or arrangements of colored divs. Can you please explain the rationale for not allowing it... 18:20:36 No real issues heard with GL item 2. 18:20:36 ...on other elements? 18:21:04 @@ comment 3 !important 18:21:36 Group talking about how it would be helpful to have this ability on other elements. 18:21:49 "3. Other image types: I don't understand the decision to allow the new longdesc to apply only to img elements, as it seems to be just as appropriate for things like groups of images (which may make up one whole image as far as the user is concerned), svg elements, objects, and even tables or arrangements of colored divs. We recommend allowing longdesc to apply to other elements such as svg." 18:22:20 "3. Other image types: I don't understand the decision to allow the new longdesc to apply only to img elements, as it seems to be just as appropriate for things like groups of images (which may make up one whole image as far as the user is concerned), svg elements, objects, and even tables or arrangements of colored divs. We recommend allowing longdesc to apply to other elements." 18:22:47 "3. Other image types: We don't understand the decision to allow the new longdesc to apply only to img elements, as it seems to be just as appropriate for things like groups of images (which may make up one whole image as far as the user is concerned), svg elements, objects, and even tables or arrangements of colored divs. We recommend allowing longdesc to apply to other elements." 18:23:21 gl comment: *4. Provide UI guidance:* The document should really provide some guidance or examples of how user agents could implement linked images with longdesc. Section 3.0.3 says "If the longdesc value is valid, User agents must make the link available to all users through the regular user interface(s)." but that's ambiguous as to whether it means "through the user agent's own UI (rather... 18:23:22 ...than relying on assistive technology)" or "through the user agent's normal clicks and keystrokes for activating links". It's clear that the user agent can't simply provide a single standard hyperlink when the img is inside an anchor and also contains a longdesc unless that pops up a choice of jumps, but it could instead apprend a separate hyperlink to the longdesc, or it could provide a... 18:23:24 ...separate command on the link's context menu and/or on a menu bar menu when the element has focus, etc. Of course, any guidance should be suggestions, rather than prescriptive, as we don't want to prevent user agent 18:23:25 developers from providing new, innovative UI or UI that's appropriate for their product and its platform. 18:24:29 JR: This sounds good to me. 18:27:39 We could add per Jim's suggestion "We also recommend you explicitly state that the longdesc link be actionable rather than allowing the user agent to merely display the URI (as is done by Firefox's View Image Info command)." 18:29:44 JA goes over how Firefox works here. 18:29:47 +1 18:30:36 JA: I think we need to say that images that have longdesc be easily discoverable. That is you do nothave to check each image. 18:31:17 s/nothave/not have 18:31:49 "User agents should enable users to discover when images in a page contain a long description." 18:33:01 jr: 'should' change to 'must' 18:34:38 group working on some wording changes. 18:34:44 a mechanism to reveal images with @longdesc, rather than discover 18:35:09 Per Jim's suggestion, we could add something like: 18:35:10 7. Discoverable by users: Section 3.0.03 says 'User agents should enable users to discover when images in a page contain a long description.' but we believe that the spec should make this a requirement (must instead of should), and also ensure that the user does not need to try clicking on every element to find which have longdesc properties. Suggested wording, "User agents MUST enable users... 18:35:12 ...to discover when images in a page contain a long description, without having to query each element individually." 18:35:34 s/description,/description/ 18:36:01 It works but expect pushback on the must part here. 18:36:09 do we want a statement about UA should not require AT to have @longdesc revealed 18:36:14 JA and JR says it works. 18:38:04 kford goes over comment a bit more. Not blocking for us at all in submitting comments. 18:38:09 gl comment: *5. Delimit blocks in the document:* As a purely editorial/formatting issue, the document should not convey information by graphical formatting alone. The problem is that the blocks starting with "This section is informative" are indented and have a differently colored background, but there is nothing textual to denote where the block ends. Thus, if one is reading or listening to... 18:38:10 ...the text that reads "This section is informative Best practices for full descriptions of images are beyond the scope of this document, but there are many resources available. Authors should not rely solely on longdesc where standards exist to provide direct, structured access." it is not immediately clear whether the third sentence is inside or outside the informative block. The reader... 18:38:12 ...may be able to infer it out from context in some cases, but that should not be required nor relied upon. 18:38:58 @@comment 5 is editorial 18:39:23 gl comment: *6. Web page contains insecure content:* FYI, when loading the page https://www.w3.org/WAI/EO/wiki/UAAG_review, my copy of Firefox 26.0 generates a warning saying "Firefox has blocked content that isn't secure. Most websites will still work properly even when this content is blocked." It links to the following page for details: https://support.mozilla.org/en-US/kb/how-does-content-isnt 18:39:25 -secure-affect-my-safety. 18:39:47 That should have been https://dvcs.w3.org/hg/html-proposals/raw-file/default/longdesc1/longdesc.html 18:40:54 6. Web page contains insecure content:* FYI, when loading the page https://dvcs.w3.org/hg/html-proposals/raw-file/default/longdesc1/longdesc.html, my copy of Firefox 26.0 generates a warning saying "Firefox has blocked content that isn't secure. Most websites will still work properly even when this content is blocked." It links to the following page for details: https://support.mozilla.org/en-US/k 18:40:56 b/how-does-content-isnt 18:43:47 @@comment 6 editorial 18:45:49 Under the requirement "Structured Markup" they have "A user should be able to determine that there is a description available for a given image." This is not really related to structured markup, so should be under the requirement "Discoverability". 18:46:02 We suggest moving "A user should be able to determine that there is a description available for a given image. " to the definition of Discoverability 18:46:40 We suggest moving "A user should be able to determine that there is a description available for a given image. " in the definition of Structured Markup to the definition of Discoverability 18:47:09 @@comment 7 is !important 18:48:25 7. Discoverable by users: Section 3.0.03 says 'User agents should enable users to discover when images in a page contain a long description.' but we believe that the spec should make this a requirement (must instead of should), and also ensure that the user does not need to try clicking on every element to find which have longdesc properties. Suggested wording, "User agents MUST enable users... 18:48:26 ...to discover when images in a page contain a long description, without having to query each element individually." A similar change should be made in the Requirements section where it currently says "A user should be able to determine that there is a description available for a given image." This should also be changed from SHOULD to MUST. 18:49:10 seems fine to me. 18:49:10 +1 18:50:19 action: jim to write comments and send to both groups 18:50:19 Created ACTION-936 - Write comments and send to both groups [on Jim Allan - due 2014-01-30]. 18:50:25 Group is good with comments after discussion. 18:50:58 Group thanks GL for his work on comment review. 18:51:13 zakim, close item 1 18:51:13 agendum 1, Longdesc review, closed 18:51:14 I see 1 item remaining on the agenda: 18:51:14 2. review comments - [from kford] 18:51:22 scribe: Jan 18:51:25 zakim, open item 1 18:51:25 agendum 1. "Longdesc review" taken up [from kford] 18:51:31 zakim, close item 1 18:51:31 agendum 1, Longdesc review, closed 18:51:32 I see 1 item remaining on the agenda: 18:51:32 2. review comments - [from kford] 18:51:39 zakim, open item 2 18:51:39 agendum 2. "review comments -" taken up [from kford] 18:52:45 KF: I have to go...I want to be here to discuss Microsoft comments 18:53:26 topic: Silas Comments 18:53:27 http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JanMar/0015.html 18:53:55 JA: Oh... 18:54:03 http://www.w3.org/WAI/UA/2014/LCcomments-20140122.html 18:54:11 silas comments: http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0000.html 18:54:19 JS: I don't have everything plugged in yet... 18:55:05 http://www.w3.org/WAI/UA/2014/LCcomments-20140122.html 18:55:09 JS: This is the big table http://www.w3.org/WAI/UA/2014/LCcomments-20140122.html 18:56:19 greg recommended response to silas - http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JanMar/0015.html 18:56:53 JR: SSB: I'm not sure if 1.7.4 (Save Copies of Stylesheets) is really needed. 18:57:16 JR: GCL: The Implementing document explains the rationale for this. Let us know if after reading that explanation you still feel it is not needed. 18:57:38 SSB1: I'm not sure if 1.7.4 (Save Copies of Stylesheets) is really needed. 18:58:05 -KellyFord 18:58:11 this is something that all browsers allow already. 19:01:22 Draft Resolution SB1 The Implementing document explains the rationale for this. Let us know if after reading that explanation you still feel it is not needed. It should be noted that many browsers already implement this success criteria. 19:04:15 Resolution: SB1 The Implementing document explains the rationale for this. Let us know if after reading that explanation you still feel it is not needed. It should be noted that most desktop browsers already implement this success criteria. 19:04:44 SB2: SSB: 1.8.7 (Reflow Text) - I think there's a possible misunderstanding here with the wording "text content in a graphical top-level viewport". Some developer might think "oh, if it's only about text in a top-level viewport, then it doesn't apply to text in a table (or other layout device) within that viewport", which is not ideal especially if such layout device is being used unnecessarily. 19:04:46 Maybe add something like "This applies even if such text is included within other structures"? 19:05:04 GL: Reasonable concern... 19:06:41 defined in viewport http://www.w3.org/TR/UAAG20/#def-viewport 19:10:06 all discussion of viewports and text vs non-text 19:11:14 GL: Want to give users option to try to reflow tables... 19:11:46 GL: What about a note in the applicability notes... 19:12:10 GL: When we refer to viewports or elements... 19:12:20 GL: We are also referring to their children 19:12:51 we have : 19:12:55 content (web content) 19:12:56 Information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions. 19:13:19 reflowable content 19:13:21 Web content that can be arbitrarily wrapped over multiple lines. The primary exceptions to reflowable content are graphics and video. 19:14:29 proposal 19:14:30 1.8.7 Reflow Text: The user can specify that reflowable content in a graphical top-level viewport reflows so the text forms a single column that fits within the width of the viewport. (Level A) 19:16:05 JS: Don't most tools already do this? 19:16:24 GL: We need it because some people assume zoom of the whole page is enough 19:16:58 We want to avoid having the developer interpret "web content that can be arbitrarily wrapped" to not include text. We note in the comments from one reviewer that they felt zoom should be good enough, that enlarging text (with wrap) should not be required. 19:19:02 old version: 1.8.12 Reflowing Zoom: 19:19:04 The user can request that when reflowable content in a graphical viewport is rescaled, it is reflowed so that one dimension of the content fits within the height or width of the viewport. (Level AA) 19:20:28 GL: So why did it change? 19:20:38 JR: Maybe as part of moving it to A from AA? 19:21:15 http://www.w3.org/2013/10/17-ua-minutes.html#item04 19:22:18 How about enhancing the definition of reflowable content to clarify that it refers to content that is technologically reflowable, even if a user agent chooses not to support reflowing it. 19:25:47 jr: table is a structural element, don't want to linearize the table 19:27:01 jr: some mode where there is no horizontal scrolling 19:27:28 JR: What if instead of splitting hairs we should had SC...have an option for thou shalt not horizontally scroll 19:28:47 what happens with iframes 19:29:23 gl: 1.8.9 covers them 19:32:08 words reflow, 'solid' things (images, objects, etc) don't reflow 19:32:56 http://my.opera.com/ODIN/blog/opera-14-for-android-is-out 19:33:10 By default, Opera for Android uses the same text autosizing (aka FontBoosting) mechanism that can be found in Chrome for Android. E.g. if you visit this desktop-specific Wikipedia page about artichokes, you see that some of the text is displayed bigger, making it readable without having to zoom in. However, as FontBoosting is only applied selectively and interferes with author-defined text... 19:33:12 ...size differences, we've made it possible to turn this off in Settings, and choose for automatic text wrap instead. Turning on text wrap instructs Opera for Android to wrap lines no matter how much you zoom into a page so there's no need for horizontal scrolling. 19:34:21 its the words that reflow, not the containers 19:34:38 gl: should be able to squeeze a table 19:38:05 -Jan 19:38:37 RRSAgent, make minutes 19:38:37 I have made the request to generate http://www.w3.org/2014/01/23-ua-minutes.html Jan 19:38:43 RRSAgent, set logs public 19:42:32 -Jeanne 19:42:35 -Greg_Lowney 19:42:37 WAI_UAWG()1:00PM has ended 19:42:37 Attendees were Jim_Allan, KellyFord, Greg_Lowney, Jeanne, Jan 19:44:47 RRSAgent, make minutes 19:44:47 I have made the request to generate http://www.w3.org/2014/01/23-ua-minutes.html Jan 19:44:49 RRSAgent, set logs public