• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: plugin accessibility
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: plugin accessibility


  • Subject: Re: plugin accessibility
  • From: David Bolter <email@hidden>
  • Date: Sun, 16 Aug 2009 15:55:37 -0400

Hi Michael,

Thanks. Now we're getting somewhere, I'll reply inline:

On 8/16/09 3:30 PM, Michael Ash wrote:
Before this discussion blows up any further I'd like to just clarify a couple of things for David.

The main disconnect in this discussion, as far as I can see, is that Accessibility has no concept of plugins. They are not within its field of view. As far as the Accessibility API is concerned, the idea of a "plugin" does not exist.

Agreed 100%. I'm talking about browser plugins, and how they might be able to provide seamless Accessibility support.



The trouble is that David keeps asking questions about how plugins relate to Accessibility.

Right, and just to be clear, I'm not asking how they relate to the API. If this list is purely about API (syntax and the like) then I'm definitely off topic here and apologize.


Since they don't, others on the list are getting kind of frustrated, but this fundamental sticking point doesn't seem to be getting explained 100% adequately. (Not meant as any sort of criticism, it's just the sort of thing that happens.)

Right, I've been confused by some of the replies but then I've certainly not been as clear as I should.



To put it simply: anything relating to the actual plugin code or API is your own problem, and unrelated to Accessibility. Once your plugin is loaded and running, then it's just like any other code within the app, and your interactions with Accessibility are *exactly* the same as they would be if you were writing a regular application.


So, get your basic plugin stuff built, and make it go (something you'll have to work with Mozilla on, since that's their end of things),

I'm not writing a plugin, I'm trying to make sure we take the right approach in providing browser support for people who want to have their plugin's accessible object tree inserted (as a child) into the main accessible object tree. Maybe this makes no sense for Cocoa a11y but I'm still not sure. This is a request currently coming from Linux:
https://wiki.mozilla.org/Plugins:NativeAccessibility


... but it affects a standard API: NPAPI.

and then once you have a foundation running and need to interact with Accessibility, ask Accessibility-specific questions here. But you can leave the word "plugin" out of it entirely, because it's just not relevant to the API.

Thanks Mike. I'll take any implementation specific questions (such as IPC for out of process plugins etc) off list.


cheers,
David
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Accessibility-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: plugin accessibility
      • From: Michael Ash <email@hidden>
References: 
 >plugin accessibility (From: David Bolter <email@hidden>)
 >Re: plugin accessibility (From: Christiaan Hofman <email@hidden>)
 >Re: plugin accessibility (From: David Bolter <email@hidden>)
 >Re: plugin accessibility (From: Travis Siegel <email@hidden>)
 >Re: plugin accessibility (From: David Bolter <email@hidden>)
 >Re: plugin accessibility (From: Michael Ash <email@hidden>)

  • Prev by Date: Re: plugin accessibility
  • Next by Date: Re: plugin accessibility
  • Previous by thread: Re: plugin accessibility
  • Next by thread: Re: plugin accessibility
  • Index(es):
    • Date
    • Thread