- From: Jon Gunderson <jongund@ux1.cso.uiuc.edu>
- Date: Thu, 13 Apr 2000 15:40:44 -0500
- To: w3c-wai-ua@w3.org
Attendance Chair: Jon Gunderson Scribe: Ian Jacobs Present: David Poehlman Jim Allan Gregory J. Rosmaita Harvey Bingham Charles McCathieNevile Regrets: Mickey Quezner Mark Novak Kitch Barnicle Rich Schwerdtfeger Action Items Open Action Items 1.IJ: Draft a preliminary executive summary/mini-FAQ for developers. (No deadline.) 2.IJ: Propose three terms to the list: Document Source, Document Object and Rendered Content 3.IJ: The content/ui division in G1 needs to be fixed 4.IJ: Resolutions from FTF meeting 5.CMN: Find out from I18N how to generalize the accessibility provided by sans-serif fonts. 6.CMN: Propose a technique that explains how serialization plus navigation would suffice for Checkpoint 8.1. 7.DA: Send name of new organization to list that was mentioned by some from the US Census Bureau 8.DA: Review techniques for Guidelines 7 and 8 9.DB: Get Tim Lacy to review G+ 10.DB: Review techniques for Guidelines 3, 4, and 11 11.DP: Review techniques for Guidelines 1 and 2 12.GR: Look into which checkpoints would benefit from audio examples in the techniques document. 13.GR: Review techniques for Sections 3.7 and 3.8 14.GR: Send to list screen shot of JFW Window list. 15.JG: Write email to the list asking for information about which user groups require the ability to slow down presentations othewise access it impossible. 16.JG: Take conformance grandulatity issue to the WAI CG. 17.JG: Identify the minimal requirement for each checkpoint. 18.HB: Take scoping issue of the current guidelines to the EO working group 19.MQ: Review techniques for Guidelines 9 and 10 20.RS: Take notification of focus and view changes to PF as possible DOM 3 requirement. New Action Items 1.IJ: Adopt new wording of proposal for checkpoint 9.2 2.IJ: Propose split to the list. Identify why and issue of priority. Completed Action Items 1.MR: Talk to Geoff Freed about implementations that slow down multimedia presentations. http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0065.html Minutes Agenda [1] [1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0067.html 1) Open Action Items 12.GR: Look into which checkpoints would benefit from audio examples in the techniques document. GR: Any example given for a self-voicing browser. Still seeking tech assistance for capturing voiced output. 13.GR: Review techniques for Sections 3.7 and 3.8 Status: Working on a technique proposal. 14. GR: Send to list screen shot of JFW Window list. Status: I have the screen shot. Will send. 17.JG: Identify the minimal requirement for each checkpoint. Status: Started 18.HB: Take scoping issue of the current guidelines to the EO working group Status: Sent to UA WG. Will send to EO tomorrow. 20.MR: Talk to Geoff Freed about implementations that slow down multimedia presentations. Done: http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0065.html 1b) No progress 1.IJ: Draft a preliminary executive summary/mini-FAQ for developers. (No deadline.) 2.IJ: Propose three terms to the list: Document Source, Document Object and Rendered Content 3.IJ: The content/ui division in G1 needs to be fixed 4.IJ: Actions from FTF meeting 5.CMN: Find out from I18N how to generalize the accessibility provided by sans-serif fonts. 6.CMN: Propose a technique that explains how serialization plus navigation would suffice for Checkpoint 8.1. 7.DA: Send name of new organization to list that was mentioned by some from the US Census Bureau 8.DA: Review techniques for Guidelines 7 and 8 9.DB: Get Tim Lacy to review G+ 10.DB: Review techniques for Guidelines 3, 4, and 11 10.DP: Review techniques for Guidelines 1 and 2 11.JG: Write email to the list asking for information about which user groups require the ability to slow down presentations othewise access it impossible. 12.JG: Take conformance grandularity issue to the WAI CG. 13.MQ: Review techniques for Guidelines 9 and 10 14.RS: Take notification of focus and view changes to PF as possible DOM 3 requirement. 2) On the FAQ. Action HB: Ensure that EO documents their commitment to to the FAQ. DP: We might want a FAQ for the users. JG, IJ: Let's wait for EO proposal before we draw up any other ones. 3) Announcements 1.FTF for Evaluation and Repair Tools working group in Amsterdam http://www.w3.org/WAI/ER/2000/05/agenda 2.Notice of Proposed Rulemaking: Electronic and Information Technology Accessibility Standards by the United States ARCHITECTURAL AND TRANSPORTATION BARRIERS COMPLIANCE BOARD. Comments will be accepted until May 30th http://www.access-board.gov/sec508/nprm.htm http://www.access-board.gov/sec508/overview.htm 4) Update on proposed Rec. IJ: Keep resolving those issues! 5) Open issues after ftf 5.2) Issue 208 http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#208 HB: I think we have to be careful about form submit buttons that aren't obvious. GR: I think this should be addressed in the techniques document. No objections to proposal: http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0088.html Action IJ: Adopt wording of proposal. 5.1) Issue 207 http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#207 Refer to summary of 6 April minutes on "where we are": http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0037.html IJ: I understand the open issue to be whether 2.1 scope should be reduced to content for humans or left at "all stuff". CMN: Human-readable content through the UI is part of a minimal requirement for conformance to 2.1. GR: I think the scope should be "all", not human-readable only. DP: I'm still not sure what's lost if we don't include machine content. IJ: I think that the UA should use machine content to do repair strategies, but that it should not be required to do so. CMN: I think that if the user has access to all the content, then the user can make repairs the UA couldn't make. JG: Is this a requirement only for markup languages, or also binary stuff? CMN: Good question. It's harder to use a GIF image in source mode. But I would continue to require them. CMN: There's no requirement that if you make content available through the UI that you also have to make it available through some other means. There is no statement about how many times you must make content available. CMN: a) Everything has to be available. b) Things for humans must be available through the UI (not through a source view). In the real world: c) There's no requirement for a source view. It will meet requirement for things meant for machines. However, if all the information meant for machines is rendered somehow through the UI, then no other view required. IJ: I disagree that the user needs to know that "id" is there. CMN: Rendering is not sufficient. You need to make available the fact that the content is styled by "id". You need an interface that lets you do everything you can do with an id. IJ: But the "id" value is not required. What about a processing instruction at the top of an XML document? I think that we're talking about processing, and the effect if what's important to the user, not the PI itself. CMN: I would agree that that's an edge case. IJ: What about the fact that all info is available through the API? CMN: Not sufficient. HB: I want to be able to view all the content, including the META information. JA: I think I agree with HB. DP: I don't see the validity, for the general user, of having binary available to the general user. JG: This machine stuff could be useful, but there's no guarantee. IJ: Suppose a user agent doesn't support PNG, must it make it available? CMN: No, only the URI to the PNG. IJ: For those things not made available through the UI, what's the minimal way to satisfy the other stuff? CMN: A source view would meet the requirement. But the minimal requirement would not be for a source view. IJ: Why is this checkpoint different from other checkpoints that allow some information to be handled through an API? CMN: We should require native support for access to all content. GR: In the case of rendering things natively, whether you need to view binary: Lynx exposes the alternative or puts in a place-holder - you can turn anything it can't render natively into a hyperlink. CMN: Lynx gives you access to applicable content, otherwise gives you access to things it can't deal with (through a link). IJ: Should we adopt similar wording as ATAG about the "average user"? That is, that the user is not expert. I have a problem with P1 access to information that is not meant for humans and will not be useful to most users. I do agree with Charles, however, that if some of that "content" is not available directly to users, it may not be accessible. DP: What does it mean to "make available" information? JG: Originally, some things through the UI and some through an API. IJ Propose: 2.1.a: Ensure that the user has access to all content meant for human consumption, including equivalent alternatives for content, through the user interface. Note: A source view does not meet this requirement. P1 2.1.b: Ensure that the user has access to all content meant for machines either by processing it according to specification or by making it available directly to the user through the user interface. Note: A source view would suffice to meet this requirement. IJ: Clearly 2.1.a a P1. I agree with the first half of 2.1.b as P1, but not sure about priority of second half since information is available through an API. I'm not sure that the source view would provide access to most people; I've heard people say that most users would not be able to use this information. Consensus: The split is reasonable, as long as it covers the requirements. GR, CMN: Unfortunately, people count the numbers of P1s. Also consistency with current PR. IJ: I think both should be sacrificed for the sake of clarity. JG: We've missed something if we've said that the other checkpoints don't cover the accessibility of the user interface and you need a source viwe. IJ: This can be seen as a way to catch thigns that we've missed. CMN: (Use case) I went to a Web site. The URI you could use to get to the site started with "javascript:". The only problem with my user agent was that it didn't support javascript. IJ: If you don't support javascript, then applicability kicks in. CMN: But it's in HTML, which is supported. The UA can either provide some form of access or tell me to buzz off. IJ: Sounds like you're requiring minimal repair strategy is native support for source view. JG: Sounds like what I'm hearing mostly is that 2.1.b is not to improve accessibility of the user agent, but to repair broken content or deal with (in)applicability. We have another repair checkpoint (2.3). Do we need another guideline for repair? JA: UAs have already repaired broken content. It's one of their primary duties. CMN: I think the document's already too big. I don't want another guideline. Action IJ: Propose split to the list. Identify why and issue of priority. 5.2) Issue 208 http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#208 HB: I think we have to be careful about form submit buttons that aren't obvious. GR: I think this should be addressed in the techniques document. No objections to proposal: http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0088.html Action IJ: Adopt wording of proposal. Copyright © 2000 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements. Jon Gunderson, Ph.D., ATP Coordinator of Assistive Communication and Information Technology Chair, W3C WAI User Agent Working Group Division of Rehabilitation - Education Services College of Applied Life Studies University of Illinois at Urbana/Champaign 1207 S. Oak Street, Champaign, IL 61820 Voice: (217) 244-5870 Fax: (217) 333-0248 E-mail: jongund@uiuc.edu WWW: http://www.staff.uiuc.edu/~jongund WWW: http://www.w3.org/wai/ua
Received on Thursday, 13 April 2000 16:40:54 UTC