Keyboard dead ends
Controls may be unreachable or trap focus.
Test complete tasks and interface states
Accessibility testing
Focused manual testing for a release, feature, component set or critical customer journey.
Automated tools support the work, while keyboard, screen reader, focus, forms and responsive behaviour are tested manually.
Why journey-based testing matters
Passing a scanner does not mean a feature is usable.
Real behaviour depends on focus, interaction order, validation, loading states and dynamic updates.
Silent updates
Visual changes may not be announced to assistive technology.
Broken error recovery
Users may receive an error without a clear way to locate or correct it.
State-dependent defects
A component may only fail after filtering, validation or navigation.
What you receive
Evidence matched to the agreed test scope.
Results are concise enough for release decisions and detailed enough for defect resolution.
Test matrix
Browsers, roles, devices, assistive technology and journeys.
Confirmed defects
Reproduction steps, impact, evidence and expected behaviour.
Retest status
Pass, fail or partially resolved results for agreed findings.
Journey summary
A clear view of whether the critical task can be completed.
Typical coverage
Typical testing coverage
Keyboard, screen reader, forms, responsive presentation and dynamic states.
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
Product and QA teams validating a release or important user journey.
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
Testing results apply to the agreed environments, data, roles and release.
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 questionIs this the same as a full audit?
No. Testing can focus on a release, feature or journey, while an audit normally covers a representative wider scope.
Which screen reader do you use?
The browser and assistive technology are agreed for the scope and recorded in the results.
Can you test authenticated systems?
Yes, with agreed safe test accounts, roles and data.
Can testing be added to release QA?
Yes. A repeatable accessibility test matrix can be integrated into release checks.
Are automated tools included?
Yes, as supporting checks rather than a replacement for manual testing.
Add accessibility to your release decision
Have a feature or journey ready to test?
Send the staging URL, roles, critical tasks and release date. Webmedic will propose a focused test matrix.