WebsiteDesignOutsource.com research

ARIA Review Boundaries for Outsourced Website Design

When an outsourced design review should inspect ARIA, native HTML semantics, and custom interaction behavior.

ARIA can describe custom interface behavior, but it cannot substitute for an understandable interaction model. A design review should first ask whether native HTML expresses the component, then verify any remaining roles, states, and properties against the implemented behavior.

Research basis

The WAI-ARIA specification and Authoring Practices define roles and interaction patterns, while the HTML specification supplies native elements. WCAG's name, role, value and keyboard criteria make the handoff testable across visual and assistive interfaces.

Review method

For each custom component, record its purpose, keyboard model, focus behavior, accessible name, state changes, and the native element considered. Test the component in its collapsed, expanded, disabled, selected, loading, and error states where those states exist.

Sources

1. WAI-ARIA 1.2 ARIA semantics.

2. ARIA Authoring Practices Interaction patterns.

3. W3C WCAG 2.2 Accessibility requirements.

4. W3C name role value Programmatic semantics.

5. W3C keyboard Keyboard access.

6. WHATWG HTML Native semantics.

7. MDN ARIA ARIA overview.

8. W3C focus visible Focus visibility.

9. W3C status messages Dynamic updates.

10. W3C pointer cancellation Pointer interaction.

Further reading

Form layout accessibility

Accessibility review operations

Related Research

Related reading

Related reading

Related reading

Frequently asked questions

Should every component use ARIA?

No. Native HTML is usually the better starting point when it expresses the required behavior.

Can a screenshot prove an ARIA implementation?

No. The review needs rendered semantics and interaction tests in addition to visual evidence.

Ready to plan your next step?

Contact WebsiteDesignOutsource.com