New best practice rule: Warn users when using role="application"

[iamrafan]

@WilcoFiers I filed this issue to kick off the discussion on how to handle the usage of role="application".

[WilcoFiers]

After some discussion we decided that the way forward with this is to look for specific patterns with role=application that cause inaccessibility. Things like content nodes that aren't part of a widget, and that aren't used in computing an accessible name might give a strong indication if role=application is used incorrectly.

[WilcoFiers]

Proposal on the table is to add a best practice rule that always flags this for review, and have an option in the check that lets you automatically fail it.

[marcysutton]

I did some reaching out online for use cases on Wilco's suggestion; not exactly scientific but there are some great insights in this thread, particularly from James Teh and Marco Zehe: https://twitter.com/marcysutton/status/1058111861139402755

From James Teh at Mozilla:

Google Docs, Google Sheets. The old Yahoo Mail from years ago (while @vick08 and @todd were there) was a phenominally good example. Felt like using a desktop app. Gmail is clunky in comparison. IMO, you should only ever use application on the body, and only if said body is control based rather than content based, with a highly efficient and tuned keyboard experience. Any area containing "content" must be marked as role document. In a mail client, the main UI would be the body with role application. Messages get role document. That way, there's a clear boundary between message content and the main UI.

[marcysutton]

application-role-inaccessible-content

• description: Ensures the ARIA application role is used effectively to not hinder navigation of content with assistive technologies

• help: role application should not create inaccessible content

Tags: cat.aria, experimental, best-practice

Selector

[role="application"]

Checks

application-role-inaccessible-content ( none )

1. No role of application should contain headings, paragraphs, and other static content without a role of document wrapping those content nodes. This ensures users can navigate that static content with AT commands like navigating by headings. Without that document role, every keystroke is passed directly to the browser–and without recreating that functionality, the interface can become unusable to screen reader users.

This check would evaluate child content and look for static content (h1-h6, p, span, ??), and fail if those nodes are not wrapped in role="document".

application-role-body, optional ( all )

2. This check would recommend using role="application" on the body element only, and failing or putting it into review if present on other DOM nodes. Up for discussion–I could see this one being too limited.

[WilcoFiers]

This would only ever be a rule that flags things for review (description above). There is some precedence for this in rules like video-captions, which only flags it for review. The problem of role=application when misused is so substantial I think it is worth a rule that only flags things for review.