I had my own extended MenuItem Class for my Application and though there was proper implementation of the MenuItems as far as the looks were concerned then also they were absolutely worthless for the disabled people. (Refer to Section 508 for devlopment: http://www.section508.gov/IRSCourse/mod02/020705--.html) because the Client Objects such as the Narrator(Provided with XP and 2K OS) and MS Jaws were not able to get the text on the MenuItems and would say only "MenuItem" Enabled/Disabled and not "<MenuItem.Text> MenuItem Enabled/Disabled>"
The real inside story goes like this.
(1) The Client App queries the MenuItem by sending a message something like getWindowText().
(2) The Server App returns the Text as a BSTR.
(3) The Client converts that to Speech.
Thats how the Narrator works,
but when it came down to OwnerDrawn Menus the menuitems would return Null String.(You can download the application called AccExplorer from MSDN to see the results of the accesible names for every component used on your form)
So I tried to find out the solution at the MSDNs but unfortunately sample implementations were specifically ment for C/C++ devs.
The solution the MSDN guys quoted was to impement an IAccessible interface but the procedure seemed to be very complicated and was impossible to implement coz microsoft seemed to have its own reasons for that. Later I discoverd that that was a published bug of the VS.NET 2003.(http://support.microsoft.com/?kbid=316581) and because of that I was not able to implement that interface properly.
But the simple solution for the same would be.
Once the application has been loaded all you do is make the OwnerDraw property to False and then make it True once more. Because this the Accessible Name and all the menuitem accessiblility realated data is filled.
Thus this can be one of the best methods to expose the OwnerDrawn items to the Client Applications.
And my menus are now 508 compliant.