Hi David.
Thanks for this. Sorry for the slow pick-up: DjangoCon this week. :)
I'd say option 1: It's an accessibility change and we should just opt
people into that. IIRC there are some small improvements to the current
HTML (aria roles and such) that would improve accessibility even if not
perfectly. We should add those. (Folks can revert to the old templates if
they must, assuming we note the changes.)
With the template based rendering in place, I'd think (though) we could
eventually move away from `as_p` &co.
Rather you'd set the (base) `template_name` for the form, or override
`django/forms/default.html`, which in the PR proxies to `table.html` to
maintain the current behaviour, and then rely on `__str__()`, i.e. you'd do
`{{ form }}`.
If we keep `table.html`, `ul.html` and `p.html`, folks who are using `{{
form }}` now can add the `as_*` as needed to keep the current output
(modulo the aria type changes).
We should then be free to introduce a better `default.html` that addresses
the accessibility issues more comprehensively. I think there's no problem
heading towards this.
I think we do have to leave that fallback though: I'd guess the number of
projects using `as_p` &co somewhere is legion; just changing the HTML would
be a pretty big break without a fallback... 🤔 Whether it's worth the
disruption to formally deprecate and remove these methods I don't know...
We could add a warning to as_p &co to say "This method
has accessibility issues" if we wanted to steer people away — There's
probably value if having two or three different examples of how you could
render a form, especially if we can solve the worst of the accessibility
concerns.
Kind Regards,
Carlton
On Friday, 4 June 2021 at 08:56:12 UTC+2 smi...@gmail.com wrote:
> Hey all,
>
> I've been looking at the couple of tickets open to improve accessibility
> of the forms and checkbox/radio widgets. [1][2]
>
> While changing the layout is _fairly_ straight forward I'm unsure how to
> transition to the new way. I'm focusing this change in changing the widget
> templates until the patch for template based rendering of forms is merged.
>
> I think the options are:
>
> 1) Just make the change and have a breaking change. 😬
>
> 2) Introduce the new template and deprecate use of the old template. This
> is really horrid as _everyone_ will have to add boiler plate template over
> rides to point at the new template. We'd then probably want to change the
> name again at the end of the depreciation period.
>
> 3) Change the default template and package the old template, folk can then
> over ride their template if they still want the old behaviour. We can then
> deprecate the old template, and folk can include it their selves if they
> want it longer term. While a breaking change there would be a _simple_
> solution.
>
> I hope this is enough to get your creative juices going! I'm hoping there
> is a better way than what I can think of.
>
> My gut reaction would be to go for option 3. We don't have any data on
> how well used the default templates are used, I'm guessing it's not used
> that much...
>
> Appreciate your thoughts.
>
> Kind Regards
>
> David
>
>
> [1]https://code.djangoproject.com/ticket/32338
> [2]https://code.djangoproject.com/ticket/32339
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/65637a91-d3b9-4031-aa3c-b737017fdd70n%40googlegroups.com.
