Skip to content
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

Closed
snide opened this issue Jan 22, 2020 · 4 comments
Closed

[DISCUSS] A11y work and breaking changes friction #2784

snide opened this issue Jan 22, 2020 · 4 comments

Comments

@snide
Copy link
Contributor

snide commented Jan 22, 2020

@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)

@myasonik
Copy link
Contributor

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?

@chandlerprall
Copy link
Contributor

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.

@snide snide mentioned this issue Mar 9, 2021
41 tasks
@github-actions
Copy link

👋 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.

@github-actions
Copy link

❌ We're automatically closing this issue due to lack of activity. Please comment if you feel this was done in error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants