Make the default 'alt' attribute for Image fields required

Coming from #2297681: Make the "alt" attribute required in EditorImageDialog - I do think that this would make the interface more consistent and also make Drupal be more ATAG 2.0 compliant.

If I read right, just make the checkbox checked by default when the alt option is added. That is a fairly simple change that I'm uploading. I have a couple questions though. For one, should the Article content type be changed to have the alt be required on its default Image field? That will have to be changed in the installation profile. It is another simple change, but I don't know if that goes too far.

Also, this patch won't pass the ImageFieldDisplayTest. I'm not sure why. It looks like the code supplies an alt, but the node form is being completed without it, which causes the submission to fail. If I modify testImageFieldSettings()'s settings to not make the alt field required, I can make it pass, but that doesn't seem like the right approach.

I noticed something else. On the node add/edit form, the alt text field (nor the title field) does not render with the "form-required" class, which gives it the red asterisk. This is bad UX, as the user does not know the field is required until after submitting.

I can't quite figure out where to fix it. The only part I see related to the form is the process function in ImageWidget, but manipulating the requirement there breaks the file upload. It ends up including the requirement as part of the upload process.

Would be useful to have a solution that worked like proposed in #2297681-44: Make the "alt" attribute required in EditorImageDialog

Clearly users should be warned that this is an issue and that they need to consider alt text. Alternative text could be presented within the context or surroundings of the image itself (although this is less common). Also, the image may be entirely stylistic (conveying no information) or is redundant then it is also alright to include a null alt attribute.

I do think it would be great if we could produce something with a workflow like suggested by @anandps. Or as @AndrewEchidna suggested, perhaps a checkbox to insist you want blank alt text vs omitting alt attribute.

How would this be configured? The image field admin form would have three checkboxes? Add alt + Require alt + Let editors override ?

On the node form we would then need a checkbox below the alt field that says, "don't include alt text". I could see this possibly working with the wysiwyg because there are triggers, but the node form would require submission. It sounds needlessly complex.

I think we could follow suggestions from #2297681: Make the "alt" attribute required in EditorImageDialog.

Make alt tags mandatory (for a simpler UI).

Adding something like what @AndrewEchidna suggested would work nicely I think. Could just 'provide a checkbox interface in cases where the editor makes a conscious decision to omit alt text - which I believe should be a rare occurrence. Checking the "Omit Alt Text" checkbox would be the editors was of specifying a null alt text be used in the markup.

This requires the editor make one extra click in the rare case that alt text is not required. Checking the box would disable the alt text input.

Utilizing this checkbox would output the null format alt="".'

I think that could work fine.

related issue tied to #3.

There is a small patch in #2 to start from, but it has known problems with ImageFieldDisplayTest.

There's also an element of how to make it mostly required, vs totally required.

A use case for this is #2307647-29: [Follow-up] Allow manual override of required image alt text in the Text Editor image dialog when appropriate - although I'm not actually sure that there's a use case for this field type.....

It might only be needed in a WYSIWYG where there is that level of personalization... Not sure.

I also don't think there's a valid use case for "empty alt attribute" in the case of image fields, because they can never appear inline with text.

Ok, let's mark it closed for now.

#13: You're right, I think mgifford closed this, thinking that this was solely about supporting the "empty image alt attribute" use case, but it's not: as you indicate, this is actually mainly about requiring alternative text in the first place :)

Thanks for clarifying the title! I'm clarifying it further, ever so slightly.

Didn't we have this discussion like 20 times already, and we decided not to require this? We should probably look at some older discussions, before rehashing it again.

Thanks again Charles. August has been pretty busy. I've certainly been thinking about this issue though and how to address it.

@Wim Leers' right in that I was thinking just about the "empty image alt attribute" issue. For that yes, there's no need to create a condition where we create a space for the empty alt attribute.

We were also talking about adding a UI element to CKEditor when we were discussing this previously. In this case the ability to enable/disable alt text is all right there.

As @Charles Belov points out though, what is the default. Do we force folks to go through and enable alt text & required alt text every time they add an image field or not.

Obviously we want it to be as simple as possible for folks to produce accessible content with Drupal. The accessible option should be the default.

This new patch both enables alt text & required alt text for new image fields. It also adds this default to the Article content type's image field. This sets a good example moving forward, but it is easy to override if an administer deems it too restrictive for a particular content type.

Forgot to engage the bot.

Code wise these changes appear very straightforward. No obvious typos I can see.

I did a manual test with simplytest.me and grabbed some screenshots.

On basic page, I used the ckeditor image upload button within the wysiwyg body field.

On article I used the image field.

The image field doesn't visually indicate that the alt txt is required,

But it certainly did not let me save until I had entered it.

I really like the notice to add "" to include empty alt text in the ckeditor, I hadn't seen that before.

Then something strange happened when I saved the article, and I got this.

I'm marking as needs work, for the missing "required" indicator - and will test again for the weirdness. Although I suspect that's a different issue that should go into the wysiwygish queue.

Added the existing image field to the basic page.

This screen grab shows that enable alt field, and alt field required options are selected.

The problem with the missing * is being worked on here #1906264: Required alt tag missing on image alt tag input

It's an existing problem with the Core. The CKEditor changes are in Core too I think.

Thanks for the testing the patch & providing screenshots of the patch.

Gotcha!

The patch itself is still failing testing - what's up with that? If we can get a green test - then I'd set this small change to RTBC.

I'm a bit baffled at how switching around alt values from false to true could case these breaks in the tests..

+      'alt_field' => 1,
+      'alt_field_required' => 1,

+ alt_field_required: true

I assume the tests themselves just have some poor assumptions.

That looks like a pretty serious error:

The test did not complete due to a fatal error.

Not sure why this is popping up either...

array_flip(): Can only flip STRING and INTEGER values!array_flip(Array)

Let's see if we can get someone to help with the tests?

Ill tackle these tests tomorrow during the pnx-sprint.

Thanks @nick_schuch - that would be awesome!

The fail is because the change is doing what it should - preventing nodes being saved that have images without alt tags :)

This still fails for me locally but I've got some existing file permissions issues on tests that do uploaded files.

So it might fair better here.

Found the following bug which might be related.

1. Create a basic page
2. Upload an image in ckeditor into the body field
3. Don't set any alt text. You get a warning that it is a required field
4. Now fill in some alt text and save
5. you will be navigated to /editor/dialog/image/basic_htmleditor/dialog/image/basic_html instead of the edit view of the node

The image is not being saved as in contrary to #23

I applied the patch #37 but the bug remains.

I verified that this is happening, but it should be identified as a problem with #2297681: Make the "alt" attribute required in EditorImageDialog

Probably it should be a new issue that is simply linked to that one as a [FOLLOW-UP] issue.

If you want to point others too it, for a few hours more there will be an environment up on SimplyTest.me to test.

Created new issue for #40 #2347175: Omitting required alt text in ckeditor image upload first time causes wrong redirection after saving

hmm where did this get to?

I think we need to update the issue to make it really clear this is about image field (not ckeditor wysiwyg), and setting the default to requiring alt text to improve overall default accessibility. It is possible to admins to turn it off, but we are setting the default to on, and helping users explicitly add empty alt tags.

I'll have a go at that now.

I've done another round of testing. Am now confident the associated issues are related to other things.

Let's go it! A big win for accessibility.

RTBC

No green patches - how can this be rtbc?

Alex - in #37 larowlan says the test fails because the patch does what it says it should - prevent the node from being saved if there's no alt tag.

The fail is because the change is doing what it should - preventing nodes being saved that have images without alt tags :)

Maybe there needs to be a different reverse test?

No I meant, the test needs to be fixed - ie you have to also send the alt tag

Ok, so the tests need to be altered so we have a green patch. Just tagging.

Thanks for the work on this @kattekrab & @larowlan!

Just getting that patch to apply again. It was 5 months old.

+++ b/core/modules/image/src/Tests/ImageFieldTestBase.php
@@ -136,6 +136,10 @@ function uploadNodeImage($image, $field_name, $type) {
+      $field_name . '[0][alt]' => $this->randomMachineName(),

I played with this some to get the tests to pass. I think actual text will need to be used here, instead of randomMachineName, so it can be identified in the other tests. Unless there is a way to grab it. That will fix ResponsiveImageFieldDisplayTest and probably most of ImageFieldDisplayTest.

ImageFieldValidateTest is failing because there is a test to check if alt was not entered if the field was set to required. uploadNodeImage now has to add alt text, so some re-arranging would be needed to make the empty but required alt. It seems this test lacks purpose now since the other tests have to add alt text to a required alt text field. Remove the alt portion?

The big problem is cannot get TaxonomyImageTest to work. I know what is wrong. It needs to add alt text to the image that is added as part of the term. I'm trying to get it to post the alt text in testTaxonomyImageAccess, just like uploadNodeImage does, but I cannot get it to work. Can anyone fix that?

I think I sorted out most of the tests, but I'm working out different scenarios. I'll upload a patch this weekend. If not, I'll un-assign myself, or someone feel free to do it for me.

I reworked uploadNodeImage() to accept alt text optionally, because there are instances where I think the alt interferes. For example, the image resize test, places where preview is used, and testRequiredAttributes() where the alt and title text are tested.

Functionally tested, everything works as expected now, awesome! Overall code looks good, one small question:

+++ b/core/modules/image/src/Tests/ImageFieldDisplayTest.php
@@ -280,9 +297,12 @@ function testImageFieldSettings() {
-    $edit = array();
-    $edit['files[' . $field_name . '_1][]'] = drupal_realpath($test_image->uri);
+    $edit = array(
+      'files[' . $field_name . '_1][]' => drupal_realpath($test_image->uri),
+    );

What does this change have to do with the issue?

Also it may be considered out of scope but since we're messing with the alt field, I noticed in testing that the description here doesn't end in a full stop, so this may be worth adding to the patch:

+++ b/core/modules/image/src/Plugin/Field/FieldType/ImageItem.php
@@ -262,7 +262,7 @@ public function fieldSettingsForm(array $form, FormStateInterface $form_state) {
       '#type' => 'checkbox',
       '#title' => t('Enable <em>Alt</em> field'),
       '#default_value' => $settings['alt_field'],
-      '#description' => t('The alt attribute may be used by search engines, screen readers, and when the image cannot be loaded. Enabling this field is recommended'),
+      '#description' => t('The alt attribute may be used by search engines, screen readers, and when the image cannot be loaded. Enabling this field is recommended.'),
       '#weight' => 9,

That change does not have anything to do with this issue. Both array syntaxes are valid. I probably changed that one as I was rewriting the tests since it is the same format as the other $edit arrays that came before it.

I fixed the description text.

I changed the array that follows the one I changed above, that mrjmd mentioned. Both ways are valid syntax, but this should at least make all the arrays in the file consistent.

Looks good to me.

And just did a manual test using simplytest.me too.

I think this is the sensible default as it will increase WCAG compliance for new sites. For anyone who doesn't want this, it's easy enough to turn them off.

Thanks for sorting out the tests David - I'm so pleased to see this get to RTBC!

So RTBC++ from me too.

Updated issue summary - No remaining tasks, added "after" screenshot and git credit message thingie

+++ b/core/modules/image/src/Tests/ImageFieldDisplayTest.php
@@ -48,7 +48,8 @@ function testImageFieldFormattersPrivate() {
+    $field_settings = array('alt_field_required' => 0);
+    $instance = $this->createImageField($field_name, 'article', array('uri_scheme' => $scheme), $field_settings);

@@ -77,8 +78,16 @@ function _testImageFieldFormatters($scheme) {
+    // After previewing, make the alt field required. It cannot be required
+    // during preview because the form validation will fail.
+    $instance->settings['alt_field_required'] = 1;
+    $instance->save();

+++ b/core/modules/responsive_image/src/Tests/ResponsiveImageFieldDisplayTest.php
@@ -365,7 +372,8 @@ public function testResponsiveImageFieldFormattersEmptyMediaQuery() {
+    $field_settings = array('alt_field_required' => 0);
+    $this->createImageField($field_name, 'article', array('uri_scheme' => 'public'), $field_settings);

Why not just add the random text for the alt field in previewNodeImage?

The alt being supplied doesn't get used, because the image has to be added first and then the alt. With preview that doesn't happen. The form is essentially submitted in one step, so requiring the alt makes it fail.

@alexpott - is there a way to work through this? Are there other patterns like this with preview that could be used?

If there isn't a workaround, can we just bump it back to RTBC?

Moving back to RTBC.

Can we get this primary accessibility feature through and perfect the details later?

Let's not let perfect be the enemy of the good. This is a really important change for making the baseline for Drupal sites more accessible. It addresses a systematic imbalance meaning that by default, images don't include ALT text, and in the majority of cases ALT text is mandatory. It is possible for site administrators to turn this off for the minority of use cases that don't require it.

I'm not 100% clear on the technical details discussed by David and Alex here, but it seems to me it could be resolved in a follow up? If that's not the case, what else do we need to do to drive this forward?

Looking at this again I think the behaviour around previewing is fine. If you disable javascript and create an article node and select a file but don't click the upload button before clicking preview you get a required field error on the alt text. This is exactly what would happen if you pressed node save and you can't preview before all required fields are completed. However whilst testing this thoroughly I discovered an unrelated issue #2457239: File upload no longer works after previewing a node.

Committed d87af02 and pushed to 8.0.x. Thanks!

Thanks adding the beta evaluation to the issue summary.

Needs change record.

working on it.

Draft change record here for review
https://www.drupal.org/node/2461557

Rather than "Alternative text for images is a requirement of the Web Content Accessibility Guidelines [WCAG2]."

Might be better to put in something like "Most images placed in content require will alternative text for images in order to meet the Web Content Accessibility Guidelines [WCAG2]."

In general it's better if users who don't know what they are doing are prompted to put in alt text. There are times where it is more appropriate not to have alt text (duplicate images, decorative images).

This was committed eight days ago, so let's just get it posted. We don't want the change getting away from us. I added Mike's text and published the change record.

I believe there is an issue with this. When the image field itself is not required, I'm getting a validation error when the alt attribute is not filled in, even if no image is uploaded.

@PLPeeters I could not reproduce the regression. Could you post the steps to reproduce what you have seen?

I have been wondering if the core image field should mimic the behaviour you see when adding an image via ckeditor.

In that the user is prompted to add "" to explicitly make an alt field empty. Should be a new ticket though.

Keen to hear thoughts on that.

A real-world a11y problem I've encountered recently should be common - so I'm surprised not to have found an elegant solution - and would still be greatful to hear ideas...

Many images in image fields, as opposed to those uploaded via wysiwyg - are used in multiple locations. Commonly this becomes a thumbnail, which is then linked through to the node it originated from.

When that image becomes a link - it MUST have alt text, and that alt text should provide direction on what the link is, not necessarily describe the image.

We recently "solved" this, by instructing users to make the alt text the same as the title of the node, but that's not a great solution. We're also using a default image for some nodes, and are considering adding a snippet of code to automatically copy the node title into the alt text field for the thumbnail in a view list. Also clunky.
The end result for users with screen readers is a stutter. The image link is right next to a title link, both of which repeat the title of the node.

Sorry - I KNOW this is totally the wrong place for this, but it's been buzzing around and around in my head, as there just doesn't seem to be an easy answer, and I really wish there was a better solution. If core provided one, that would be a monumental win!

Especially now with views in core, I do reckon we need to think it through. Or - I'm hopeful - my google fu has failed me, and there is already an elegant solution out there! :)

@kattekrab we could move this discussion over to GDO, but not sure that's going to reach that many more people at the moment.

Unlike in #2297681: Make the "alt" attribute required in EditorImageDialog we don't actually know how the image is going to be displayed. In the WYSIWYG we know, but you have to have other knowledge for some other uses. So often it's a matter of knowing how the image is used in context with the text. The alt text should convey meaning which is consistent with the page a user is browsing it on. Good points about this in #23:

If image fields don't require the alt attribute right now, then that's how it is. It's out of scope for this issue. Don't forget that they're image fields, and perhaps these images are never exposed in any way to the end user, or perhaps they're repackaged in an image carousel or whatnot, in which case it may be fine to not have alternative text. But in the case of an image being used in rich text, I don't think there's any non-farfetched reason to not have an alt attribute.

#30:

The image field and the editor are not the use same use case, so their forms do not need to be consistent. Having it forced on the editor should be acceptable, since the only use is to insert an image with an html tag, which should always have alt text.

I set up a new issue #2474687: Make it Easier for Views with Images & Links to be Accessible - feel free to build on this.

Awesome! Thanks Mike :)