Ensuring your application is usable by persons with disabilities is a crucial task. The Universal Access Panel is where you provide the semantic layer required by screen readers (such as VoiceOver on iOS or TalkBack on Android) to describe your visual components to users who are visually impaired.

In Shipcode, accessibility is split into two key areas:

1. Visual Best Practices: Ensuring adequate color contrast, reasonable font sizes, and spacing (handled primarily in the Inspector Panel).
2. Semantic Announcing: Using the properties below to ensure a screen reader can understand and describe non-textual or complex components (handled in the Universal Access Panel).

The properties in this panel adhere to industry standards, leveraging both WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) standards for Web/PWA and native mobile accessibility APIs.

Data Binding

Just like the main Settings Panel, nearly all text fields in the Universal Access Panel are Data Pickers. This means the accessibility information can be:

1. Static: A hard-coded string (e.g., "Back button").
2. Dynamic (FQL): Bound to a Data Zone or Flow for localization, dynamic status updates, or to include content from a data source.

Core Semantic Identity

These are the primary properties used to communicate what a component is and what it does to a screen reader.

Aria-label

• Purpose: A short, descriptive string that acts as the component's name for a screen reader. This is the most essential text property for accessibility, as it is read immediately. It is used to provide context for non-text components like icons or buttons with only visual cues.
• Best Practice: The label should be concise, but clear.
• Example: For a backwards-facing arrow icon used as a navigation button, the Aria-label should be "Back button."

Accessibility hint

• Purpose: Provides more detailed, actionable information about the consequence of interacting with the component. This property is primarily consumed by native mobile applications (iOS/Android) and is often announced after the Aria-label.
• Best Practice: Always start the hint with an action verb.
• Example: For a checkout button, the hint should be "Navigates to the final payment screen."

Structural & Semantic Role

These settings define the component's place and function within the page hierarchy, ensuring the screen reader conveys the correct structure to the user.

Role (Dropdown Selector)

• Default Value: None
• Purpose: The Role is a predefined semantic descriptor that tells the screen reader how a component functionally relates to the page structure. Because Shipcode develops cross-platform applications, you use the Role attribute to replace traditional semantic HTML tags (like <h1>, <ul>, or <button>).
• Example: If you use a View and Text component together to create a custom tab, setting the Role of the View to "Tab" ensures the screen reader recognizes it as part of a tab structure, not just a generic container.

Aria-level (Data Picker: Text Field)

• Purpose: Used exclusively when the Role property is set to "Heading." It defines the heading's hierarchical level, similar to HTML's <h1> through <h6> tags.
• Best Practice: Use a numerical value from 1 to 6. Level 1 should be reserved for the main title of the Layout/page.
• Example: To define a major section header, set the Role to "Heading" and set Aria-level to 3.

Interaction and Grouping

These properties control how a screen reader treats nested components and how a keyboard navigates the application.

Accessible (Toggle)

• Default Value: Off
• Purpose: When enabled, this property indicates that the current component and all its nested children should be treated as a single, unified accessible element by the screen reader.
• Example: If you build a single button by nesting an Image icon and a Text label inside a Link component, you must enable Accessible on the parent Link. This prevents the screen reader from redundantly announcing the Link's function, then the Image's existence, then the Text's content.

Tab Index (Data Picker: Text Field)

• Purpose: Controls the order in which focus moves when a user navigates the application using the Tab key on a keyboard (essential for web/PWA accessibility).
• Best Practice:
• • Positive Number (> 0): Sets an explicit focus order. Components are traversed in ascending order. Use sparingly, as this can override natural document flow.
  • 0: Allows the component to be focusable and part of the sequential tab order, but its position is determined by its layout order.
  • -1: Makes the component non-focusable but leaves it available to be focused programmatically (e.g., via a Flow).