Assess web application accessibility systematically

A web application includes more than its public entry pages. Authentication, search, form steps and feedback determine whether someone can complete a task independently. An assessment plan therefore starts with actual user journeys and their different states.

Define what will be assessed

Record page variants, roles, supported devices and central tasks. Include embedded components and transitions to external systems. This makes it possible to understand later which part of the application a finding or acceptance decision covers.

Automated checks reliably detect certain technical errors, but cannot fully judge a label's meaning or an entire correction workflow. Combine automated checks with manual walkthroughs.

Combine different perspectives

• Check keyboard operation and visible focus.
• Include magnification and narrow viewports.
• Assess structure and feedback with assistive technology.
• Explicitly include errors, loading and empty states.

Prioritize findings by their effect on the task. An issue preventing completion has a different impact from a purely visual inconsistency.

Consider a customer portal as a test scenario: someone signs in, finds a record, changes a detail and receives confirmation. Repeat the journey with invalid input and expired access.

Make findings reproducible

Record the starting state, interaction sequence, observed behavior and expected result. A screenshot alone is insufficient for a focus issue; include the preceding steps. Sanitized test data allows the workflow to be repeated without access to real customer records.

A useful report connects technical details to a specific limitation. Developers and the business team should understand why a correction matters and how success will be verified.

Turn findings into actionable tasks

• Identify the affected component and user task.
• Record ownership and verification steps.
• Group common causes affecting several pages.
• Retest corrections through the original workflow.

When a central component changes, check its different uses. A local correction is not automatically effective everywhere.

For a comparable proposal

• Identify affected forms and complete user journeys with their observed barriers.
• Separate the assessment criteria, manual checks and code remediation in the proposal.
• Agree acceptance cases for keyboard use, focus after dialogs and understandable error feedback.

Accessibility remains a property of the running application. New content, modified forms and replacement components can disrupt previously usable paths. Keep the most important assessment scenarios within the normal change process.

Interpret results accurately

An initial technical review identifies improvements, but does not establish complete conformance. Describe the assessed scope and unresolved findings clearly. That transparency supports planning the next improvements.

Identify user journeys where keyboard interaction or forms currently fail. GSWE scopes a technical assessment and subsequent remediation of those specific barriers with you.

Commission accessibility remediation: Develop design systems for digital platforms.