Client-side navigation
Page titles, focus and announcements may not update predictably.
Accessible dynamic .NET interfaces
Blazor and ASP.NET accessibility
Accessibility testing and implementation support grounded in how Blazor and ASP.NET applications render, navigate and update.
Webmedic connects keyboard, screen reader, focus and validation failures to practical Razor, C# and JavaScript changes.
Why dynamic .NET interfaces need manual testing
Static scans miss behaviour created after rendering.
Markup can pass basic rules while focus disappears after navigation, errors remain silent or component state becomes unclear.
Custom components
Clickable divs and incomplete keyboard models can block interaction.
Dynamic validation
Errors and status changes may be visible but not announced.
Third-party controls
Grids and component suites may impose vendor-dependent constraints.
What you receive
Findings connected to the .NET implementation.
The review accounts for the render model, component lifecycle, shared abstractions and server interaction.
Component diagnosis
Trace repeated problems to the responsible Razor component or primitive.
Developer guidance
Expected semantics, keyboard behaviour, focus and validation outcomes.
Pull-request support
Implement changes or review the team's accessibility fixes.
Journey retesting
Verify the resulting behaviour for agreed roles and states.
Typical coverage
Typical .NET coverage
Routing, components, dialogs, forms, validation, focus, live updates and third-party controls.
Structure and semantics
Headings, landmarks, names, roles, states and relationships.
Content and presentation
Instructions, alternatives, contrast, zoom and responsive reflow.
Keyboard and focus
Order, visibility, navigation, dialogs and custom interactions.
Forms and errors
Labels, required fields, validation, summaries and recovery.
Assistive technology
Screen reader output, announcements and dynamic changes.
Responsive states
Mobile layouts, orientation, reflow and touch targets.
Process
A clear process from scope to verified results.
The exact environments, roles, journeys and deliverables are agreed before testing.
- 01
Agree the scope
Confirm priority pages, components, roles and user journeys.
- 02
Prepare access
Set up safe environments, accounts, data and known constraints.
- 03
Assess the behaviour
Run the agreed automated, keyboard, responsive and assistive technology checks.
- 04
Document or implement
Record actionable findings or apply agreed changes in the responsible layer.
- 05
Verify the outcome
Retest the original behaviour and complete affected journeys.
Who it is for
Teams building rich Blazor and ASP.NET applications with authenticated workflows.
The scope is adapted to the product, platform, team and delivery stage.
Business websites and digital services
E-commerce and booking journeys
SaaS products and customer portals
Agencies supporting client projects
Product, development and QA teams
Organisations operating in European markets
Why Webmedic
Technical accessibility work connected to real implementation.
Findings are written for action and consider shared components, application state and delivery constraints.
Developer perspective
User impact is connected to the responsible code and component behaviour.
Clear evidence
Location, state, reproduction steps and expected behaviour are recorded.
Root causes first
Repeated defects are grouped so shared causes can be addressed first.
Verification included
Agreed fixes can be retested against the original acceptance criteria.
Technical and legal scope
Results apply to the agreed routes, roles, data states, component versions and test environment.
The service applies to the agreed pages, components, roles, content and tested version. New releases can introduce new barriers.
Third-party widgets and closed components can be assessed, but remediation may depend on the supplier or available extension points.
Webmedic provides technical accessibility assessment and implementation support using WCAG 2.2 Level AA as the primary reference. This is not legal advice, legal certification or a guarantee of compliance.
Frequently asked questions
Questions before you begin.
Before work starts, we agree the scope, pages, user journeys, deliverables and responsibility for implementation.
Ask another questionDo you work with Blazor Server and WebAssembly?
Yes. The method is adapted to the hosting and render model.
Can you assess a private application?
Yes, with agreed safe test access, roles and data.
Can third-party component libraries be fixed?
It depends on source access, templates, extension points and vendor support.
Are axe or Lighthouse enough for Blazor?
No. They do not reliably test focus after navigation, validation, dialogs and complete journeys.
Can you work through pull requests?
Yes. Webmedic can implement changes or review and retest the team's pull requests.
Bring one difficult component or journey
Have a Blazor interaction that is hard to make accessible?
Send the application type, affected route, user role and observed behaviour.