Manual ARIA injection vs. waiting for native navigation plugin support in Eleventy

Context

Eleventy's navigation plugin builds hierarchical menus from front‑matter but emits plain <ul>/<li> markup without ARIA landmarks. Teams targeting WCAG 2.1 AA must decide how to add role="navigation" and aria-label to every generated navigation block.

Trade‑off

Approach A: author a shortcode or filter that wraps the plugin's output in a <nav> element with the required attributes. This works today but duplicates wrapper logic across layouts and requires developers to remember the pattern on every new template.

Approach B: rely on the data cascade and eleventyComputed to inject ARIA attributes centrally. This reduces repetition but couples accessibility markup to the global data layer, making it harder to override for special cases (e.g., a footer nav that needs a different label).

Neither approach is officially blessed, and the plugin's roadmap has not committed to automatic ARIA injection. The decision affects every page template and the long‑term maintenance burden of accessibility compliance.

Open questions

1. Which approach scales better when the site grows to dozens of distinct navigation regions (header, sidebar, footer, breadcrumb)?
2. Is there a documented pattern for extending the navigation plugin's output without forking it?
3. What are the risks of adopting a custom wrapper if a future Eleventy release adds native ARIA support?