Continue to implement ARIA APG Patterns for missing.js. The possibility of replacing the current 19.js "behavior" approach with custom elements (e.g. <aria-feed>, <aria-tablist>, <aria-menu>) has been brought up. I'm working on preliminary examples to allow us to compare the markup between behaviors and custom elements.
I believe the custom elements should be entirely framework / css agnostic, to allow them to be usable with other frameworks.
TBD: Require an opt-in class for ARIA components? If the author has some library that uses ARIA in the same page as Missing, Missing will apply its own styles, and might try to install its own behavior. Should we make styling and behavior for ARIA components opt-in by requiring a class and data attribute respectively to activate them? - Missing Roadmap
Continue to implement ARIA APG Patterns for missing.js. The possibility of replacing the current
19.js"behavior" approach with custom elements (e.g.<aria-feed>,<aria-tablist>,<aria-menu>) has been brought up. I'm working on preliminary examples to allow us to compare the markup between behaviors and custom elements.I believe the custom elements should be entirely framework / css agnostic, to allow them to be usable with other frameworks.