This page provides project guidance for teams that must assess an MDriven web application against WCAG requirements. It does not state product conformance.

Scope

The UI & Styling documentation identifies web-UI customization areas including customization and CSS. Changes in these areas can affect the rendered application and should be included in a project accessibility review.

MDriven documentation also describes the ViewModel as a perspective on information for a specific need. It states that action names are exposed to the client and that execution of an action is requested from the server. Review the user-facing names and workflows represented by ViewModels and actions as part of the application assessment.

Project accessibility review checklist

For each project that has WCAG requirements:

1. Define the WCAG version and conformance level required for the delivered application.
2. Identify the relevant user roles, ViewModels, actions, and end-to-end user tasks.
3. Review the rendered application, including project content and styling.
4. Review action names, labels, instructions, status text, and error text for clarity in the context of each task.
5. Include keyboard operation, visible focus, text resizing or zoom, color-dependent information, images or icons, dialogs, and changed or refreshed content in the test scope where these are present.
6. Test the deployed application with the roles, data, customizations, browsers, and assistive technologies that are in scope for the project.
7. Record the deployment, role, ViewModel, task, test conditions, result, and unresolved issues.
8. Repeat the review after changes to ViewModels, actions, or styling that affect the tested task.

Customization review

The UI & Styling documentation includes CSS among the available web-UI customization topics. Treat each such customization as part of the accessibility review scope.

For each affected user task, review whether the customization changes the information presented, the available actions, or the way a user reaches and operates those actions. Record the result against the rendered application.

Review record

Keep evidence at the application level. A review record can identify:

• deployment or URL;
• user role;
• ViewModel and action;
• task being tested;
• browser and assistive technology, where applicable;
• result and outstanding issues; and
• steps needed to reproduce an issue.

See also

• UI & Styling
• High or low exposure to risk