Skip to content

docs: Publish the accessibility conformance document - #381

Draft
turbobobbytraykov wants to merge 1 commit into
masterfrom
btraykov/docs-accessibility-conformance
Draft

docs: Publish the accessibility conformance document#381
turbobobbytraykov wants to merge 1 commit into
masterfrom
btraykov/docs-accessibility-conformance

Conversation

@turbobobbytraykov

Copy link
Copy Markdown
Contributor

Description

Publishes docs/accessibility-conformance.md — the accessibility conformance record for IgniteUI.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:

  • Scope — every 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.
  • Where defects live — the components are thin .NET wrappers around igniteui-webcomponents custom elements, so roles, names, states, keyboard interaction and focus management belong to the underlying element. The document distinguishes wrapper defects from upstream ones.
  • Verification method — three layers: automated axe-core scanning, keyboard operation coverage, and a once-per-major-release screen reader smoke test. Layers 1 and 2 are recorded as not yet in place — a documented commitment rather than an enforced gate — and the screen reader matrix carries "not yet recorded" rows rather than fabricated ones.
  • Known failures — currently one accepted, unfixed AA defect: Radios added after the group upgrades are not adopted into the group #336 (IgbRadioGroup/IgbRadio group 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):

  • Bug fix
  • New functionality
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Refactoring (no functional changes)
  • Documentation
  • Demos
  • CI/CD
  • Tests
  • Changelog

Component(s) / Area(s) Affected:

Documentation only. No product code, build, or workflow changes.

How Has This Been Tested?

  • Unit tests
  • Manual testing
  • Automated e2e tests

Relative links were checked against master: .github/CONTRIBUTING.md and tests/IgniteUI.Blazor.Lite.IntegrationTests both resolve, as does the README link to docs/accessibility-conformance.md.

Test Configuration:

  • .NET version: n/a
  • Hosting model: n/a
  • Browser(s): n/a
  • OS: n/a

Checklist:

  • All relevant tags have been applied to this PR
  • This PR includes unit tests covering all the new code
  • This PR includes API docs for newly added methods/properties
  • This PR includes general feature table updates in the root README.MD
  • This PR includes CHANGELOG.MD updates for newly added functionality
  • This PR contains breaking changes
  • This PR includes behavioral changes and the feature specification has been updated with them
  • Accessibility (ARIA, keyboard navigation, focus management) has been verified

Reviewer 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.

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.
Copilot AI lite review requested due to automatic review settings August 31, 2026 13:53

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 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.md documenting WCAG 2.2 AA target, scope, verification approach, and known unfixed failures.
  • Linked the conformance document from README.md.
  • Noted the publication in CHANGELOG.md under 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants