Re-write importance and meaning of ARIA widgets

[jmuheim]

As our guide was written with the deep impression that the usage of ARIA by the "default" web developer would do more harm than good, there are quite a few places where I stress out that ARIA is kind of ambivalent (if not precarious) to use.

In general, I would say that this is still the case today, but screen reader / browser combos have caught up quite a bit. So I'm re-writing/re-framing all these spots, claiming that usage of ARIA can be useful for certain widgets - if you really want to provide the "fanciest" accessibility possible.

Related to #128.

[netlify[bot]]

✔️ Deploy Preview for accessibility-developer-guide ready!

🔨 Explore the source changes: 45a0b144e22e3179466b515a70550a409b4ab42c

🔍 Inspect the deploy log: https://app.netlify.com/sites/accessibility-developer-guide/deploys/614b287b288aee00080849b9

😎 Browse the preview: https://deploy-preview-373--accessibility-developer-guide.netlify.app

[jmuheim]

@ralf57 I'm done so far with my work (re-writing the content, so that ARIA is not generally discouraged anymore from being used).

What I see is now left to do:

• Create our own ARIA implementation of a tablist
  • @ralf, please add the implementations that you found somewhere in this ticket
  • @AndreasUe, A4A needs to verify which of the proposed tablist implementations are accessible
  • We would then decide upon which example(s) we build our own implementation: I vote for a minimalistic implementation, which might not workaround some browser/SR bugs or which might not serve some edge cases, but that is aligned with our "keep it simple/stupid" approach, and which we can safely claim that it will keep working "untouched" in the future
    • I will then replace the "TODO" placeholder at https://deploy-preview-373--accessibility-developer-guide.netlify.app/examples/widgets/tablists/#poc-1-aria with it, whereas @ralf57 will provide the code

Another question is: what about other widgets? Should they also be updated to rely more thoroughly on ARIA?

• Carousels and accordions:
  • AFAIK, carousels and accordions are not listed in the ARIA spec (ie. there is no role="carousel"), and there's a discussion whether carousels and accordions should actually be implemented as tablists.
  • @AndreasUe, what's your opinion on this?
• Dropdowns:
  • AFAIK, dropdowns in the sense of "navigation menus" indeed are listed in the ARIA spec, but what about other kinds of dropdowns, ie. mega dropdowns?
  • And is there any clear advantage to use a complex ARIA implementation instead of simply relying on aria-expanded?
  • @AndreasUe, I would love to hear your opinion about this, too.
• Dialog:
  • It might be reasonable here to use either role="dialog" or even the <dialog> element; it might restrict keyboard focus to the element, and even prevent screen readers from leaving the dialog completely.
  • @AndreasUe, and experiences about this that you can share?
• Autocomplete:
  • Our "masterclass" widget! AFAIK there still isn't a specific role nowadays. Although we should investigate some modern implementations, ie. the one from https://www.swiss.com/ or https://lambda-it.github.io/digitalfactoryui_react/
  • In general, I'm still intrigued in the simplicity and beauty of our solution that uses radio buttons
• Datepicker:
  • Again an item that is not resembled in the ARIA spec
  • Maybe it would make sense though to place it inside a dialog (see above)?
  • Other than that, I'm pretty happy with our implementation.
  • @AndreasUe, what's your opinion here?

In general it might be worth stating somewhere that our widgets are not "one solution fits all use cases", they are merely inspirations on how to implement stuff. I write this because some weeks back a developer of an UI components library was kind of disappointed of the ADG's autocomplete, claiming that for example it wouldn't work as well on mobile as sophisticated "real world" implementations like https://lambda-it.github.io/digitalfactoryui_react/. Looking at the code of the latter I definitely appreciate the simplicity of the ADG implementation, while the sophistication of the latter definitely is stupendous. But it's two totally different solutions, and they can't be compared.