- From: Jon Gunderson <jongund@ux1.cso.uiuc.edu>
- Date: Wed, 01 Nov 2000 19:01:41 -0600
- To: Ian Jacobs <ij@w3.org>, w3c-wai-ua@w3.org
Ian, Good to hear that Adobe is interested in the guidelines and that you had a chance to meet with them! At 07:20 PM 11/1/2000 -0500, Ian Jacobs wrote: >Hello, > >I spent the day yesterday at Adobe (in San Jose) talking >to developers about accessibility issues. I had some very >productive discussions about a number of topics, including >UAAG 1.0, accessibility of PDF viewers, and SVG. Here are two >comments about UAAG 1.0 that I think we can address pretty >easily. Note: I look forward to a full review from Adobe >of the last call draft [1]. > >1) Point 1: They would like the UAAG 1.0 to include a > requirement that the conforming user agent allow > other software to capture focus. I responded that I think > our document covers that requirement in checkpoint 5.4: > > "5.4 Provide programmatic read and write access to user agent > user interface controls using standard APIs ..." > > Write access to the focus amounts to being able to capture > the focus and change it. At least I think so. What do other > people think? In checkpoint 5.5, we mention selection and > focus explicitly as part of user interface controls. Should > we do the same in 5.4 (or in a definition)? Should we just > say in the Techniques document that assistive technologies > and other software (in this case an SVG rendering engine) > needs to be able to take focus. > > I also pointed out that checkpoint 7.1 requires navigation to > all viewports (in this case, an SVG viewport), but that doesn't > cover the issue exactly. JRG: We use to have a separate checkpoint that was considered an important special case of 5.5[1]. So my understanding is that this functionality was is part of the current 5.5. >2) Point 2: In rendering PDF, Acrobat (on Windows) does not use > standard system calls for drawing text to the screen. Instead, it > creates a bitmap itself and causes that to be displayed. Since PDF > is a low-level page description format, is it "ok" for them to > do their own bitmap (since that's what the language is about) >creation? > Note: Acrobat Reader implements MSAA apparently, so it satisfies >checkpoint > 1.2's requirement to use standard APIs for the OS. However, it does >not > use the standard device API for drawing text. JRG: The group may want to consider modifying the current checkpoint 5.3 to say: <NEW> 5.3 For markup languages other than HTML and XML, provide programmatic access to content using either standard APIs (e.g., platform-independent APIs and standard APIs for the operating system) or other APIs that are defined to support communication with assistive technologies. [Priority 1] Note: This checkpoint addresses content not covered by checkpoints checkpoint 5.1 and checkpoint 5.2. Techniques for checkpoint 5.3 </NEW> <OLD> 5.3 For markup languages other than HTML and XML, provide programmatic access to content using standard APIs (e.g., platform-independent APIs and standard APIs for the operating system). [Priority 1] Note: This checkpoint addresses content not covered by checkpoints checkpoint 5.1 and checkpoint 5.2. Techniques for checkpoint 5.3 </OLD> >3) Point 3: Checkpoint 6.2 says to use and conform to W3C specs. Does >this > checkpoint apply to the Acrobat Reader since they only read and >render > PDF? I think that we need to consider ways to help developers and > readers interpret "appropriate for a task". > > W3C doesn't (yet) specify a similar "page description format"; HTML > is not about pixel-perfect rendering on paper/the screen (the HTML >spec > emphasizes the fact that it does not require particular rendering). > You could argue that HTML + CSS are the appropriate languages, but > even that seems far-fetched to me. > > A larger question is (and of course it's related to applicability): > should software that doesn't implement W3C specifications at all > be able to claim conformance? I personally would like the UAAG 1.0 > to be applicable to user agents in general, not just user agents > that implement W3C formats. I think there is some grey area that > we need to work on: > - If you are creating an imitation of a W3C format (or if > W3C is creating an imitation of yours...), then for the > sake of interoperability and also because of the way W3C > > works (with WAI review, etc.), you should (P2) implement > the W3C spec. So, implement PNG at least, but if you wish, > GIF, JPG, etc. > > - If you are doing something entirely different, 6.2 doesn't > apply, and you can still conform. > > How can we provide guidance for determining what is "available" > (e.g., implemented sufficiently) and "appropriate for a task"? > I think it's easier to talk about 'available' than 'appropriate for > a task'. I don't have any proposals today to address this. JRG: I think this is exactly the situation that 5.3 was designed to handle. Maybe if we modify 5.3 to include accessibility APIs we can expand the scope of this checkpoint. Jon [1] http://www.w3.org/WAI/UA/CR-UAAG10-20000308/ Jon Gunderson, Ph.D., ATP Coordinator of Assistive Communication and Information Technology Division of Rehabilitation - Education Services MC-574 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 Wednesday, 1 November 2000 20:01:08 UTC