You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need to clarify our policy for backports, largely based on that of Django, to make it clearer how we handle:
Accessibility fixes. Where there might not be a direct crash for all users or most users, but some users might be experiencing major issues equivalent preventing them to do certain tasks
UI fixes. Where here as well there might not be a crash or major issue, but certain small issues can have an outsize impact on the user experience.
In both cases we want more leeway than just looking at "critical problems".
Working on this
Assigning to myself as I have a specific idea of the kind of wording I’m after. But comments / feedback in this issue is very welcome.
The text was updated successfully, but these errors were encountered:
Do we want to provide a schedule of what accessibility tooling we support (alongside browser support)?
As for the backport policy, we could include a threshold that aligns with the WCAG framework? E.g. any A level item that is part of core admin functionality.
@lb- we do, it’s here: Accessibility targets :) Yeah I think that kind of threshold could work, though we probably need more flexibility than that. For example #8334 was a blocker for WHCM users, which lots of people argue isn’t part of WCAG.
Pertinent section of the Wagtail docs
Wagtail’s release process - Supported versions
Details
We need to clarify our policy for backports, largely based on that of Django, to make it clearer how we handle:
In both cases we want more leeway than just looking at "critical problems".
Working on this
Assigning to myself as I have a specific idea of the kind of wording I’m after. But comments / feedback in this issue is very welcome.
The text was updated successfully, but these errors were encountered: