Add some more docs for render mode and aria, for easier discoverability.

[MayaKirova]

Description

Add explicit information in the README about render modes and accessibility for easier assements.

[Copilot]

🟡 Changes recommended

The new render-mode guidance is placed in the WebAssembly getting-started section but render modes apply to Blazor Web Apps, which can mislead standalone WASM users.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Updates the repository README to improve discoverability of hosting/render-mode requirements and accessibility ownership for Ignite UI for Blazor consumers.

Changes:

• Added a “Supported render modes” section describing interactive render mode requirements.
• Added an “Accessibility (WAI-ARIA)” section clarifying that ARIA patterns/keyboard behavior/testing are owned by the Ignite UI Web Components repo.
• Minor whitespace cleanup (e.g., trailing spaces).

File summaries

File	Description
README.md	Adds documentation for supported interactive render modes and accessibility/WAI-ARIA guidance; also trims minor whitespace.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[MayaKirova]

• About the render mode - the skills seems to find and read the render mode info properly now and marked most of the related notes as verified.

Here's the re-assessment (on RadioGroup - 1 component):

Full BEQ scorecard (24 IDs)

ID	Requirement (abbrev.)	Status	Evidence
BEQ-01	Supports latest .NET GA TFMs	verified	csproj net8.0;net9.0;net10.0; builds clean on net10 (0 errors)
BEQ-02	Supported render modes documented	verified	README "Supported render modes": InteractiveServer/WebAssembly/Auto
BEQ-03	Unsupported modes fail safely/documented	verified	README: static SSR explicitly unsupported (JS-interop rationale) + per-page guidance
BEQ-04	Prerender correctness (no double-init/state loss)	not tested	InteractiveServer run (prerender on by default) surfaced no console errors, but no explicit double-init/state assertion. Follow-up: assert prerendered markup + single init
BEQ-05	Static SSR usefulness/accessibility contract	verified	README documents SSR unsupported → requires interactive; explicit contract
BEQ-06	Interactive Server works	verified	Runtime: IgbRadioGroup+IgbRadio render under @rendermode InteractiveServer, zero console errors (isolated pass)
BEQ-07	Interactive WebAssembly works	not tested	WASM mode registered/supported, but harness runs the radio on the Server-mode Home page. Follow-up: WASM page rendering the group
BEQ-08	Interactive Auto works	not tested	README claims Auto; not exercised by harness. Follow-up
BEQ-09	[Parameter] not mutated internally	defect	Change handler writes this.Value (RadioGroup.cs) + author TODO on bounce risk
BEQ-10	[EditorRequired] on required params	not applicable	All params optional; no conceptually-required parameter
BEQ-11	Callbacks use EventCallback	verified	EventCallback<string> ValueChanged, EventCallback<IgbRadioChangeEventArgs> Change, EventCallback<bool> CheckedChanged
BEQ-12	Callbacks awaited; failures reach host	defect	Fire-and-forget InvokeAsync, only sync exception observed (BaseRendererControl.cs ~L2985-3040; RadioGroup.cs)
BEQ-13	State changes marshaled to Dispatcher	verified	EventCallback marshaling + clean isolated runtime run; parallel Dispatcher error was infra (port clash), not component
BEQ-14	No unobserved fire-and-forget async	defect	Callback task discarded after sync-exception check (same evidence as BEQ-12)
BEQ-15	Cleanup of timers/subscriptions/JS refs	verified	TrySendCleanupAsync (BaseRendererControl.cs ~L3216-3283): JS cleanup + queue clear + broad catch; disposes DotNetObjectReference. Minor: EnsureReady Task.Delay(100) poll loop has no CancellationToken
BEQ-16	IAsyncDisposable implemented correctly	verified	ValueTask DisposeAsync() idempotent (disposedValue), awaits cleanup, SuppressFinalize (~L3187-3206)
BEQ-17	JS interop via narrow module-scoped APIs	defect	Global window.ig* API + global bootstrap injection instead of IJSObjectReference module isolation
BEQ-18	Avoid interop during init/prerender	verified	Interop only in OnAfterRenderAsync(firstRender)/EnsureReady; OnInitialized interop-free, OnParametersSet interop commented out
BEQ-19	Typed serialization; untrusted values escaped	verified	SerializeCore uses typed AddStringProp/AddEnumProp; RendererSerializer writes via Utf8JsonWriter.WriteString (JSON-escaped)
BEQ-20	CSS isolation / scoped styling contract	verified	Styling encapsulated in igc-* web-component shadow DOM + _content/IgniteUI.Blazor/themes CSS; no leak surface on Blazor side
BEQ-21	Nullable clean or accepted migration plan	maintainer evidence required	csproj <Nullable>disable</Nullable> + TODO; 1785 build warnings. Need the tracked, documented migration plan (repository-wide)
BEQ-22	XML doc comments accurate	verified	Thorough <summary>/<param> on RadioGroup.cs & Radio.cs matching behavior
BEQ-23	Samples cover every supported render mode	defect	Single BlazingStory host; no per-render-mode radio sample
BEQ-24	Explicit SemVer/experimental/compat policy	maintainer evidence required	CHANGELOG.md exists but no explicit SemVer/support/compat policy found in README/CHANGELOG (repository-wide)

• About the ARIA - it didn't help much.

The agent still tried running a sample to check for aria attributes, kb nav and so on. Probably because the skill explicitly tells it to: https://github.com/dotnet/aspnetcore/pull/68627/changes#diff-2187b115d4ead7ac9d38d55d9fd2dc4a152a62acbaa21b64d624bc55b6956e86R18

If we don't want it to do that, it will require changes on the skill.

Here's the re-assessment:

A11Y scorecard (12 IDs)

ID	Requirement (abbrev.)	Status	Evidence
A11Y-01	WCAG 2.2 AA conformance	maintainer evidence required	Formal conformance owned upstream (README); not attested in this repo. Browser probe surfaced grouping/keyboard gaps to reconcile
A11Y-02	No known AA failures at ship	maintainer evidence required	Upstream-tracked; this repo has no conformance record. Observed grouping/keyboard gaps flagged for confirmation
A11Y-03	Automated a11y scanning clean each release	maintainer evidence required	A11y scanning/gating lives upstream; not evidenced in this repo. Follow-up: run axe on the story
A11Y-04	Full a11y assessment per major release	maintainer evidence required	Upstream attestation; not in this repo
A11Y-05	Screen-reader smoke testing recorded	maintainer evidence required	Upstream; not run here
A11Y-06	Keyboard-only operation verified	defect	Arrow roving absent; all radios tabindex=0 (separate tab stops), not the radio-group pattern (runtime probe). Upstream-owned
A11Y-07	Focus order/trapping/restoration/visible focus	not tested	Focus enters the clicked input correctly; visible focus indicator + full order/restore not verified
A11Y-08	Roles/names/values/states/relationships	defect	Roles/names/checked OK; relationships missing — no radiogroup role/group name (runtime a11y tree). Upstream-owned
A11Y-09	Selection/expansion/validation/async announced	not tested	Selection announced ([checked] in a11y tree); Invalid/validation announcement not exercised; no expansion/async for radio
A11Y-10	High Contrast / forced-colors	not tested	Not exercised; theming owned upstream
A11Y-11	User-facing strings localizable	verified	Radio owns no hard-coded user strings; labels are consumer child content (localizable). Resource-string mechanism exists for components that need it (e.g. CalendarResourceStrings.cs)
A11Y-12	RTL recorded when claimed	not applicable	RTL not claimed for this component in this repo

[skrustev]

Here's the summary I was able to get by the agent related to the render mode and ARIA. For my assessment it does recognize the name/role and such. The listed defects do sound valid but probably needs to be investigated:

I think for my case it directly tested the component for the ARIA and was not relying on docs for it.

For the render mode I think its fine as is. The failure on unsupported modes does not sound like critical to be fixed atm.

---

4.3.1 ARIA readiness summary

Overall ARIA readiness: not ready for an unqualified accessibility claim. The tested Radio Group exposes the core ARIA radio structure correctly, but validation state and composite keyboard behavior have release-blocking gaps. This conclusion is limited to the exact 0.1.1 package in Chromium and is not a formal WCAG or assistive-technology certification.

ARIA area	Readiness	Assessment
Group role and containment	Ready in tested configuration	The container is exposed as radiogroup, all tested items are exposed as radio, and each radio is contained by the expected group.
Accessible names	Ready in tested configuration	Group names from aria-label or aria-labelledby and radio names from slotted labels were exposed correctly.
Checked and disabled states	Ready in tested configuration	Checked and disabled states were exposed correctly and updated when selection changed.
Invalid state	Defect	Invalid="true" changes visual styling, but the accessibility tree still reports invalid="false" and the underlying input has no aria-invalid.
Required state	Defect	Required="true" does not expose a required state to the accessibility tree.
Composite keyboard pattern	Defect	Without a shared radio name, arrow keys do not move focus or selection and the group does not consistently provide a single roving Tab stop. Adding a shared name fixes the tested behavior, but the released wrapper has no public Name parameter.
Focus indication	Defect	Keyboard focus is not visible under forced-colors emulation because the focus treatment relies on a box shadow that disappears.
Selection and validation announcements	Evidence required	No release-aligned screen-reader record establishes that selection and validation changes are announced correctly.
Automated scan	Limited positive evidence	axe-core 4.13.0 reported no Radio Group-specific violation, but automated scanning did not detect the keyboard, validation-state, or forced-colors failures found through direct testing.
RTL semantics	Behavior passed; support evidence required	RTL layout and mirrored arrow behavior passed after supplying a shared name, but no release-aligned RTL support claim was found.

The primary ARIA remediation needs are:

1. Expose invalid and required state through the computed accessibility API.
2. Provide a public grouping mechanism that enables the expected radio-group arrow-key and roving-tabindex behavior by default.
3. Preserve a visible focus indicator in forced-colors environments.
4. Add release-aligned screen-reader coverage for names, selection changes, validation, disabled state, and required state.

4.4.1 Render mode readiness summary

Overall render-mode readiness: runtime-ready for the tested interactive modes, but documentation is not release-ready. Radio Group operated correctly in Interactive Server, Interactive WebAssembly, and both phases of Interactive Auto. Prerendering did not throw. The released package does not, however, provide a clear supported-mode matrix, an explicit unsupported-mode contract, or a useful Static SSR accessibility and behavior contract.

Render mode	Readiness	Assessment
Prerendering	Verified	Static prerender output contained the Radio Group elements and did not throw. Interactive WebAssembly subsequently attached and upgraded the custom elements successfully.
Interactive Server	Verified	Existing browser infrastructure exercised Radio Group on Interactive Server. The targeted keyboard probe also reproduced component behavior on Server.
Interactive WebAssembly	Verified	The exact 0.1.1 package attached on WebAssembly, registered and upgraded its custom elements, and passed selection, binding, callback, typed change-detail, and bidirectional DOM synchronization checks.
Interactive Auto — initial visit	Verified	A cold first visit ran interactively on Server. Selection, callbacks, and .NET-to-DOM synchronization worked.
Interactive Auto — subsequent visits	Verified	Later visits in the same browser profile ran on WebAssembly and preserved correct Radio Group behavior. Auto changed execution environment on a later navigation rather than during the active page instance, as expected.
Static SSR	Documentation defect	Current documentation says Static SSR is unsupported, but the exact package does not publish a clear usefulness, accessibility, or failure contract for non-interactive Radio Group output.
Unsupported modes	Documentation defect	The released package does not clearly identify every unsupported mode or state how the component behaves when interactivity is unavailable.
Public mode-specific samples	Coverage defect	Public samples do not behaviorally assert Radio Group operation in every supported render mode.

The targeted interactive probes observed:

• correct bound-value changes and callback counts after browser selection;
• correct checked state and host value synchronization;
• successful .NET-driven selection updates back to the DOM;
• successful custom-element registration and shadow-root upgrade;
• no component-attributable browser-console error;
• no failed Radio Group package asset request;
• only an expected _blazor/disconnect aborted beacon when navigating away from the initial Auto Server visit.

The primary render-mode readiness actions are:

1. Publish an explicit Radio Group support matrix for Static SSR, Interactive Server, Interactive WebAssembly, and Interactive Auto.
2. Document the exact Static SSR output, accessibility, and non-interactive behavior contract.
3. Document safe behavior for unsupported or unavailable interactivity.
4. Add behaviorally asserted public examples and CI coverage for each supported mode.

---

Here's the full assessment file:
radio-group-readiness.md