-
Notifications
You must be signed in to change notification settings - Fork 32
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
RFC: Contextual alt text #51
Conversation
For this, and #66, how do you feel about making it easier to use non-streamblocks in streamfields? For example we could use these blocks as regular database fields by wrapping them with class MyPage(Page):
image = StreamField(ImageChooserBlock())
link = StreamField(LinkBlock()) Both would store the data in JSON though. But would have the same UI as the streamfield version Crazy idea, maybe we could somehow allow people to use struct blocks on page models and these get converted into database fields? so: class MyPage(Page):
image = ImageChooserBlock() Expands the structblock into actual fields like so: class MyPage(Page):
image_image = models.ForeignKey()
image_alt = models.CharField()
image = an accessor that gets/sets these fields with a struct value |
Thanks for putting this RFC together Matt! Contextual alt text is a great step in the right direction for accessibility 👍 From the discussion in wagtail/wagtail#6034, I understand that a dedicated alt text field is often added using a custom image model. You've explained why we don't have this field in core Wagtail and why contextual alt text is preferred pretty well in your comment.
With the Decorative images Auto-populating contextual alt Naming conventions Alternatively (not sure how feasible it is), would it be possible to keep the Keen to hear what others think! |
The rationale for calling it ImageChooserBlock with a keyword argument (defaulting to alt text enabled) would solve that, but I don't think it adequately communicates that I expect that once we introduce ImageBlock, we'll downplay the existence of ImageChooserBlock in the documentation so that only 'advanced' developers will need to understand the distinction. |
Have to say that we are very excited for an I think As for:
Personally I'd think that any developer who knew about marking images as decorative would also be aware that an empty alt-text would suffice. I'd imagine leaving the field empty would be the default when using this block, but then-again, maybe being explicit would help folks stay more accessible. Any idea how long this will take to be supported? |
A few of the @wagtail/accessibility team, along with others, met to discuss this last week with the hope of reviving this thread and nudging us closer towards improving this in Wagtail. We discussed a few options:
We concluded that option three provides the most flexibility and is a sensible foundation to add to Wagtail, though we'd like more opinions on this before committing to the approach. In particular, we'd love to investigate this suggestion from @kaedroho about reducing the burden on developers when using images within models. Currently a developer only has to add one field (a FK to the
...is a significant change that will likely be inconsisntely implemented. We'd like a more reliable/robust way of doing this - e.g. adding a single field as per @kaedroho's suggestion. Thoughts? |
I think it's possible in Django to construct field types that appear as a single field in the model definition but translate to multiple fields at the database level, but that would need more research. (I thought GenericForeignKey did this, but apparently not...). I'd definitely prefer that to a JSON / StreamField representation, both for the added referential integrity of having a proper FK, and for avoiding a Wagtail-specific solution that departs from the 'natural' DB representation. |
Hi all, Thanks for adding alt texts in Wagtail! In our case, we are dealing with a lot of (inexperienced) web editors. An image library with just one alt text per image (insensitive of context) would be entirely appropriate and suffice. It is the same approach WordPress uses. So option 1 would already be enough. Thanks! Wim |
@wimfeijen Hi Wim, isn’t this something that’s already possible? It feels to me like you could just add the field to a custom image model. From our perspective this isn’t good enough, and we wouldn’t recommend this option for any site. Without knowing in what context an image is used in, it’s hard for editors to judge whether the alt text is appropriate or not. Without any way to explicitly mark an image as decorative, it’s even harder for inexperienced web editors to make the judgement call to leave an optional alt text field empty. |
Hi all, I'd like to report that there is renewed interest in this RFC from the accessibility team. See the accessibility team meeting notes from the 22nd of December, 2023. I'm still catching up on everything that has been said on this RFC and in other issues over the past years. It is my intention to revive this RFC and make a more accessible default image model happen in 2024. (cc'ing @SaptakS as he has expressed interest in helping out) |
There is now a working group working on this. Come find us in the #a11y-image-model-working-group channel on Slack! |
Based on our recent ATAG audit, here are ATAG requirements pertaining to alt text.
Additionally – per ATAG, all of this needs to be documented, either in docs or in the CMS. And I’d also recommend looking at the results of the We4Author Cluster project for text alternatives. Based on all of this, my "ideal scenario" if I could redesign this all from scratch would be:
|
Hi @thibaudcolas, Thanks for looking into this! Your ideal scenario sounds very nice.
Best regards, |
@wimfeijen in my mind, in this ideal world where there is a separate mandatory alt text field, pre-filling from the title doesn’t sound right – as title itself is pre-filled from the file name on upload. The point of having a separate field be mandatory is so people make some effort to write it right. Or if they don’t want to – they can copy-paste the contents of the title field themselves. And yes, setting in context would be optional. I’d assume we could default the alt text field to use what has been defined centrally, and provide help text to explain that "Set a different alt text to better describe the image in context", and a separate "mark image as decorative" checkbox. |
Link to meeting notes from our accessible image model working group. |
As per the discussions for the GSoC '24 project on |
Closing in favour of #97. We could use more feedback there if anyone who’s read this RFC has the chance to take a look :) |
Wagtail's default image model does not currently provide an alt text field - the title is used instead. Wagtail could add a dedicated alt text field (and developers often do so on custom image models); however, ideally alt text should be tailored to the context where the image is being used - for example, a gallery implemented with an InlinePanel would make the alt text a property of the GalleryItem model - and adding a field at the image level would interfere with this 'ideal' approach. Unfortunately, since both approaches require up-front effort on the part of the developer, it's common for neither one to be implemented. We therefore seek a solution for context-aware alt text that is as frictionless as possible for both developers and editors. This RFC proposes a solution for this within StreamField image blocks.