emilk
Consider enabling AccessKit by default in the base egui crate
It seems that by giving into the request to disable AccessKit by default in the base egui crate, I have set a confusing precedent, as we can see in this comment. If there are practical reasons to continue to disable AccessKit by default in the base egui crate, I will do what I can to address those. But my position is now that accessibility should be the default at all layers of the stack, and it should be something that developers have to work to disable.
On one hand
Turning on the accesskit feature on egui has no effect without the egui integration having support for it. For instance, if you are using egui-miniquad you can turn on accesskit on egui and get nothing out of it. We should promote egui integrations to enable accesskit, and then they can in turn on the accesskit feature of egui, just like eframe does.
On the other hand
accesskit is today a commendably light-weight dependency, with no default dependencies. That's not how it started out, which is why I insisted on having it opt-in. So great job on that!
If accesskit can commit to keeping its compilation time and dependency tree to a minimum (and not introduce a build.rs etc) we could even remove all #[cfg(feature = "accesskit")] in the egui crate. It would make the egui code cleaner and haver produce fewer permutations of features to test on CI. But let's not get ahead of ourselves.
I've also ran the benchmarks again - enabling accesskit has no noticeable performance penalty that I can notice.
Conclusion
Why not, let's do it!
