Re: Top-10 Accessibility API Wish List
Re: Top-10 Accessibility API Wish List
- Subject: Re: Top-10 Accessibility API Wish List
- From: Guy Fullerton <email@hidden>
- Date: Thu, 12 Sep 2002 20:33:46 -0700
On 9/12/02 7:50 PM, "Michael Kamprath" <email@hidden> wrote:
>
I've already solved this "puppet stringing" problem many years ago ;-)
>
>
I did this exact same "puppet stringing" under MacOs 7-9 by simply patching
>
FindWindow() ...
We already know how to do this. We also know (through experience of having
done it before) that:
1) It doesn't work for all apps; you'd be surprised how many it *doesn't*
work for. Not everybody calls FindWindow in quite the way you expect them
too. Not everybody allows a phantom point to even *reach* FindWindow. Not
everybody uses standard window definitions.
2) Such code is difficult to maintain and convolutes our source base. This
is made worse every time our HI designers move widgets or redesign window
layout.
3) It is a slippery slope. Now, people are asking us to do this for close
boxes, but from there it's not too much of a stretch to ask us to do this
for conventional controls (push buttons, scroll bars, etc.). After that,
folks will ask us to do this for controls that are *scrolled out of view*,
since those can be "seen" by the accessibility API. The state machine just
gets more and more gross.
4) It doesn't promote adoption of the technologies we want developers to
adopt. Developers can (read: will be able to) get this for free by adopting
the standard window event handler or responding to the appropriate window
close event. The vast majority of developers *already* need to rev their
apps to be Section 508 compliant (since the vast majority of apps have
custom areas that need to be made accessible), and adopting the standard
window handler or close carbon event is part of that work.
We've told developers for several years that adopting carbon events would be
the *only* way to achieve certain new functionality in their apps. This is
one of those cases.
If the ultimate goal is to make apps Section 508 compliant, and if doing so
requires app developers to rev their product, then adding puppet strings to
the Toolbox doesn't really help.
Adding puppet strings *does* help certain utility developers, but (like I've
said before) that's not our goal with the Accessibility APIs.
>
Ah, the good old days of being able to patch system traps to get what you
>
want . . . .
I'm probably taking that comment out of context, but doesn't that seem like
the wrong attitude? Patching is *bad*. Sure, it's good in the short term,
since folks can quickly push product out the door. Unfortunately, in this
case, the "quicker, easier, more seductive" route led to the dark side:
incompatibilities, and the prevention of Apple from revving system software.
I'm most interested in doing things the *right* way, even if that means it
takes a bit more time and effort to do it.
_______________________________________________
accessibility-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/accessibility-dev
Do not post admin requests to the list. They will be ignored.