docs: Publish the accessibility conformance document - #381
Draft
turbobobbytraykov wants to merge 1 commit into
Draft
docs: Publish the accessibility conformance document#381turbobobbytraykov wants to merge 1 commit into
turbobobbytraykov wants to merge 1 commit into
Conversation
Records the WCAG 2.2 AA claim, the scope it covers (components, render modes, browsers, assistive technology), the three verification layers and the current status of their automation, plus the accepted unfixed failures.
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
Only minor documentation spelling-consistency nits were found; no functional or structural issues.
Pull request overview
Publishes an accessibility conformance record for IgniteUI.Blazor.Lite and surfaces it in the repo’s primary documentation touchpoints (README + changelog), giving consumers a scoped, explicit WCAG 2.2 AA statement and known-failures record.
Changes:
- Added
docs/accessibility-conformance.mddocumenting WCAG 2.2 AA target, scope, verification approach, and known unfixed failures. - Linked the conformance document from
README.md. - Noted the publication in
CHANGELOG.mdunder Unreleased → Added.
File summaries
| File | Description |
|---|---|
| README.md | Adds an Accessibility section linking to the conformance record. |
| docs/accessibility-conformance.md | Introduces the conformance document (scope, verification method, known failures). |
| CHANGELOG.md | Records the addition of the conformance document for the next release notes. |
Review details
Suppressed comments (1)
docs/accessibility-conformance.md:62
- This sentence uses British spelling (“behaviour”) while the rest of the repository uses “behavior”. Updating to “behavior” keeps wording consistent across docs and code comments.
Open an issue at [github.com/IgniteUI/igniteui-blazor/issues](https://github.com/IgniteUI/igniteui-blazor/issues) describing the component, the render mode, the assistive technology and browser, and the expected versus observed behaviour. If the defect is in the underlying custom element it will be reproduced against [`igniteui-webcomponents`](https://github.com/IgniteUI/igniteui-webcomponents) and tracked there, with the tracking issue linked back into the table above.
- Files reviewed: 3/3 changed files
- Comments generated: 2
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| | Browsers | Chromium, Firefox, and WebKit current stable | | ||
| | Assistive technology | NVDA, JAWS, and VoiceOver — see the smoke matrix below | | ||
|
|
||
| Static server rendering is explicitly **out of scope for the conformance claim**. Components in that mode render as unupgraded custom elements with no interactive behaviour and no ARIA semantics, because the custom element definitions are never executed. See [render mode support](https://www.infragistics.com/products/ignite-ui-blazor/blazor/components/general-getting-started-blazor-web-app#add-ignite-ui-for-blazor-component) for the supported configurations. |
|
|
||
| ### Status of the automation | ||
|
|
||
| **The axe-core scan and the keyboard suite described above are not yet in place.** They are being implemented on a separate branch against the existing Playwright integration suite in [`tests/IgniteUI.Blazor.Lite.IntegrationTests`](../tests/IgniteUI.Blazor.Lite.IntegrationTests). Until that lands, layers 1 and 2 above are a documented commitment rather than an enforced gate, and no per-release scan artefact exists. |
damyanpetev
marked this pull request as draft
September 2, 2026 06:56
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Publishes
docs/accessibility-conformance.md— the accessibility conformance record forIgniteUI.Blazor.Lite— and links it from the README and the changelog.The document states the WCAG 2.2 Level AA target and is deliberately specific about what has and has not been verified, because a conformance document that implies more testing than was performed is worse than none:
Igb*component, Interactive Server and Interactive WebAssembly render modes, current-stable Chromium/Firefox/WebKit, and NVDA/JAWS/VoiceOver. Static server rendering is explicitly out of scope: the custom element definitions never execute in that mode, so there is no interactive behaviour and no ARIA semantics to claim.igniteui-webcomponentscustom elements, so roles, names, states, keyboard interaction and focus management belong to the underlying element. The document distinguishes wrapper defects from upstream ones.IgbRadioGroup/IgbRadiogroup adoption), attributed upstream.Motivation / Context
This is the ACC-01 gap from the package readiness assessment: the library made an accessibility claim in marketing copy with nothing in the repository substantiating it, scoping it, or listing what is known to be broken. Consumers with a procurement or VPAT requirement had nothing to point at.
Split out of #371 so the conformance record can be reviewed and merged on its own rather than as a footnote to a release-workflow refactor.
Type of Change (check all that apply):
Component(s) / Area(s) Affected:
Documentation only. No product code, build, or workflow changes.
How Has This Been Tested?
Relative links were checked against
master:.github/CONTRIBUTING.mdandtests/IgniteUI.Blazor.Lite.IntegrationTestsboth resolve, as does the README link todocs/accessibility-conformance.md.Test Configuration:
Checklist:
README.MDCHANGELOG.MDupdates for newly added functionalityReviewer notes
The two claims worth scrutinising are the ones the document declines to make: the automation section says the axe-core and keyboard suites are not yet enforced, and the smoke matrix rows say not yet recorded. If we would rather not publish an unfinished verification story at all, the alternative is to hold this until the automation lands — but that leaves the scope and known-failure record unpublished in the meantime, which is the more expensive gap.