NSAccessibilityProtocol

In general, your custom user interface elements should not adopt this protocol. Instead, select the role-specific protocol—such as NSAccessibilityButton, NSAccessibilityImage, or NSAccessibilityGroup—that best matches your element’s behavior.

Many AppKit classes already adopt the NSAccessibility protocol by default. In particular, NSView, NSWindow, NSCell and 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 ensures 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 NSAccessibilityElement 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.

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 accessibilityValue 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 isAccessibilitySelectorAllowed(_:). Return true if the accessibility client can call the selector; otherwise, false.