I could see updates to a component library iterating much more frequently that the core Phoenix project so I think an “official” library might introduce an unreasonable maintenance load on the core team and potentially slow down innovation.
I think the authors of the Petal Components library are moving pretty quickly so perhaps it will become the de-facto go-to library?
It’s my hope with HEEx and function components we’ll see more and more full-featured component libs (like petal), and that they will ship fully accessible components, so doing the right thing is the default for standard components. We know that developers won’t ship accessible features if it takes extra effort (unless they are forced), so a <.dropdown, <.modal, etc that just happens to be accessible out-of-the-box is the happy destination I hope we arrive at 
Yes, Kip and Chris explained what I meant much more eloquently than my use of quotes for “official standard” component library.
The petalframework crew is doing a fantastic job of cranking out updates and implementing user feedback.
There are too many component frameworks for the Phoenix core team to be too involved or manage, but adding to what Chris said maybe a checklist / test suite to ensure all the accessibility and best-practice requirements are met for a component library to be “blessed as official” is probably more what I meant. But that’s also what we are doing here as a kind of community review board.
I fiddled around a bit more yesterday with my Phoenix.Component → Stimulus → React idea. (I don’t know if this is the best place to share it, but in case anyone is going down the same path, here it goes):
components/form_component.ex:react/1 function component with controller (name of the Stimulus controller) and props (a map of props that will be provided to the React component): def multi_select(assigns) do
~H"""
<.react controller="multi-select" props={extra_attributes(assigns)}>
<%= Phoenix.HTML.Form.multiple_select(@form, @field, @options, class: "multi-select__select", data: [multi_select_target: "select"]) %>
<div data-multi-select-target="component"></div>
</.react>
"""
end
components/react_component.ex:defmodule MyAppWeb.ReactComponent do
use Phoenix.Component
import Phoenix.Naming, only: [camelize: 2]
@react_props %{class: :class_name}
def react(assigns) do
assigns = assigns |> assign(:data, controller: assigns.controller, "#{props_key(assigns)}": props_value(assigns))
~H"""
<div data={@data} class="react">
<%= if @inner_block do %><%= render_slot(@inner_block) %><% end %>
</div>
"""
end
defp props_key(assigns) do
"#{assigns.controller}-props-value"
end
defp props_value(assigns) do
assigns.props
|> Enum.map(fn {key, value} -> {Map.get(@react_props, key, key), value} end)
|> Enum.map(fn {key, value} -> {camelize(to_string(key), :lower), value} end)
|> Map.new()
|> Jason.encode!()
end
end
stimulus_controllers/multi_select_controller.jsximport { MultiSelect } from '@mantine/core';
export default class extends Controller {
static values = { props: Object };
static targets = ['select', 'component'];
connect() {
ReactDOM.render(
<MultiSelect ... data={this.options} onChange={this.handleChange} />,
this.componentTarget
);
}
disconnect() {
ReactDOM.unmountComponentAtNode(this.componentTarget);
}
handleChange = (values) => { ... };
get options() { ... }
// ... more stuff here ...
}
And it looks like this:
This is just 1 approach to implement such a more advanced component. At the end of the day it’s nice to have a function component (<.multi_select ... />) that you can call without worrying (too much) about it’s implementation. It happens to be fully accessible also.
Only thing I’m not happy with is that it is stil bringing in quite a bit of javascript and I have to make sure the integration works well enough 
For example supporting grouped select options will be a bit more code. I have also not tested it in a morphdom setting (just single render for now).
I can also see the appeal of implementing such components via LiveView / LiveView.JS or Alpine.js. It will obviously result in more code when building it from the ground up but it won’t have a dependency on React/Node/etc.
While this sounds nice at least accessibility is not as simple as a checklist to deal with. There‘s not s „correct“ way of doing it. Even the official aria docs afaik are full of examples, but not prescriptions or how tos. There‘s a lot more gray in that topic than black and white.
But there can be “good defaults” right ? Never had to deal with accessibility myself until now. So, I don’t understand how ‘difficult’ is it define ‘sane defaults’.
There are for sure some generalizable rules, mostly on the smaller scale, but there’s no “this is how you make your calendar component accessible”.
