The complete list of properties and methods implemented by accessible elements.
- macOS 10.10+
In general, your custom user interface elements should not adopt this protocol. Instead, select the role-specific protocol—such as
NSAccessibility—that best matches your element’s behavior.
By default, many AppKit classes already adopt the
NSAccessibility protocol. In particular,
NSDrawer) provide a default implementation for all the properties and methods listed in this protocol. However, if you create a custom subclass that adopts one of the role-specific protocols, the compiler may ask you to reimplement some of the protocol’s accessor or action methods. By forcing you to reimplement these methods, the compiler helps ensure that your custom subclass provides accurate information to the accessibility clients.
If your custom user interface element does not inherit from
NSView (or one of the other accessibility-enabled AppKit classes), subclass the
NSAccessibility class instead. This class manages many of the details required to work with accessibility clients successfully. You also need to implement all the properties and methods from your user interface element’s role-specific protocol—as well as any additional properties and methods you may need to use to further customize your element’s behavior.
Customizing User Interface Elements
You can further customize any user interface elements by freely implementing any of the other properties or methods listed in the
NSAccessibility protocol. You do not need to adopt any particular protocol to make these properties and methods available to the accessibility client. As soon as your element is accessibility enabled, the system automatically uses any of the
NSAccessibility properties and methods that you have implemented.
If a user interface element inherits from
NSView (or one of the other accessibility-enabled AppKit classes), you can also customize it by simply setting the appropriate properties. Often, you can fine tune how an accessibility client interacts with your element without creating a custom subclass.
Sometimes, however, it makes more sense to override the property’s accessor methods. If you override the getter for a property declared in the
NSAccessibility protocol, the system lets accessibility clients call your getter. This can be particularly useful when managing dynamic properties, because you can calculate their current value on demand instead of trying to update the property in response to a change.
If you override the setter for a property, by default the system lets accessibility clients both read and modify that property. For example, you can override the setter for a control’s
accessibility property, letting users modify the control’s value through an accessibility client.
You can further control which accessor methods the accessibility client can use by overriding
true if the accessibility client can call the selector; otherwise,