- From: Ian B. Jacobs <ij@w3.org>
- Date: Thu, 25 Apr 2002 16:55:52 -0400
- To: w3c-wai-ua@w3.org
UAWG teleconference, 25 Apr 2002 Agenda announcement: http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0059 Participants: Jon Gunderson (Chair), Ian Jacobs (Scribe), Eric Hansen, Tim Lacy, Jim Allan, David Poehlman, Harvey Bingham, Rich Schwerdtfeger Previous meeting: 18 April 2002 http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0056 Next meeting: 2 May, 2pm ET. Regrets: IJ, RS Reference document 12 September Candidate Recommendation: http://www.w3.org/TR/2001/CR-UAAG10-20010912/ ========== Discussion ========== Action IJ: Update issues list. 1. Sun BeiJing Accessibility Team a) JG, Judy, IJ will talk offline with them first. b) Based on that discussion, talk about possibly rescheduling our weekly meetings. c) Additional meetings for test materials? JG: Does the current time still work for people as the summer is approaching? (No problems for people.) 2. AT requirements/ DOM JG: Postponed for now while we collect more information. Action JG: Contact AT developers to get them to send more requirements. 3. Issues list http://www.w3.org/WAI/UA/issues/issues-linear-cr2.html ========= Issue 521: If not required to conform for all implemented formats, what is relation to "turn off all images", etc.? ========= Issue 522: Make clearer early in conformance section that ok to conform to fewer than all checkpoints. Resolved: Accept this proposal. ========= Issue 523: 2.10: Explanation of placeholder requirement unclear Resolved: Change 2.10: "If the user agent has satisfied checkpoint 2.3 by using a placeholder, then allow the user to toggle rendering between the placeholder and the original author-supplied content." ========= Issue 525: 1.2, 9.5, 9.6: Can satisfy these checkpoint on per event type basis (not handler)? Resolved: Clarify in 1.2, 9.5, 9.6 that sufficient to address handlers on a per event-type basis. ========= Issue 526: 6.3: Checkpoint title says "content" but checkpoint text refers to "markup". What is intended scope? Q: Do 6.1/6.3 include access to all bits? Or just limited to markup language info (e.g., terms of infoset)? IJ: Should we think about 6.1 in terms of infoset requirements? That seems useful to me: distinguishing stuff from API requirements. /* JG leaves */ IJ: Talking about infoset seems to clarify what's expected. What would PDF look like? What about plain text? What about style sheets? IJ: What about "structured formats" (I hesitate)? TL: I suggest avoiding "markup". IJ: Should we require in Guideline 6 access to all (plain) text content? This would be consistent with 2.2. Or should we just expect that everyone can do HTTP GET? RS: In the case of IE for text files, IE takes this content, converts to an HTML document that has a big PRE statement... RS: There are issues with secure sockets; some ATs may not be able to use HTTP GET to get at text content. IJ: Question for 6.3: does this assume STRUCTURED access to content? Or does a dump of content suffice? /* EH leaves */ IJ: Proposed for 6.3.1: "For content other than HTML and XML, provide structured programmatic read access. Note: In the case of plain text, the structured access will only be as structured as the text content." Consider three ways of using CSS: a) Processed as text/css (i.e., according to the CSS spec); in this case it can be processed and discarded. Not in content (i.e., object). b) Processed as structured CSS (e.g., and authoring tool). In this case, you want structured access through an API. c) Treated like text/plain. In this case, the API access would only be as structured as the plain text itself. [Same idea with schemas, for example.] TL: This is how we treat CSS today. E.g., you can view CSS in Notepad today (handed off by IE). Proposed: Change 6.3.1: "For content other than HTML and XML, provide programmatic read access according to the structure of the content." DP: Would Adobe say that there's enough info in a PDF file to allow for that to be provided? IJ: See Acrobat core API: http://partners.adobe.com/asn/developer/acrosdk/docs/coreapi/CoreAPIReference.pdf IJ: I think the proposal addresses: a) Need for structured access. b) Plain text case handled (API will be minimal) c) I think by using "content" we are ok with cases where style sheets, DTDs, etc. not maintained in document objection. Resolved: Change 6.3.1: "For content other than HTML and XML, provide programmatic read access according to the structure of the content." ================== Open Action items: ================== IJ: Send proposal for Guideline 10 modifications based on 4 April 2002 teleconference Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0027 IJ: Propose text to the UAWG on conformance profiles for use by other specifcations. Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0027 IJ: Review UAAG 1.0 for which checkpoints should be "all formats" v. "formats that are part of the claim". (issue 521). http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0049 JG: Write up user scenarios for why non-text-based highlighting important for users; notably which users. Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0027 See for additional questions: http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0029 JG: Clarify why "Max rating" used in some cases (in low implementation experience section) and "Avg rating" in some cases. Also, delete "+/-" with P (round down from G to P) http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0049 -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs Tel: +1 718 260-9447
Received on Thursday, 25 April 2002 16:56:36 UTC