Telefonica
Document Heading annotations for native apps [annotation kit]
Description
In native applications (Android and iOS), a single level of Heading is used for all headers. This means that, even though different levels of headers (H1, H2, H3, etc.) are specified in the design, they are translated into a single level of Heading in the implementation.
In the annotation kit, we are currently defining multiple levels of Heading (H1, H2, H3, etc.), commonly used for web accessibility, without differentiating this specific use case for native applications.
Additional Information
Android: It only has one level of Heading. An element can either be a Heading or not (boolean). There is no possibility of defining multiple levels. Reference: Android Documentation on setAccessibilityHeading.
iOS: < iOS 17: We can only identify elements as Header or not Header, without specifying a level. This applies to both UIKit (uiaccessibilitytraits) and SwiftUI (isHeader). iOS 17+:
- UIKit: We still cannot specify Header levels (uiaccessibilitytraits).
- SwiftUI: It is now possible to specify Header levels using accessibilityHeadingLevel. However, most of our apps currently use UIKit, so this functionality is not available in practice.
Reference: Apple Documentation on AccessibilityHeadingLevel.
Proposal
Add a specific slide to the Annotation Kit documentation to explain the use case for iOS and Android. The slide should state the following: "In Apps (Android and iOS), a single level of Heading will be used for all headers, regardless of the levels defined in Figma (H1, H2, H3, etc.). This means that all headers will be implemented as the same level of Heading." Include in the example a generic Stamp Heading without specifying levels.
References
Apple Documentation on AccessibilityHeadingLevel
Android Documentation on setAccessibilityHeading
Tasks
- [ ] Update specs
- [ ] Design documentation
- [ ] Add to mobile library
- [ ] Add to desktop library
- [ ] Add to UI Kit
- [ ] Android ticket
- [ ] iOS ticket
- [ ] Web ticket
