4 ms·

Yep I totally agree with this. There are however a bunch of ARIA tags & best practices etc (https://w3c.github.io/aria-practices/ https://w3c.github.io/aria-pr

Yep I totally agree with this. There are however a bunch of ARIA tags & best practices etc (https://w3c.github.io/aria-practices/ https://w3c.github.io/aria-practices/) that exist to make popups and dialogs (and other things e.g. tree views or "email-inbox-style" "treegrids" etc) accessible (if implemented correctly). I am conflicted about these - it is nice that there are ARIA tags for this, but it would also be nice if browsers "understood" aria tags and added some default behaviors (e.g. keyboard navigation). As it is, ARIA tags are essentially "pointless" to anyone who doesn't use an assistive technology, and so non-assitive-technology users nor developers benefit from using ARIA tags so they are often forgotten. If the browsers saw that there was an A11y-tree that matched a treeview or a treegrid, it would be really really nice if they applied some default common keyboard navigation implementation, rather than do nothing and leave it up to the developer to decide what keys do what on each and every site. .... Or on the other hand, is that too prescriptive and should we give developers and UX designers more leeway to design something better, rather than rely on browser-enforced defaults? I guess we are happy with browser defaults for basic inputs, but would we be for a treegrid?

extra88 5y ago
The WAI-ARIA Authoring Practices are not best practices, they are not carefully researched to ensure they can be successfully used in a variety of browsers or with a variety of assistive technologies. They include examples that don't work properly with common browser/screen reader combinations (like Safari + VoiceOver). They'll use ARIA approaches even when they're not the only or best way to achieve a goal. They're best thought of as patterns designed to "exercise" a browser's support for ARIA attributes, browser developers can use them to test whether their implementation of ARIA support matches expectations. Nevertheless, some of them are perfectly good solutions as-is and can serve as a good starting point. I would also like browsers to have more capabilities "baked in;" browsers should offer keyboard navigation of ARIA landmarks (both implicit ones created by <header>, <main>, <footer>, etc. and explicit `role` attributes). I don't like the idea of browsers automatically creating interactive controls based on the presence of ARIA attributes, I'd rather there be new HTML elements, ones that document stylability much better than old ones did. I'm interested in Open UI's [0] work, attempting to develop common web components, ones that can be useful in the short term and may serve as the basis for new HTML elements in the future. They're sort of documenting cow paths that HTML in the future can pave, similar to HTML5 elements being named based on common class names or useful additions to JavaScript having been based on features in libraries like jQuery (obviously without adopting jQuery's syntax). [0] https://open-ui.org/ https://open-ui.org/
- bmn__ 5y ago
  > I would also like browsers to have more capabilities "baked in;" browsers should offer keyboard navigation of ARIA landmarks (both implicit ones created by <header>, <main>, <footer>, etc. and explicit `role` attributes). Opera 12 does that. It predates ARIA, so it navigates based on the elements available at that time. Default keys (Tools → Preferences → Advanced → Shortcuts → Keyboard setup → Edit… → Input context and shortcuts → Document Window): • a : Highlight next URL • q : Highlight previous URL • s : Highlight next heading • w : Highlight previous heading • d : Highlight next element • e : Highlight previous element I can mash the keys like crazy to get where I want. The browser is super responsive, keyboard navigation is a joy to use. The browser also offers spatial navigation (Shift + arrow keys), this navigates interactables not by their functionality, but by their apparent position to each other.
- rhdunn 5y ago
  The open-ui is only potentially good when you need something that resembles the standard controls and interactions. At the moment it only has a few controls specified and if you need anything not covered by those you are going to end up creating your own UI -- e.g. using a treeview dropdown instead of a listbox, or if you have a form with multiple checkboxes and need that group of checkboxes to be a role=select from an ARIA perspective in order to place form error messages on that group so that screen readers read the error set on the ARIA description, but still display as a list of checkboxes to the user. When you have custom UI, then you need to mark that up in a way that is accessible and implement things like keyboard navigation properly. No matter how many standardized UI elements you create there will always be cases where you need to use ARIA markup and not just for styling/theming, but for accessibility as well like in my form error example above. The ARIA authoring practices is the best thing I know of that does that, along with other resources like www.a11ymatters.com for patterns like pagination. If you are saying that the authoring practices isn't good enough, then what we need is a battle tested guide on how to implement all of the UI patterns (disclosure, dialog, select, etc.) that works on all screen reader/browser combinations and documents all current features (ARIA, keyboard, dark mode, reduced motion, styling/theming, etc.). It should also include notes on what issues and resolutions to look out for, and details on what users of assistive technologies are looking for (e.g. when and what content should be read out). You can (and should) have a set of common components that implement these patterns in a way that can easily be styled to handle 80% of the use cases. But there should also be a way to support the other 20% of use cases -- which is what ARIA was designed for.

extra88 5y ago

The WAI-ARIA Authoring Practices are not best practices, they are not carefully researched to ensure they can be successfully used in a variety of browsers or with a variety of assistive technologies. They include examples that don't work properly with common browser/screen reader combinations (like Safari + VoiceOver). They'll use ARIA approaches even when they're not the only or best way to achieve a goal. They're best thought of as patterns designed to "exercise" a browser's support for ARIA attributes, browser developers can use them to test whether their implementation of ARIA support matches expectations. Nevertheless, some of them are perfectly good solutions as-is and can serve as a good starting point. I would also like browsers to have more capabilities "baked in;" browsers should offer keyboard navigation of ARIA landmarks (both implicit ones created by <header>, <main>, <footer>, etc. and explicit `role` attributes). I don't like the idea of browsers automatically creating interactive controls based on the presence of ARIA attributes, I'd rather there be new HTML elements, ones that document stylability much better than old ones did. I'm interested in Open UI's [0] work, attempting to develop common web components, ones that can be useful in the short term and may serve as the basis for new HTML elements in the future. They're sort of documenting cow paths that HTML in the future can pave, similar to HTML5 elements being named based on common class names or useful additions to JavaScript having been based on features in libraries like jQuery (obviously without adopting jQuery's syntax). [0] https://open-ui.org/ https://open-ui.org/

bmn__ 5y ago
> I would also like browsers to have more capabilities "baked in;" browsers should offer keyboard navigation of ARIA landmarks (both implicit ones created by <header>, <main>, <footer>, etc. and explicit `role` attributes). Opera 12 does that. It predates ARIA, so it navigates based on the elements available at that time. Default keys (Tools → Preferences → Advanced → Shortcuts → Keyboard setup → Edit… → Input context and shortcuts → Document Window): • a : Highlight next URL • q : Highlight previous URL • s : Highlight next heading • w : Highlight previous heading • d : Highlight next element • e : Highlight previous element I can mash the keys like crazy to get where I want. The browser is super responsive, keyboard navigation is a joy to use. The browser also offers spatial navigation (Shift + arrow keys), this navigates interactables not by their functionality, but by their apparent position to each other.
rhdunn 5y ago
The open-ui is only potentially good when you need something that resembles the standard controls and interactions. At the moment it only has a few controls specified and if you need anything not covered by those you are going to end up creating your own UI -- e.g. using a treeview dropdown instead of a listbox, or if you have a form with multiple checkboxes and need that group of checkboxes to be a role=select from an ARIA perspective in order to place form error messages on that group so that screen readers read the error set on the ARIA description, but still display as a list of checkboxes to the user. When you have custom UI, then you need to mark that up in a way that is accessible and implement things like keyboard navigation properly. No matter how many standardized UI elements you create there will always be cases where you need to use ARIA markup and not just for styling/theming, but for accessibility as well like in my form error example above. The ARIA authoring practices is the best thing I know of that does that, along with other resources like www.a11ymatters.com for patterns like pagination. If you are saying that the authoring practices isn't good enough, then what we need is a battle tested guide on how to implement all of the UI patterns (disclosure, dialog, select, etc.) that works on all screen reader/browser combinations and documents all current features (ARIA, keyboard, dark mode, reduced motion, styling/theming, etc.). It should also include notes on what issues and resolutions to look out for, and details on what users of assistive technologies are looking for (e.g. when and what content should be read out). You can (and should) have a set of common components that implement these patterns in a way that can easily be styled to handle 80% of the use cases. But there should also be a way to support the other 20% of use cases -- which is what ARIA was designed for.