-
Notifications
You must be signed in to change notification settings - Fork 844
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DISCUSS] A11y work and breaking changes friction #2784
Comments
I'm all for on changing some of these attributes that we mark as "optional but very recommended for accessibility" to "breaking change: you're required to pass this in now." The tricky point here will be to get the cadence right. I tend to err on the side of "ship small breaking changes often" which would be to ship every individual PR as a breaking change just whenever they land. I think many small upgrades is less painful than fewer large upgrades. If Kibana+EUI would rather strike some middle ground at every six months, that's fine by me too. All that is to say, I'm very in favor of shipping these as breaking changes. I slightly prefer a faster cadence but will happily defer to any cadence. Getting area leads around Kibana to weigh in might be helpful? |
We should also canonicalize what we want to do in new instances: are defaults okay (always? sometimes?), or are they required input from now on. |
👋 Hey there. This issue hasn't had any activity for 180 days. We'll automatically close it if that trend continues for another week. If you feel this issue is still valid and needs attention please let us know with a comment. |
❌ We're automatically closing this issue due to lack of activity. Please comment if you feel this was done in error. |
@myasonik and I have gone back and forth a bit about how a11y changes often force breaking changes because they require such precision. On one side upgrades are no fun and cause friction to people using the library, on the other hand, making our a11y work need context in development (because the defaults are lame) results in things technically passing, but not being optimal.
I think a compromise idea would be to continue letting individual PRs with these cases still default to easy-upgrade, but then collect them (in our deprecations list #1469) so they can be acted upon once every six months in a formal one and done release push. This would give these sorts of breaks a non-constant upgrade requirement, but still force change occasionally over time.
If this works for folks, I can collect the last couple PRs we've let go this route and add them to our deprecations list.
This came up as part of #2782 (comment)
The text was updated successfully, but these errors were encountered: