W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 2000

Re: Some (minor) comments from Adobe on UAAG 1.0

From: Ian Jacobs <ij@w3.org>
Date: Thu, 02 Nov 2000 08:31:34 -0500
Message-ID: <3A016CB6.FD1BE57D@w3.org>
To: David Poehlman <david.h.poehlman@verizon.net>
CC: w3c-wai-ua@w3.org
David Poehlman wrote:
> 
> If gregory were here he would scream.  One of my biggest headaches is
> things "brabbing the focus".

The requestion wasn't to grab the focus, but have the right to
have it! Apparently there was an IE bug that prevented the SVG
viewer from getting the focus at all.

 - Ian
 
> The sad thing here seems to be that they seem to be developping a
> solution for only one platform.  With all the system hooks around for
> different opperating systems, I'd have figured that as long as they
> have been envolved in software development the solution to access
> would be more platform independant.
 
> Has anyone seen their new implementation?
> 
> ----- Original Message -----
> From: "Ian Jacobs" <ij@w3.org>
> To: <w3c-wai-ua@w3.org>
> Sent: November 01, 2000 7:20 PM
> Subject: 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

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783
Received on Thursday, 2 November 2000 08:31:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:50:22 GMT