Apple accessibility: govern settings with declarative MDM
Apple has added an OS 27 declaration that lets MDM configure accessibility settings on supervised devices. This building block can improve consistency across managed environments, but it should not become a uniform profile imposed without consulting affected users.
1. What Apple documents precisely
The com.apple.configuration.accessibility.settings declaration is available on iOS, macOS, and visionOS for supervised enrollment. Apple allows it at system scope on all three platforms and at user scope on macOS. It is unavailable for nonsupervised Device Enrollment, User Enrollment, and Local Enrollment.
Apple’s developer documentation currently exposes a “Vision” object and an example that disallows Live Recognition. Multiple declarations combine into one effective configuration. Teams must therefore verify OS versions, supported keys, and their MDM vendor’s implementation before making functional commitments.
2. Accessibility and security do not always pursue the same goal
Live Recognition may help a user understand their surroundings through the camera. An organization may nevertheless need to govern this capability in a sensitive area. The appropriate balance is neither a blanket ban nor universal enablement: it connects individual need, workplace context, physical security, and data policy.
Supervision and Automated Device Enrollment are decisive here. A personal device enrolled as BYOD does not receive this declaration; that boundary belongs in service design from the outset.
3. What does this announcement change for a Belgian or French organization?
For an SME, the feature provides a repeatable way to apply an approved setting without manual handling. For a mid-market organization, large enterprise, or public administration, it can attach selected accessibility decisions to groups, roles, and risk zones through an MDM-declared policy.
In Belgium and France, IT teams need to involve security, HR, prevention, data protection, and affected users. Compliance is not merely proof that a setting is applied: the measure must also remain proportionate, reversible, and compatible with reasonable workplace accommodation.
4. Underside analysis: manage a durable exception, not a frozen profile
Our view is that this declaration belongs in a versioned configuration catalogue. Every rule should state its rationale, target population, owner, review date, and exception process. Declarative status reporting can confirm technical application, but it cannot by itself prove that the user experience is appropriate.
In Jamf or another compatible MDM, the pilot should distinguish supervised devices from BYOD and system scope from user scope, then test how multiple declarations combine. Teams should also remove the rule and verify actual behavior after a group change.
5. Operational qualification plan
- Inventory accessibility use cases and privacy or security constraints.
- Confirm support for the declaration and its keys across the MDM and target OS versions.
- Limit the pilot to representative supervised iOS, macOS, or visionOS devices.
- Test system scope, macOS user scope, declaration merging, and removal.
- Document user communication, exceptions, support, and periodic review.
- Measure technical compliance separately from suitability for the individual need.
Objective: make an accessibility setting consistent and verifiable without erasing individual needs or extending MDM control beyond Apple’s documented scope.
Qualify your Apple MDM policyOfficial Apple sources: What’s new in Apple platform deployment and AccessibilitySettings.