Accessibility · DucDZ

01

Structure and meaning

Compare information and presentation in context of use.

Finalize the test scopeRecord access criteria and screens and statuses that need to be verified.Combines automated testing with keystrokes and screen readers.Example Check both the normal form, the error form and the confirmation dialog box.Measure actual contrastCheck for meaningful text, symbols, and controls in both light and dark interfaces.Check each combination of text, background, focus and status, including sub-content; Record the results next to the sample so system users don't make the wrong choice.Complete tasks using the keyboardMaintain proper focus order, correct operation and exit path from overlay.The documentation should describe the focus and key paths of each element type; a screenshot of the interface does not show this behavior.Keep the focus point visibleDo not remove the focus indicator and do not let the header or panel cover what is currently selected.Check that the focus is not covered by the header, drawer or keyboard; The focus state must be visible on all user backgrounds.

02

Interaction and usability

Try the operation, change the status and continue working.

Use correct names and structuresLabel controls, title hierarchies, and statuses that support tools understand.Prioritize HTML elements with built-in behavior; Add a role or attribute only when it reflects the actual state.Check when the text gets biggerZoom in on text and zoom out on the screen to find content cutouts or missing actions.Read the important changesFor errors, results and progress are reported without suddenly gaining focus.Record physical inspectionTest with a suitable person or support tool and clearly state the untested part.Combine automation tools with keyboard and screen readers; Do not consider an automatic error-free report as proof that all tasks are usable.

03

Complete the experience

Check for details that are easy to miss when putting the design into use.

Document accessibility behavior in the designSpecify accessible names, reading order, focus placement, and dynamic feedback in the design before implementation.Notes should follow the actual action, such as focus after opening a modal or notification after saving, instead of just listing the ARIA attribute.Require accessibility when contributing componentsRequire new or changed components to pass keyboard, accessible name, contrast, and state checks against the system standards.Place responsible person and proof of audit in the contribution form; Accessibility bugs should be tracked like other functionality bugs.

Accessibility Design system

Structure and meaning

Interaction and usability

Complete the experience

How to review

Finalize the test scope

Usage examples

Finalize the test scope

Find a checklist

No checklists found