Accessibility

[agubler]

Epic

All Dojo 2 applications to be as accessible as possible. Giving developers the right tooling to identify issues with accessibility in their applications plus providing sound accessibility patterns and libraries.

Potential areas of development:

Tooling

• accessibility linting tools for cli-build-app
• accessibility testing tools for cli-test-intern

Patterns

• blockingElements
• inert
• focus management (for both widgets and elements)
• focus-ring focus-visible
• accessibility around menu's?
• review of existing widget patterns for a11y compliance
• review of dojo theme styles for a11y, with attention to the new WCAG rules

[smhigley]

Some thoughts on the items in the epic:

• Tooling/a11y testing: axe-core seems like the best choice for this, at least to me. It's free and open source unlike Tenon and, apart from Tenon, has the best ratio of hits/false positives, support, community, and track record of the automated testing tools out there.

• inert/blockingElements: Have a PR in the works. I think this belongs in our vdom implementation, since it makes sense to control via properties on VNodes.

• Menu: The basic issue is that people conflate programmatic menus with navigation menus. Although they serve different purposes and involve different user interaction, it seems that most frameworks have a single widget for both, and designers often create a single visual design pattern/style for both. Heydon Pickering explains it better and in more depth: https://inclusive-components.design/menus-menu-buttons/

• Reviewing existing widgets and styles: Although we built stuff with an eye to accessibility, multiple iterations and changing widget-core capabilities mean that some of it probably needs updating. Also I'm sure I missed stuff the first time through :)

• Focus management: Saved the best for last. The pattern in the hopefully soon-to-be-merged PR is essentially a hack, stretches the meaning of Meta, and breaks widget DOM encapsulation: this.meta(Focus).set('key', 'selector');. We need a long-term way to set focus on both VNode and widget children in a way that ideally doesn't involve creating an "I want to be focused" state (for various reasons, expanded on in the focus issue: Create meta for containing focus widget-core#729 (comment)). The basic issue is that setting focus really is entirely different from the other properties. Pretty much everything we've done in widgets thus far involves us dictating the DOM from our code, which is considered the source of truth. However, focus (and a couple other things like cursor position and text selection) are actually within the control of the user, and only briefly taken over by us before being ceded back to the user. This means that any attempt to control focus or keep an internal state that manages it is pretty dicey (and kinda reminds me of positive tab indices).