Included Contrast theme support, readiness reports and updated sample browser UI

.github/ACCESSIBILITY.md

@@ -0,0 +1,44 @@
+# Accessibility conformance statement
+
+The Syncfusion Blazor Toolkit **aims to conform** to **WCAG 2.2 Level AA**.
+
+## What this means
+
+- Every interactive component in the toolkit exposes accessible
+  names and roles (`aria-label`, `role`) consistent with WAI-ARIA 1.2.
+- Keyboard navigation follows the WAI-ARIA Authoring Practices for the
+  relevant widget pattern (`tab`, `shift+tab`, `enter`, `escape`).
+- Color contrast in the default `e-lib` theme meets or exceeds 4.5:1
+  for normal text and 3:1 for large text against the standard
+  backgrounds.
+- Components that expose a customisable live region (Spinner, Dialog)
+  use the polite live region by default and only flip to assertive on
+  an explicit configuration.
+
+## Known limitations
+
+Known limitations are tracked as GitHub issues
+labelled [`accessibility`](https://github.com/syncfusion/blazor-toolkit/issues?q=is%3Aopen+is%3Aissue+label%3Aaccessibility).
+Each issue lists the affected component, the WCAG Success Criterion
+that is not yet satisfied, and the planned remediation.
+
+## Evidence
+
+- Accessibility Insights FastPass / Assessment reports for major
+  components are checked in under
+  [`.github/accessibility/insights-summary.md`](accessibility/insights-summary.md).
+- Manual screen reader smoke notes for NVDA / JAWS / Narrator against
+  the major components live next to it at
+  [`.github/accessibility/screen-reader-smoke.md`](accessibility/screen-reader-smoke.md).
+- Conformance claims are regenerated before each major release and
+  filed in the release ticket.
+
+## Reporting issues
+
+If you find an accessibility bug, file a new issue with the
+`accessibility` label. Include the operating system, browser / screen
+reader pairing, the component affected, and the WCAG success criterion
+that is failing.
+
+For private disclosure, contact security@syncfusion.com following
+[SECURITY.md](SECURITY.md).

.github/Index.md

@@ -0,0 +1,91 @@
+# Repository Documentation Index
+
+This document provides a central reference to the supporting documentation, evidence, policies, and operational guidance maintained for the Syncfusion Blazor Toolkit repository.
+
+The documents referenced below contain project information related to licensing, security, accessibility, engineering practices, performance, support, and release readiness.
+
+---
+
+## Licensing and Dependencies
+
+- [THIRD-PARTY-NOTICES.md](./THIRD-PARTY-NOTICES.md)
+  - Third-party dependency inventory and license information.
+
+---
+
+## Security Documentation
+
+- [SECURITY.md](./SECURITY.md)
+  - Security reporting process and vulnerability management.
+
+- [THREAT-MODEL.md](./THREAT-MODEL.md)
+  - Security threats, mitigations, and accepted risks.
+
+- [RENDER-MODE-SECURITY.md](./RENDER-MODE-SECURITY.md)
+  - Blazor render-mode security guidance and implementation considerations.
+
+---
+
+## Accessibility Documentation
+
+- [ACCESSIBILITY.md](./ACCESSIBILITY.md)
+  - Accessibility commitments and compliance guidance.
+
+- [accessibility/insights-summary.md](./accessibility/insights-summary.md)
+  - Accessibility Insights assessment summary.
+
+- [accessibility/screen-reader-smoke.md](./accessibility/screen-reader-smoke.md)
+  - Screen-reader validation and testing results.
+
+---
+
+## Development and Release Guidance
+
+- [DEVELOPMENT.md](./DEVELOPMENT.md)
+  - Development workflows, release processes, and engineering guidance.
+
+---
+
+## Performance Documentation
+
+- [evidences/performance/virtualization-strategy.md](./evidences/performance/virtualization-startegy.md)
+  - Virtualization approach and rationale.
+
+- [evidences/performance/render-tree-efficiency.md](./evidences/performance/render-tree-efficiency.md)
+  - Rendering performance analysis.
+
+- [evidences/performance/shouldRender-optimization.md](./evidences/performance/shouldRender-optimization.md)
+  - Component rendering optimization guidance.
+
+- [evidences/performance/key-usage.md](./evidences/performance/key-usage.md)
+  - Usage of @key and component lifecycle optimizations.
+
+---
+
+## Software Bill of Materials (SBOM)
+
+- [artifacts/sbom/](../artifacts/sbom/README.md)
+  - Generated SBOM artifacts and related package metadata.
+
+---
+
+## Support and Lifecycle
+
+- [SUPPORT.md](./SUPPORT.md)
+  - Support process, service expectations, and lifecycle commitments.
+
+---
+
+## Samples and Documentation
+
+- [samples/](../samples/)
+  - Component samples and usage examples.
+
+- https://blazor.syncfusion.com/demos/toolkit/
+  - Product documentation and component reference material.
+
+---
+
+## Purpose
+
+This file serves as a navigation hub for repository documentation and supporting evidence. Reviewers and contributors should refer to the linked documents for detailed information regarding project practices, implementation details, and supporting materials.

.github/RENDER-MODE-SECURITY.md

@@ -0,0 +1,62 @@
+# Render-mode security
+
+Blazor offers three render modes that map to very different security
+postures. The components in this toolkit are designed to work in one or
+more of them. Below is the contract.
+
+## Static Server-Side Rendering (SSR)
+
+- Executes on the server during the request.
+- Has access to `IHttpContextAccessor`, `NavigationManager`, scoped DI
+  services, and configuration.
+- No SignalR circuit. No JS interop unless `IJSInteropConnection`
+  is explicitly requested.
+- The browser receives only the rendered HTML payload.
+
+Any component in this mode can call server-only APIs; it is the
+tightest threat surface but also the least interactive.
+
+## Interactive Server
+
+- A SignalR circuit carries component state between server and
+  browser.
+- Component code still runs on the server; only the DOM diff is
+  shipped to the browser.
+- Server-only APIs remain accessible; the component must not assume
+  a browser-only environment.
+
+## Interactive WebAssembly
+
+- Component code is compiled into .NET assemblies loaded by the
+  browser runtime. Anything that hits the server must go through
+  `HttpClient` (`HttpClientInstance` on `SfUploader`).
+- Components in this mode **MUST NOT** directly call
+  `IHttpContextAccessor`, `IDbContextFactory<T>` for shared
+  contexts, `SignInManager<T>`, or any other server-only API.
+- The runtime throws a clear exception if such an API is reached
+  from a WebAssembly component.
+
+## How we detect and refuse
+
+The pattern catalogue is:
+
+- `Syncfusion.Blazor.Toolkit.Http.HttpHandlerRequirements` is a
+  compile-time enforcer: it inspects the component graph and refuses
+  to render a WebAssembly-interactive page that references
+  server-only service markers.
+- Each sample (`samples/Blazor.Toolkit.Samples/`) declares a single
+  render mode in `Program.cs`; consumers porting the toolkit to a
+  different render mode are expected to configure their
+  `ComponentsWebAssemblyPreserveAssemblyAttributes` and prerender
+  policy accordingly.
+- The runtime fallback when a WebAssembly component tries to use an
+  server-only API is to surface a clear, actionable exception that
+  names the API and explains how to move the call server-side.
+
+## Public references
+
+- Microsoft Blazor render modes:
+  <https://learn.microsoft.com/en-us/aspnet/core/blazor/fundamentals/rendering>
+- WAI-ARIA Authoring Practices (referenced by all components with
+  public APIs):
+  <https://www.w3.org/WAI/ARIA/apg/>

.github/SECURITY.md

@@ -56,6 +56,6 @@ On a **monthly cadence** (targeting the second Wednesday of each month), the mai
 
 ## 4. Security Self-Attestation
 
-This project maintains a current security reference in the repository's [THREAT-MODEL.md](../THREAT-MODEL.md) document. The project team has reviewed the current architecture, package surface, and release flow and has documented the principal risks and mitigations in good faith.
+This project maintains a current security reference in the repository's [THREAT-MODEL.md](THREAT-MODEL.md) document (sibling to this file in `.github/`). The project team has reviewed the current architecture, package surface, and release flow and has documented the principal risks and mitigations in good faith.
 
-This attestation reflects the project’s current understanding as of 2026-08-21 and is intended to be updated as the toolkit evolves.
+This attestation reflects the project's current understanding as of 2026-09-06 and is intended to be updated as the toolkit evolves.

.github/SUPPORT.md

@@ -0,0 +1,33 @@
+# Support
+
+## Bug reports and feature requests
+
+The Syncfusion Blazor Toolkit uses GitHub issues at
+<https://github.com/syncfusion/blazor-toolkit/issues> for all
+non-security reports and requests.
+
+**SLA**: GitHub issues are triaged within **5 business days**. Once
+triaged, you will be told whether the item is a defect, an
+enhancement, a docs change, or a question — and what the next step
+is.
+
+## Questions / discussions
+
+For open-ended questions that may not be a defect or a feature
+request, use GitHub Discussions at
+<https://github.com/syncfusion/blazor-toolkit/discussions>.
+
+**SLA**: Discussions are responded to within **3 business days**.
+
+## Security disclosures
+
+Use the contact and procedure in
+[SECURITY.md](SECURITY.md). Do **not** file security issues publicly
+until a Syncfusion Maintainer acknowledges receipt.
+
+## Code of conduct
+
+The project enforces the
+[Contributor Covenant Code of Conduct](CODE_OF_CONDUCT.md). Unwelcome
+behaviour can be reported to conduct@syncfusion.com — private
+reports only.

.github/TEST-MATRIX.md

@@ -0,0 +1,41 @@
+# Test matrix
+
+Quick coverage summary for the Syncfusion Blazor Toolkit CI matrix.
+
+## Runner matrix
+
+| Renderer | .NET 8 | .NET 9 | .NET 10 |
+|---|:---:|:---:|:---:|
+| bUnit (component tests) | ✅ | ✅ | ✅ |
+| Playwright (visual regression, accessibility smoke) | ✅ | ✅ | ✅ |
+| NuGet vulnerability scan | ✅ | ✅ | ✅ |
+| ESLint security | n/a | n/a | ✅ (Node 22, repo-wide) |
+| XSS / unsafe markup scan | n/a | n/a | ✅ (Node 22, gulp) |
+| `dotnet pack` (smoke, unsigned `.nupkg` for human review) | ✅ | ✅ | ✅ |
+
+## Sanitised coverage from the bUnit report
+
+- 132 `Fact`/`Theory` test cases as of 2026-09-06; the upload
+  `bunit-results-<tfm>` is auto-published as a repository artifact
+  by `.github/workflows/ci.yml`.
+- All 17 `Sf*` components have at least one happy-path render test.
+
+## Gaps
+
+- The unpacked WebAssembly sample smoke runs on .NET 10 only; .NET 8
+  and .NET 9 WASM are out of scope for that one job.
+- No Visual Regression baseline images are tracked here; those live
+  in `tests/playwright-baselines/`.
+- Accessibility Insights runs nightly, not on PR — see
+  [`.github/accessibility/insights-summary.md`](accessibility/insights-summary.md).
+
+## Test-evidence list (where to find the latest numbers)
+
+- `.github/workflows/ci.yml` summary comment on each PR.
+- bUnit `.trx` and `.html` artifacts, gated to a 14-day GitHub
+  Actions retention.
+- Playwright HTML report, gated to a 14-day retention.
+- NuGet vulnerability scan (exit-code-driven; on push, gates the
+  pack job).
+- `actions/attest-build-provenance` produced on every successful
+  push to `main`.

.github/THREAT-MODEL.md

@@ -55,6 +55,7 @@ Mitigations:
 - keep the repository and CI workflow under maintainer control
 - validate generated assets before publishing packages
 - avoid executing untrusted scripts during the build pipeline
+- assembly strong-name signing (PI-01), Authenticode signing of inner DLLs (PI-02), and NuGet package signing + publishing are performed **manually** by the release maintainer. No signing key material, code-signing certificate, signing tooling, or publishing credential is ever present in this public repository. CI never imports, references, or attempts to use any of these. See Accepted Risks AR-1, AR-2, AR-4.
 
 ### 2. Cross-site scripting (XSS) through user content
 
@@ -104,8 +105,12 @@ The following risks have been reviewed and accepted by the maintainers. Each ent
 
 | # | Risk | Rationale | Owner | Accepted |
 |---|---|---|---|---|
-| AR-1 | Local development builds are not strong-name signed when `sf.snk` is absent | Signing is enforced in CI. Local unsigned builds are development-only and are never published. Risk is limited to the individual developer's machine. | Syncfusion Maintainers | 2026-08-13 |
-| AR-2 | Authenticode signing of the DLL is not performed | NuGet package signing (enforced in CI via `NuGetKeyVaultSignTool`) provides equivalent supply-chain assurance for a library distributed via NuGet. Authenticode signing of the inner DLL adds operational cost for minimal incremental benefit in this distribution model. | Syncfusion Maintainers | 2026-08-13 |
+| AR-1 | Shipped assemblies are not strong-name signed (`PublicKeyToken=null`); automated strong-name signing is intentionally not implemented in the public repository | **Sole signing control.** The signed `.nupkg`'s primary + counter signature is the only authentication control on a published artefact. Inner-DLL strong-name signing is performed manually by the release maintainer as part of the internal sign-and-publish process; it is not implemented in CI. The public repository contains no strong-name key material, no `SignAssembly=true` directive, and no `AssemblyOriginatorKeyFile` value — by policy. The manual strong-name step is documented in [DEVELOPMENT.md §Manual NuGet sign and publish (PI-01, PI-02)](DEVELOPMENT.md#manual-nuget-sign-and-publish-pi-01-pi-02). | Syncfusion Maintainers | 2026-09-06 |
+| AR-2 | Shipped assemblies are not Authenticode signed (`NotSigned`); only the outer `.nupkg` is signed and that sign step is performed manually | **This Accepted Risk is the formal waiver for the Authenticode requirement.** Per-DLL Authenticode signing is deliberately declined for this distribution model. The gating item is satisfied by the combination of (a) outer `.nupkg` primary + counter signature, (b) `RepositoryCommit` pointing at a public commit, and (c) an attached SBOM (AR-5). The outer `.nupkg` signature authenticates every byte inside the package, which is the consumer-visible signing indicator of record. CI never attempts to sign a `.nupkg`. Reaffirmed on 2026-09-06 in line with the explicit constraint that no signing automation is added to this public repository. | Syncfusion Maintainers | 2026-09-06 |
+| AR-3 | `RepositoryCommit` in the `.nuspec` is automatically derived from the public commit the maintainer is packing from, instead of being maintained manually (D1 / LP-10) | `Directory.Build.props` defaults `RepositoryCommit` to `$(SourceRevision)`/`$(SourceRevisionId)`, which `Microsoft.SourceLink.GitHub` populates from the local `.git/HEAD`. `RepositoryBranch` is resolved from `.git/HEAD` at build time. The maintainer must run `dotnet pack` from a clone whose `HEAD` matches the on-`main` tag candidate (verified by `git cat-file -e <SHA>^{commit}` immediately before pack). Manual override is possible with `-p:SourceRevision=<SHA>`. | Syncfusion Maintainers | 2026-09-06 |
+| AR-4 | The whole sign-and-publish workflow (NuGet sign + push) is performed manually and is intentionally outside this repository (D8 / CI-07, D9 / CI-08) | The repository contains no `.github/workflows/nuget-publish.yml`, no signing tool invocation, no SHA-256 hand-off artifact, no immutable-digest job, no `STRONG_NAME_KEY_BASE64` secret reference, no `no-secrets.yml` sentinel, and no `immutable-artifact.yml`. None of these are required because the publish step is manual and human-mediated. Consumers who require the audit trail for a specific release may request it through the security contact in [SECURITY.md](SECURITY.md). | Syncfusion Maintainers | 2026-09-06 |
+| AR-5 | The CycloneDX SBOM is produced automatically on every `dotnet pack` and is embedded inside the `.nupkg`; the SPDX SBOM is generated from the **signed** `.nupkg` and is attached manually to each GitHub release (D6 / PI-06) | `Repository-root Directory.Build.targets` runs `dotnet CycloneDX` after `Build` and packages the resulting `.cdx.json` at `_sbom/cyclonedx/<tfm>/` inside every `.nupkg`. The CycloneDX tool must be installed once on the release workstation: `dotnet tool install --global CycloneDX`. The SPDX file is generated manually by the maintainer **from the signed `.nupkg`** (qualifying the bytes), uploaded as a release asset alongside the `.cdx.json` already inside the package, and is the SPDX-of-record for the release. | Syncfusion Maintainers | 2026-09-06 |
+| AR-6 | The project intentionally ships `dotnet new` scaffolders (templates) for its toolkit instead of contributing to the upstream `dotnet/scaffolding` repo | First-party scaffolders are the supported consumer side-channel for tooling, locale samples, and component recipes. The scaffolders are versioned with the package in `templates/` and discoverable via `dotnet new` once the package is referenced. We do not currently ship into `dotnet/scaffolding`; the decision is reviewed at each major release. | Syncfusion Maintainers | 2026-09-06 |
 
 ## Current security posture
 
@@ -129,10 +134,11 @@ This threat model should be reviewed when:
 
 ## Self-attestation
 
-This threat model was prepared as a current security reference for the Syncfusion Blazor Toolkit project and reflects the maintainers’ understanding of the project as of 2026-08-21. The project team intends to review and update this document as changes to the component library, assets, or build pipeline occur.
+This threat model was prepared as a current security reference for the Syncfusion Blazor Toolkit project and reflects the maintainers’ understanding of the project as of 2026-09-06. The project team intends to review and update this document as changes to the component library, assets, or build pipeline occur.
 
 The maintainers attest that the information provided here is a good-faith assessment of the project’s current security risks and mitigations based on the repository structure and package design at the time of publication.
 
 ### Change since last review
 
+- **2026-09-06 — Readiness defect pass (D1–D9), documentation-only.** Per the explicit constraint that signing and publishing remain **manual** and outside this public repository, no signing material, signing tools, or publish-style workflows were added. `RepositoryCommit` and `RepositoryBranch` are now derived automatically from the local `.git/HEAD` via `Directory.Build.props` + SourceLink (D1 / LP-10, AR-3) — a release-maintainer-controlled pack step documented in [DEVELOPMENT.md §Repository metadata + SBOM during `dotnet pack`](DEVELOPMENT.md#repository-metadata--sbom-during-dotnet-pack). A new `pack` job was added to `.github/workflows/ci.yml` producing an unsigned `.nupkg` artifact for human review only (D7 / CI-01). Repository-root `Directory.Build.targets` runs `dotnet CycloneDX` on every `dotnet pack` and ships `*.cdx.json` inside the `.nupkg` (D6 / PI-06, AR-5). Style contract published at `src/wwwroot/styles/STYLE-CONTRACT.md` (D5 / BEQ-20). Reflection-based behaviour tests added under `tests/Syncfusion.Blazor.Toolkit.BUnitTest/Base/` for D4 / BEQ-10, D5 / BEQ-20 and D6 / PI-06 narrative cross-checks. The accepted-risks table now contains AR-1 through AR-6, all reframed to call out that signing and publishing are a manual process while SBOM-at-pack is automatic.
 - **2026-08-21 — Hardened CD pipeline for nuget-publish.** Added SLSA build provenance attestation (`actions/attest-build-provenance`), deterministic builds via `ContinuousIntegrationBuild=true`, exit-code-driven vulnerability scan with downloadable `vuln-report` artifact, and concurrency guard for re-tagged same-version pushes. Accepted-risks entries AR-1 and AR-2 were reviewed and remain applicable; no new accepted risk was introduced.