Hi Joseph, You raise a very good point, but I think we need to be careful about when we conflate sighted keyboard-only users with screen reading/magnifying keyboard users. In some cases their needs are the same (e.g. how does a sighted keyboard user select text from a web page to copy it to the clipboard? same way as a blind keyboard users moves the caret & selects text), in some cases not (e.g. how does a sighted keyboard user discover what the menu's contents are, including which menu items are not available). Since we don't expect sighted keyboard-only users to use an external assistive technology, everything *must* be built-in. However, we do expect blind users to use an external assistive technology - in this case a screen reader (which of course should be Orca). When external AT is involved, it *may* be appropriate to have any given piece of functionality in the AT rather than built into the widgets/toolkit/desktop/environment itself. I not certain what the right answer is here for unavailable menu items - whether they should be keyboard navigable or not. In some toolkits they are keyboard navigable (e.g. Swing). But - other than display of any tooltip associated with an unavailable menu item - there isn't much overlap between sighted keyboard-only users and screen reader users. Therefore it isn't so clear that the access solutions for those two use cases should be the same. Regards, Peter On 1/5/2012 6:25 AM, Joseph Scheuhammer wrote: All, --
Peter Korn | Accessibility Principal Phone: +1 650 5069522 500 Oracle Parkway | Redwood City, CA 94065 Oracle is committed to developing practices and products that help protect the environment |