<IcDataTable> API Enhancement for Cell‑level Attributes (e.g. lang, aria, data)

Nobody has claimed this yet.

### Summary

Enhance ` `to allow cell‑level HTML attributes (e.g. lang, aria-*, data-*) to be specified declaratively in the data model. This enables accessibility compliance and richer metadata without requiring slot‑based overrides.

### 💬 Description

Currently, `` cannot set HTML attributes directly on individual `` cells via its data API.
If attributes such as lang are needed for WCAG 3.1.2 compliance, each cell must be overridden in JSX via a slot, with an extra element inside (e.g. ).

This introduces code duplication and maintenance overhead:

- Multiple slot overrides per table for every column that needs attributes.
- Scattered attribute logic in the render tree instead of a single centralised step.
- Increased risk of missed attributes in large tables.

Proposed solution:
Allow each cell in the data model to include:

```
{
value: string;
attributes?: Record;
}

```
All attributes provided will be applied directly to the `` element during rendering.

### 💰 Use value

- Accessibility — Meets WCAG and ARIA requirements natively.
- Automation — Allows data-testid or other selectors for end‑to‑end testing.
- Analytics — data-* hooks for tracking user interaction with specific cells.
- Styling — Conditional formatting via data-* attributes without inline styles.
- Governance — Tag sensitive data per cell (data-sensitivity) for UI/processing rules.
- Consistency — Single source of truth for attributes in data prep, no render‑time duplication.

### 📝 Acceptance Criteria

Given
A ` `cell object includes an attributes property.

When
The table renders.

Then

1. Attributes appear on the `` for that cell.
2. No attributes? `` renders as usual.
3. Sorting, pagination, filtering, selection behave normally with attributes.
4. Attributes are type‑checked and safe for rendering (XSS protected).
5. Types updated to support attributes?: `Record.`

### ✏ Designs

No visual UI change — affects DOM only.

Documentation examples should show:

- Accessibility: `lang`, `aria-label`
- Automation: `data-testid`
- Styling: `data-status`
- Governance: `data-sensitivity`

### 🧾 Guidance

[WCAG3.1.2 - Language of Parts]
(https://www.w3.org/WAI/WCAG21/Understanding/language-of-parts)

### 🚨 Urgency (low, medium or high)

Medium — Current workaround works for single columns but scales poorly when multiple attributes are needed across a table. Adding now avoids repeated slot overrides and future technical debt.

### Additional info

While lang is a key accessibility driver for multi‑language tables:

- ARIA attributes (aria-label, aria-describedby) for richer assistive tech.
- Automation hooks (data-testid) for testing frameworks.
- Analytics (data-metric) for usage tracking.
- Conditional styling (data-status) for CSS rules.
- Security & governance (data-sensitivity) for policy enforcement. This universality makes it beneficial for all teams, not just those with multilingual data.

### Three-Stage Diagram - Evolution of Attribute Handling

Locate the IcDataTable implementation, its cell data type definitions, and existing rendering and documentation entry points; start by tracing how a cell becomes a . Check the acceptance criteria for attribute application, unchanged table behavior, type safety, and safe rendering, then add the requested accessibility and data-attribute examples to the documentation.

Written by the indexing model from the issue text.