Changing widget rendering templates

[smi...@gmail.com]

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

[Carlton Gibson]

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

[Adam Johnson]

I think a breaking change for the widget HTML is fine too, if it improves everyone’s apps. Perhaps documenting in the release notes how to undo it (eg copy this template file into your project, reconfigure the widget to use the template like so) will make it easier for folks with incompatible CSS to upgrade.

--
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-develop...@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.

[Thibaud Colas]

Hi all,

I wanted to mention a couple more things that might help in the decision:

• There is no direct accessibility issue for end users from `as_p` that I know of. The only issue is its propensity to making people create forms with invalid HTML (see #31189), which is problematic when running HTML validation, and is a failure of WCAG 2.1 level A SC 4.1.1 Parsing (this standard being the most likely target for Django, although there is no official target as of now).
• I’ve just opened two tickets that, if confirmed, would require additional changes to the widgets’ rendering to fix: #32819, #32820.

I imagine we want to release changes to forms’ rendering as infrequently as possible. If we considered grouping those changes all in the same release, it could be worthwhile for me to further review forms and fields for any further issues there might be, so they can be fixed at the same time. One problem I’m facing with this and similar audits is that I almost never use Django’s default markup myself, so it would be nice for others to look at the form I’m using for testing (code, rendering) and confirm it’s suitable. Or provide alternative forms you might already be aware of, set up differently or showcasing more advanced widget configurations.

Those additional tickets reflect the extent of my audit progress to date. One thing I’m considering but am uncertain of is whether non-field errors would also need ARIA markup, to be more identifiable as errors, and-or programmatically associated with the form. I still need to research this, both according to specs, and with actual support from screen readers.

Kind regards,

Thibaud

[smi...@gmail.com]

Hi All,

Thanks for your repsonses and guidance.

I think for the widget changes we have far less flexibility than with forms where folk are already using various as_* functions. I'll therefore progress with the widget ticket as a breaking change. 

For the form changes I think it makes sense to make the existing as_* forms as accessible as we can. We can also intoduce a new template that is a "best practice" implementation. Making this the defualt while breaking wouldn't be too hard for folk to adjust as they would just use `as_table`.

Hopefully I've understood this correctly.

Thibaud -- just a few comments on your email. 

> widgets’ rendering to fix:

Looking at the ticket, I think these would require changes to the form render rather than the widget. Once we have the template rendering of forms PR merged, I think these will be easier to implement. 

>  Or provide alternative forms you might already be aware of,

The test project for crispy-forms has a django rendered page, this could be of help? https://github.com/django-crispy-forms/crispy-test-project 

> showcasing more advanced widget configurations

Looking at your page I think the couple of additional items which would be useful to get your views on would be:

- A grouped input (rendered with select, checkbox and radio widgets). I am not sure "grouped input" is the right terminology, I'm trying to expain the `MEDIA_CHOICES` example as shown here. https://docs.djangoproject.com/en/3.2/ref/models/fields/#django.db.models.Field.choices

- A multifield/multiwidget. `SplitDateTimeField` is a good example. Personally, I've found this one troublesome (https://forum.djangoproject.com/t/accessibility-for-splitdatetimefield/6871)

Kind Regards

David

[Tom Carrick]

I agree with everything said here so far.

I just want to add that I wonder if it is perhaps a good idea to deprecate and dedocument as_p and friends, but leave them in the code base for existing projects?

Tom

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0702b02a-019d-4a4d-8083-4ee9cf21bdb9n%40googlegroups.com.