Some (minor) comments from Adobe on UAAG 1.0

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.

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.

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.

 - Ian

[1] http://www.w3.org/TR/2000/WD-UAAG10-20001023/

 _ Ian
-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Wednesday, 1 November 2000 19:20:52 UTC